From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_00,INVALID_MSGID, MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,dc94fe39f71093ec X-Google-Attributes: gid103376,public From: Robert Dewar Subject: Re: The revolution will not be standardized Date: 2000/01/07 Message-ID: <854tvc$osf$1@nnrp1.deja.com>#1/1 X-Deja-AN: 569425065 References: <82p7hu$l1q$1@nnrp1.deja.com> <82ppc9$1u6$1@nnrp1.deja.com> <385252E8.FF140CD2@acenet.com.au> <8333q3$9rh$1@nnrp1.deja.com> <8335ip$b8f$1@nnrp1.deja.com> <38561D9A.70B61403@acenet.com.au> <835ukh$uiv$1@nntp2.atl.mindspring.net> <385685B2.7E341C32@quadruscorp.com> <3856d861.30417176@news.netidea.com> <3856EA29.7B4C0A95@quadruscorp.com> <838mhs$cii$1@nnrp1.deja.com> <385F6039.65A1B1B4@acenet.com.au> <83od9d$1i8$1@nnrp1.deja.com> <83osai$ekj$1@nntp2.atl.mindspring.net> <83sb2d$r1i$1@nnrp1.deja.com> <83ubgv$mlv$1@nntp5.atl.mindspring.net> <852ehv$53$1@nnrp1.deja.com> X-Http-Proxy: 1.0 x32.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja.com - Before you buy. X-Article-Creation-Date: Fri Jan 07 14:41:51 2000 GMT X-MyDeja-Info: XMYDJUIDrobert_dewar Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.61 [en] (OS/2; I) Date: 2000-01-07T00:00:00+00:00 List-Id: In article , Robert A Duff wrote: >Some of the above languages you mention are very special purpose, so > they don't count, in my mind, when discussing the design of general > purpose languages. I don't think SNOBOL should be a "language"; You just don't know SNOBOL4 well, or you would not make this statement. Of *course* SNOBOL4 is a general purpose language. Yes, people who only have a surface acquaintance with the language think of it as being specialized to string processing and that pattern matching is the only interesting feature, but this is bogus. Indeed Robert Dewar's important rule for writing SNOBOL-4, well known in that community is "Don't use pattern matching". What this rule means is that unlike the case in SNOBOL-3, it is wrong to write complex algorithms as pattern matches in SNOBOL-4. The most interesting features of SNOBOL-4 to me are the generalized mappings (the TABLE function), a VERY important feature in programming languages as is known well from the SETL family of languages (SETL/ABC/Python), and the DATA facility for creating programmer defined data types. The latter are particularly interesting, they are record types, where member names are functions that can be applied to any record type sharing the same member name. This can be used to construct quite interesting structures, including for example the possibility of multiple dispatching. Finally, the most important feature of SNOBOL4 is its highly dynamic nature. Someone once said that the design of SNOBOL4 is "never do anything at compile time if it can be left till runtime". The dynamic definition of functions, and the EVAL/CODE functions, familiar from the LISP family of languages, are very powerful additions to expressive power. The SPITBOL packages in GNAT are handy for providing a very limited subset of the SNOBOL4 capability, namely string pattern matching, but please please do not confuse this with providing anything approaching the expressive power of SNOBOL4. That's simply not possible in a low level language like Ada :-) I would guess that Bob's other comments about my list of languages being specialized is also based on inadequate familiarity with these languages. For example, people who don't know APL often dismiss it on the grounds that it is just a specialized gizmo for dealing with arrays, but in fact APL also is a powerful general purpose very high level language with extremely interesting ideas on data aggregation. APL demonstrates that you can replace a lot of traditional algorithm messing with complex data structures by powerful manipulations on much more regular data structures. It's a pity how unfamiliar people are with the general notion and feel of very high level languages (calling them simply high level languages is admittedly deliberately provocative :-) And it is surprising how much programming is done in low level languages. Java is a particular disappointment. If we are at the stage where we can afford the kinds of fundamental inefficiencies that the Java approach involves (and that people have run into with Java), then we could have had a far higher level language that would have allowed Java applications to be written far more compactly and reliably. As it is Java suffers from most of the disadvantages of both worlds -- the need to write things down at a low level, worrying about data structures, and the inefficiencies of generalized "interpretive" execution. The "intepretive" is in quotes here, because of course Java can be compiled, but then any interpretive language can be compiled (SPITBOL/360 demonstrated that a long time ago, and the technology of compiled APL is well established at this stage). I believe that if Java had been designed from the start with its eventual deployment in mind, it might have turned out very differently. Of course the emphasis on reference rather than value semantics is a matter of taste. For me, going more in the direction of reference semantics is a huge mistake. Sent via Deja.com http://www.deja.com/ Before you buy.