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
fpst@hubcap.UUCP (Steve Stevenson) (05/05/88)
The comments on this subject are somewhat misleading. One must keep clearly in mind that what most folks call "programming language" is really virtual machine + a tad of syntax. After twenty years in the language and computability game, about the strongest conclusion I can come to is that language is a very personal commodity. Compilers developed to meet the needs of early programmers with different needs. The issues in the '60s was fast compilation and optimal runtimes. It is time to reevaluate that objective function. I personally think it stinks. The question - now that some folks want to have the fate of the world in the hands of programmers - is getting things to work right every time. When you, dear reader, were cheaper than the machine, your management didn't care about how long you worked. And since the life time of commerical software was thought to be short, they really didn't care about quality. Now we're paying the price for teaching you syntax and not semantics and brand loyalty instead of principles. As to the universal OS - it is a "language" too, at least in the formal sense. UNIX is neat, but certainly not the ultimate. This newsgroup represents the folks who start it off. You need to consider principles in computation and programming as much as the engineering principles. End soapbox. -- Steve Stevenson fpst@hubcap.clemson.edu (aka D. E. Stevenson), fpst@clemson.csnet Department of Computer Science, comp.parallel Clemson University, Clemson, SC 29634-1906 (803)656-5880.mabell
eugene@pioneer.arpa (Eugene N. Miya) (05/05/88)
I think we are beginning to stray from architectures, I will follow this up to os.research and lang.misc In article <1575@hubcap.UUCP> fpst@hubcap.UUCP (Steve Stevenson) writes: > . . . summary: languages are personal >Compilers developed to meet the needs of early programmers >with different needs. The issues in the '60s was fast compilation and >optimal runtimes. I'll add: to minimize storge for expensive memories >It is time to reevaluate that objective function. I personally think >it stinks. This is my comment as it pertains to architecture: we must not forget that we built and use computers to accomplish specific tasks: first to compute ballistic trajectories, then simulate thermonuclear processes, model the weather, fly spacecraft, and so on [fun now for instance]. I can't easily justify the first two personally, but I have worked on weather, image processing, and space problems. It's kind of a silly joke to hear about the 24 hour weather forecast which takes 27 hours to run. But weather is a more serious matter outside California. ;-) A different physicist I am working with (in his 60s, in fact he can remember the comment about the most machine ever needed [live]) made a really neat comment when the people at Purdue mapped a cold virus. He said, "That's neat, that's what computers are for!" And he is kind of right. I wonder if Turing and von Neumann would turn in their graves if they saw video games and word processors as the chief use of computing (Don't post, it's retorical, think about it for yourself)? This contrasts with the islands he vaporized doing experimental physics ;-). My point is we have to keep some balance and perspective why we have made computers. I believe Cray (the person does this). Now if you architects can only get some quiet time to build better machines. Enough rambling (sorry). >The question - now that some folks want to have the >fate of the world in the hands of programmers - is getting things >to work right every time. This is why Ada(tm) was developed, see the Rationale document. (not an endorsement of this language). >As to the universal OS - it is a "language" too, at least in the formal sense. Re: the topic of problem specific language is always bandied about: i.e. editing as a language, programming languages, graphics as a language, etc. I was given a reminder in a different discussion. Check out: %A Ivan E. Sutherland %T Computer Graphics - Ten Unsolved Problems %J Datamation %V ?? %N ?? %D May 1966 %P 22-27 %X (Surprise!) When Datamation was a respectable technical publication. A very good article. See problem 3 on "coupling." This latter (reminder) given to me by Frank Crow (PARC). Neat old classic paper (youngins' like me) need reminders like this. Another gross generalization from --eugene miya, NASA Ames Research Center, eugene@ames-aurora.ARPA resident cynic soon to be aurora.arc.nasa.gov at the Rock of Ages Home for Retired Hackers: "Mailers?! HA!", "If my mail does not reach you, please accept my apology." {uunet,hplabs,hao,ihnp4,decwrl,allegra,tektronix}!ames!aurora!eugene "Send mail, avoid follow-ups. If enough, I'll summarize."
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)