steckel@Alliant.COM (Geoff Steckel) (05/04/88)
In article <762@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >> >The language ... should ... try to include it _all_. In article <768@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >And they must realize that the resulting system will probably be inadequate, >and therefore must be easily extensible. This means that the user must be >able to use notation which he considers easy to read, as long as that notation >is not already coopted, and in some cases it might be necessary to change >existing notation. This is done in mathematics all the time, and does not >lead to problems. I will argue that extensible languages lead to fairly large problems in programming systems. As soon as more than one person uses a system, "personal taste" rears its head. The more a language needs extending, the more the resultant language-prime becomes unintelligible to the next reader. Have you ever tried to read a math paper where the author invented fifty new symbols and formalisms? Try, then, using those formalisms PERFECTLY to change a paper 3000 lines of equations long. Then hand your work to someone else in the hall and leave the building, and let that person do the same to what you've done. Result? A mess... The worst case are languages where one does not debug, but discards and starts again (exaggeration, but I am quoting smart, sophisticated users!): APL - the original one-liner programs PL/I - the most sub-set prone major language forth - just try and use someone else's dictionary EL/1 and other extensible languages ADA with highly overloaded operators In almost any language with a macro facility it is possible to "extend" the language to the point of incomprehensibility - and quite quickly! A very major part of the art of engineering (including software) is understanding and using the limitations of your materials, be they concepts, software, or hardware. Give me powerful, elegant constructs - and not so many of them I can't understand them! Geoff Steckel (steckel@allliant.COM)
crowl@cs.rochester.edu (Lawrence Crowl) (05/04/88)
Please remove comp.arch from the Newsgroups line when following up to this
topic.
--
Lawrence Crowl 716-275-9499 University of Rochester
crowl@cs.rochester.edu Computer Science Department
...!{allegra,decvax,rutgers}!rochester!crowl Rochester, New York, 14627ralphw@ius3.ius.cs.cmu.edu (Ralph Hyre) (05/04/88)
[followups directed to comp.lang.misc, where they belong] In article <1705@alliant.Alliant.COM> steckel@alliant.UUCP (Geoff Steckel) writes: >In article <762@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >>> >The language ... should ... try to include it _all_. > >In article <768@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: > >>And they must realize that the resulting system ... must be easily >> extensible. This means that the user must be able to use notation >> which he considers easy to read, >I will argue that extensible languages lead to fairly large problems... >"personal taste" rears its head. The more a language needs extending, >the more the resultant language-prime becomes unintelligible to the next >reader. Assuming you make extensions within the basic syntax of the language, I believe that documentation of the language concepts and philosophy is sufficient to smooth over most problems caused by differences. My model of the 'programming environment of the future' includes a programming assistant, which will transliterate your code into other language. This is how Kyoto Common Lisp works, it gets compiled into C. I doubt that the output is meant for humans, though, so there's still some technology to devlop. You might imagine using smalltalk to do some user-interface prototyping, lisp or prolog to write some inference engines, and C to do some time-critical crunching. If you want to deliver a version completely written in C, just invoke the smalltalk->lisp and lisp->C translators on it. [This might be an advantage if you want to sell C 'source code' to your customers, but want them to have a hard time deciphering it so you retain your competetive edge.] Not easy to think about implementing this. A simpler alternative, of course, is to specify inter-language interfaces For example, most modern Unix lisps have a way of calling routines in Unix object modules. -- - Ralph W. Hyre, Jr. Internet: ralphw@ius2.cs.cmu.edu Phone:(412)268-{2847,3275} CMU-{BUGS,DARK} Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA
kasper@csli.STANFORD.EDU (Kasper Osterbye) (05/05/88)
In article <1705@alliant.Alliant.COM> steckel@alliant.UUCP (Geoff Steckel) writes: >A very major part of the art of engineering (including software) is >understanding and using the limitations of your materials, be they concepts, >software, or hardware. Give me powerful, elegant constructs - and not >so many of them I can't understand them! > > Geoff Steckel (steckel@allliant.COM) Geoff argues that the use of extensible languages leads to unreadable code for anybody but the author. I agree, but the same seems to happen in languages that do not include that kind of abstraction mechanisms. It happens in the form of programming idioms. Most programmes have their little tricks, that are hard to understand, or does something "dirty", and while I do not have to learn the abstracted formalism, I have to learn to recoqnize certain pieces of code, or data as being related in a very special way. Some examples from different languages is In Basic you can not have array of record, but then one just make an array of each primitive type involved, and remembers that the arrays are really just one structure. In prolog someone uses difference lists, which is not normal lists, and can not be used as such, but you must know that when you read the program. In Pascal variant record are used to implement soft typing. And one can go on. All these little things differ from person to person, and is one of the things that makes it difficult to read others programs, even if it is not an extensible language. Unfortunately it seems like there is no easy way out of this mess. I am personally in favor of ext. lang. but know the problem of readability, and yes I have tried to use some one elses dictionary in forth, and know what you mean. --Kasper Kasper Osterbye ||| /// ///| Internet: kasper@csli.stanford.edu ||| /// ///|| UUCP: {backbones..}!csli.stanford.edu!kasper |||<<< ///||| AT&T: (415) 323 9604 ||| \\\ ///=||| USMAIL: 2420 Tasso st. #3, Palo Alto CA 94301 ||| \\X// |||MIGA
pase@ogcvax.ogc.edu (Douglas M. Pase) (05/06/88)
In article <sol.9329> crowl@cs.rochester.edu (Lawrence Crowl) writes: >Please remove comp.arch from the Newsgroups line when following up to this >topic. For that matter, please remove comp.lang.misc from the Newsgroups line also. I have the following complaints about this latest batch of articles: (1) The assertions/suggestions put forth in certain previous articles reflect only a primitive understanding of language design (and I'm NOT refering to compiler design). For all their vagueness the basic ideas presented seem to be more grandiose but otherwise little different from some of the great "has-been"s of the '60s. a) This language should be everything to everybody... (Ever hear of PL/I or Algol 68?) b) Each programmer should be able to modify the language on the fly... (A previous article has already brought up examples of that.) c) We should adopt a UNIFORM notation... (Aside from its obvious contradictions with (b) above, it's not clear that this really means anything. It is clear that the implications are not understood by the original author.) d) Efficiency is a must... (In terms of what? CPU time? Programmer time? Both? Something else? For which problems? All? Some special subset?... How would you achieve it?) (2) A number of comments seem to indicate the original author considers language designers to be at least an "unimaginative" lot. Judging from the quality of the text surrounding the claims, he who makes the claims is not in a position to do so. -- Doug Pase -- ...ucbvax!tektronix!ogcvax!pase or pase@cse.ogc.edu (CSNet)