robert@isgtec.UUCP (Robert A. Osborne) (03/10/90)
lou@atanasoff.rutgers.edu (Lou Steinberg) writes: >jbaker@gmu90x.gmu.edu (jbaker) writes: >> But the real usefulness of requiring break in a switch statement is for >> SIMILAR treatments of similar cases, for example you may require a >> few assignments in one case before a more complicated computation which >> must be performed for several of the cases. > >ARGHHH!! That is what subroutines (and macros) are for - to handle >common code. And if your language makes them too expensive, either in >terms of run time or in terms of programmer effort, then THAT is an >even worse problem with the language than the problems with break. ARGHHH!! Why are we constantly bombarded with people who do not understand that PEFORMANCE IS SOMETIMES AN ISSUE!!!!! I was under the impression that C's function calls are, relative to other high level languages, very inexpensive, (is this still true?) in which case if you are using fall-through to gain speed (which I have done several times) there is probably a good reason! I'm tired of people blithly saying that "such and such is dangerous, and hence should be removed from the language" when I need such things to get interactive performance. How many people posting to this group(s) are actually using C in a production environment? Rob. -- Robert A. Osborne {...uunet!mnetor,...utzoo}!lsuc!isgtec!robert
woody@eos.UUCP (Wayne Wood) (03/11/90)
In article <300@isgtec.UUCP> robert@isgtec.UUCP (Robert Osborne) writes: > >I'm tired of people blithly saying that "such and such is dangerous, >and hence should be removed from the language" when I need such i agree. if we followed everyboy's advice on what was dangerous in a programming language, we would all be programming in LISP. read Abelson and Sussman for an example of someone who "protects" programmers. /*** woody **************************************************************** *** ...tongue tied and twisted, just an earth bound misfit, I... *** *** -- David Gilmour, Pink Floyd *** ****** woody@eos.arc.nasa.gov *** my opinions, like my mind, are my own ******/
sommar@enea.se (Erland Sommarskog) (03/11/90)
Robert Osborne (robert@isgtec.UUCP) writes: >I'm tired of people blithly saying that "such and such is dangerous, >and hence should be removed from the language" when I need such >things to get interactive performance. How many people posting to >this group(s) are actually using C in a production environment? Well, not me. I work in a production environment, but I fear of the consequences of having the product I work with written in C. We use VAX-Pascal, and that's bad enough. We have severe performance problems in the system I involved with, but I can tell you it's not because Pascal doesn't provide fall- throughs on the CASE statement or have expensive function calls. Those are simply not an issue. (This is a database application, so our problems are connected with the disk I/O and locking.) Working in a production does not only mean ultimate performance, but also acceptable reliability and correctness. With a small application you can maybe afford to have those traps around to be able to gain some small percentage in execution time. (Which not always is worth the bucks it costs your employer to pay you doing it.) But when the size increases it becomes more and more important to keep those traps out. -- Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
lgm@cbnewsc.ATT.COM (lawrence.g.mayka) (03/11/90)
In article <6421@eos.UUCP> woody@eos.UUCP (Wayne Wood) writes: >i agree. if we followed everyboy's advice on what was dangerous in a >programming language, we would all be programming in LISP. Well, I'm glad someone finally admitted it! Let me know if you need a list of commercial Common Lisp implementations. :-) >read Abelson and Sussman for an example of someone who "protects" >programmers. Try a Symbolics workstation for an example of a development environment that works *with* programmers instead of against them. Lawrence G. Mayka AT&T Bell Laboratories lgm@ihlpf.att.com Standard disclaimer.
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (03/12/90)
From article <14312@cbnewsc.ATT.COM>, by lgm@cbnewsc.ATT.COM (lawrence.g.mayka): >In article <6421@eos.UUCP> woody@eos.UUCP (Wayne Wood) writes: >> i agree. if we followed everyboy's advice on what was dangerous in a >> programming language, we would all be programming in LISP. > Well, I'm glad someone finally admitted it! Let me know if you > need a list of commercial Common Lisp implementations. :-) Here's a summary of the advantages and disadvantages of Lisp, from the article "The Automatic Translation of Lisp Applications into Ada", appearing in the Proceedings of the Eighth Annual National Conference on Ada Technology: ...because Lisp was developed for use within the research community, its objectives were considerably different from those of a language such as Ada, which is tuned for applications deployment. In particular, the original objectives of Lisp were: o ease of algorithm prototyping o concise programs (no declarations) o powerful data and control structures o very general constructs o rich programming environments o incremental development o fast compilation o ease of debugging ...Lisp has been utilized as a "rapid prototyping" environment for investigating the algorithms and user interfaces for many "expert systems" being developed... ...While Lisp maximizes the productivity of the prototyping phase of development, it trades off this productivity for increases in cost, weight, and size, and decreases in speed, safety, and maintainability. ...Lisp development software systems are not appropriate for deployment because: o they are too slow, especially on arithmetic o they require extremely large run-time systems -- 50 megabytes or more for Lisp Machines o they do not offer the sort of real-time response mechanisms required for embedded systems o they do not do global consistency checks on variable or function usage o they require a choice between "safety" and speed o they are not easily ported to a wide variety of instruction set architectures. ...At least one defense contractor has taken the idea of "Lisp as a specification language" to a certain conclusion, and produced a system called "InnovAda". InnovAda is the direct interpretation of Zetalisp's Flavors object-oriented programming constructs as a specification language for Ada, except that the executable code within the bodies of the Flavor definitions must be valid Ada code instead of Lisp code. This specification is then processed by the InnovAda translator to produce legal Ada source code by expanding the Flavor constructs. (A system called "Classic Ada" has similarly grafted the object-oriented ideas of Smalltalk onto Ada.) ...As a result of the decision by the Common Lisp committee to delay action on a multiprocessing standard, Common Lisp has not failed as a language for real-time control; it was never considered for this task. As a result, Lisp cannot currently be viewed as an appropriate vehicle for expressing real-time constraints or concurrent control in an embedded system. ...Many existing Lisp systems attempt to provide both software development and applications delivery with the same software. Their "solution" to the problem of efficient code for application delivery is to perform debugging with the SAFETY parameter set to the highest level; when sufficient confidence has been reached with the program, more efficiency is gained (at the expense of safety) by setting SAFETY to the lowest level. This method of achieving speed by increasing the risk of field failure is unacceptable for most applications. While the benefits of additional speed are greatly appreciated by the customer for a while, the risk of sudden and catastrophic failure which can result from the elimination of the run-time checks is not worth the increased speed. As expert systems find their way into embedded applications such as graceful nuclear power plant shutdown and a "pilot's associate", the lowering of safety standards in the software is not to be tolerated. [Remainder of the paper discusses type inferencing during the automatic (but extremely slow) translation of Lisp code into Ada] Bill Wolfe, wtwolfe@hubcap.clemson.edu
woody@eos.UUCP (Wayne Wood) (03/12/90)
In article <14312@cbnewsc.ATT.COM> lgm@cbnewsc.ATT.COM (lawrence.g.mayka,ihp,) writes: [ bunch of stuff about LISP deleted] >Well, I'm glad someone finally admitted it! Let me know if you >>read Abelson and Sussman for an example of someone who "protects" >>programmers. > > Lawrence G. Mayka well, now we know why english isn't a programming language. my article was a slam on the most insipid, brain-dead language i've ever encountered. i didn't say ADA or COBOL merely because i've never programmed in them. i wouldn't wish LISP on anybody. the reference to Abelson and Sussman was a slam also. the authors are obviously idiots who know nothing of programming outside the ivory tower. /*** woody **************************************************************** *** ...tongue tied and twisted, just an earth bound misfit, I... *** *** -- David Gilmour, Pink Floyd *** ****** woody@eos.arc.nasa.gov *** my opinions, like my mind, are my own ******/
drc@cs.brown.edu (David R. Chase) (03/12/90)
In article <6433@eos.UUCP> woody@eos.UUCP (Wayne Wood) writes: >i wouldn't wish LISP on anybody. the reference to Abelson and Sussman >was a slam also. the authors are obviously idiots who know nothing >of programming outside the ivory tower. This is very interesting. Care to elaborate on how you came to these conclusions? I await enlightenment. David
grimlok@hubcap.clemson.edu (Mike Percy) (03/12/90)
From article <8315@hubcap.clemson.edu>, by billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ): > > Here's a summary of the advantages and disadvantages of Lisp, from > the article "The Automatic Translation of Lisp Applications into Ada", > appearing in the Proceedings of the Eighth Annual National Conference > on Ada Technology: [description of lisp to ada translator/prototyper thingy] So what? It could just as well have translated lisp to C, or C++, or Pascal, or BASIC, or... And if Ada is so great, why should someone want to use lisp anyway? Because its faster and easier to prototype in lisp they say? What is an Ada man to do?
robert@isgtec.UUCP (Robert A. Osborne) (03/13/90)
In article <871@enea.se> sommar@enea.se (Erland Sommarskog) writes: >Robert Osborne (robert@isgtec.UUCP) writes: >>I'm tired of people blithly saying that "such and such is dangerous, >>and hence should be removed from the language" when I need such >>things to get interactive performance. How many people posting to >>this group(s) are actually using C in a production environment? >We have severe performance problems in the system I involved with, >but I can tell you it's not because Pascal doesn't provide fall- >throughs on the CASE statement or have expensive function calls. >Those are simply not an issue. (This is a database application, >so our problems are connected with the disk I/O and locking.) If I was writing a database application, I wouldn't want to use C either! Our product is a 3d medical imaging system, so my problems (performance wise) are with handling short[512*512] pixel arrays. An extra couple of cycles per pixel adds up REALLY quick. Your article illustrates *EXACTLY* what I was complaining about, the example of an IO bound process is meaningless, not all processes are IO bound. If somebody was using some subtle, neat C trick to shave off a few cycles when the very next thing they do is access the disk, I would say they were not a good programmer (actually I would probably scream first). Similarily, if they had a couple of unnecessary function calls for every pixel processed because they didn't want to use "messy" but valid C functionality I would also say they were a poor programmer. Which of the two is worse is ENTIRELY dependent on you application. >Working in a production does not only mean ultimate performance, >but also acceptable reliability and correctness. Presently our company dominates our market, mostly because our system is fast enough to be clinically useful. In some applications not doing it fast enough is almost as bad as not doing it! Analyzing the trade offs between reliability and performance are what programmers are paid for. >With a small application you can maybe afford to have those traps >around to be able to gain some small percentage in execution time. >(Which not always is worth the bucks it costs your employer to pay you >doing it.) But when the size increases it becomes more and more >important to keep those traps out. In our application the precentages can be HUGH, I can think of one application that went from 30 seconds to 3 by using some really ugly macros to inline routines. At 30 its too slow to put in the product, at 3 its a part of our demos. It was definitly worth a couple of days work. Again if another couple of days got the time down to 2.9 seconds using really ugly C that was a bitch to support, I agree, it isn't worth it. Sometimes performance is a consideration! You should not judge a language or what programming methods others use on the basis of what your application demands. Rob. -- Robert A. Osborne {...uunet!mnetor,...utzoo}!lsuc!isgtec!robert
cik@l.cc.purdue.edu (Herman Rubin) (03/13/90)
In article <300@isgtec.UUCP>, robert@isgtec.UUCP (Robert A. Osborne) writes: > lou@atanasoff.rutgers.edu (Lou Steinberg) writes: > >jbaker@gmu90x.gmu.edu (jbaker) writes: > >> But the real usefulness of requiring break in a switch statement is for > >> SIMILAR treatments of similar cases, for example you may require a > >> few assignments in one case before a more complicated computation which > >> must be performed for several of the cases. > > > >ARGHHH!! That is what subroutines (and macros) are for - to handle > >common code. And if your language makes them too expensive, either in > >terms of run time or in terms of programmer effort, then THAT is an > >even worse problem with the language than the problems with break. > ARGHHH!! Why are we constantly bombarded with people who do not understand > that PEFORMANCE IS SOMETIMES AN ISSUE!!!!! > > I was under the impression that C's function calls are, relative to other > high level languages, very inexpensive, (is this still true?) > in which case if you are using fall-through to gain speed (which I have > done several times) there is probably a good reason! Simple, yes. Inexpensive, no. I can conceive of a way in which hardware can be constructed which would make subroutine calls inexpensive, but I know of no machine which has it. The following paragraph should be well known to computer users. Unforutnately, this does not seem to be the case. A subroutine necessarily must find its arguments (or pointers to them, etc.) in standardized places. It also must put its results in such places, or use pointers to know where to put them. Occasionally one can put the arguments in those places or use the results that way, but not always. There is also necessarily a context switch to some extent. Even some inline procedures have some of these drawbacks. What used to be called open subroutines do not have these drawbacks; in many cases, they can be replace by macros, but not always. . > I'm tired of people blithly saying that "such and such is dangerous, > and hence should be removed from the language" when I need such > things to get interactive performance. How many people posting to > this group(s) are actually using C in a production environment? This is needed for non-interactive performance also. It is not the case that the speed of the computer can make up for the inefficiency of the code. The infamous frexp function is a strong example of the inefficiencies cause by using subroutines. The actual code as a procedure is not much longer than the code for a subroutine call and return, and may even be shorter. The speed advantage is enormous, especially if, as was done in BSD 4.2, the code was written in C! There is another danger from eliminating things from languages. This has led to eliminating them from machines on the grounds that no one needs them. We could probably eliminate most deaths from automobiles by limiting them to a maximum speed of 5 mph. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)
lgm@cbnewsc.ATT.COM (lawrence.g.mayka) (03/13/90)
[ I have removed comp.lang.c, and added comp.lang.lisp, to the newsgroup list for this discussion. ] In article <8315@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > Here's a summary of the advantages and disadvantages of Lisp, from > the article "The Automatic Translation of Lisp Applications into Ada", > appearing in the Proceedings of the Eighth Annual National Conference > on Ada Technology: ... > ...While Lisp maximizes the productivity of the prototyping > phase of development, it trades off this productivity for > increases in cost, weight, and size, and decreases in speed, > safety, and maintainability. These disadvantages are application- and implementation-dependent generalizations. The alleged loss of safety and maintainability is highly debatable, as well as being highly dependent on one's definitions and criteria. > ...Lisp development software systems are not appropriate for > deployment because: > > o they are too slow, especially on arithmetic > o they require extremely large run-time systems > -- 50 megabytes or more for Lisp Machines > o they do not offer the sort of real-time response > mechanisms required for embedded systems ... > o they require a choice between "safety" and speed Again, application- and implementation-dependent generalizations. > o they are not easily ported to a wide variety of > instruction set architectures. Simply untrue. Common Lisp is available on all major processor architectures. > ...As a result of the decision by the Common Lisp committee > to delay action on a multiprocessing standard, Common Lisp > has not failed as a language for real-time control; it was > never considered for this task. As a result, Lisp cannot > currently be viewed as an appropriate vehicle for expressing > real-time constraints or concurrent control in an embedded system. This of course assumes that one's application requires processes (in the computer science sense of "an independent thread of execution"). Some real-time, concurrent-control applications are more amenable to a finite-state machine approach anyway. It is indeed sad, however, that the de facto standard Common Lisp multiprocessing constructs (PROCESS-RUN-FUNCTION and friends) were not ruled de jure into the ANSI standard. > ...Many existing Lisp systems attempt to provide both software > development and applications delivery with the same software. > Their "solution" to the problem of efficient code for application > delivery is to perform debugging with the SAFETY parameter set to > the highest level; when sufficient confidence has been reached with > the program, more efficiency is gained (at the expense of safety) by > setting SAFETY to the lowest level. This method of achieving speed > by increasing the risk of field failure is unacceptable for most > applications. While the benefits of additional speed are greatly > appreciated by the customer for a while, the risk of sudden and > catastrophic failure which can result from the elimination of the > run-time checks is not worth the increased speed. As expert systems > find their way into embedded applications such as graceful nuclear > power plant shutdown and a "pilot's associate", the lowering of > safety standards in the software is not to be tolerated. I agree that the "solution" of lowering SAFETY is a basically unacceptable tradeoff. Common Lisp vendors are challenged to provide acceptable execution speed *without* a loss of run-time safety. To some extent the better vendors are meeting the challenge already, but they must continue to make progress in this area if they expect to remain competitive. Lawrence G. Mayka AT&T Bell Laboratories lgm@ihlpf.att.com Standard disclaimer.
jeff@aiai.ed.ac.uk (Jeff Dalton) (03/14/90)
In article <8315@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > [...] In particular, the original objectives of Lisp were: > > o ease of algorithm prototyping > o concise programs (no declarations) > o powerful data and control structures > o very general constructs > o rich programming environments > o incremental development > o fast compilation > o ease of debugging These are *not* the original objectives for Lisp. They are some much more recent list from I know not where. > ...Many existing Lisp systems attempt to provide both software > development and applications delivery with the same software. > Their "solution" to the problem of efficient code for application > delivery is to perform debugging with the SAFETY parameter set to > the highest level; when sufficient confidence has been reached with > the program, more efficiency is gained (at the expense of safety) by > setting SAFETY to the lowest level. This is Common Lisp, not Lisp in general. This study seemed to be somewhat confused about what was Lisp and what was Common Lisp or Lisp Machines or particular implementations etc. -- Jeff
grano@cs.Helsinki.FI (Kari Gran|) (03/14/90)
Abelson & Sussman is one of the few good books on programming that I've read. And anyway, flaming that the authors are idiots without _any_ arguments is not very convincing. It's stupid. So, please enlighten me too. Kari. -- Kari Grano grano@cs.helsinki.fi Hey, my opinions are just mine.. "I've got a thousand telephones that don't ring" - R.Z.
nick@lfcs.ed.ac.uk (Nick Rothwell) (03/14/90)
In article <2000@l.cc.purdue.edu>, cik@l.cc (Herman Rubin) writes: >In article <300@isgtec.UUCP>, robert@isgtec.UUCP (Robert A. Osborne) writes: >> lou@atanasoff.rutgers.edu (Lou Steinberg) writes: >> >ARGHHH!! That is what subroutines (and macros) are for - to handle >> >common code. And if your language makes them too expensive, either in >> >terms of run time or in terms of programmer effort, then THAT is an >> >even worse problem with the language than the problems with break. >> ARGHHH!! Why are we constantly bombarded with people who do not understand >> that PEFORMANCE IS SOMETIMES AN ISSUE!!!!! >> >> I was under the impression that C's function calls are, relative to other >> high level languages, very inexpensive, (is this still true?) >> in which case if you are using fall-through to gain speed (which I have >> done several times) there is probably a good reason! > >Simple, yes. Inexpensive, no. How about "free"? Is there any reason why a decent compiler shouldn't beta-reduce function calls to inlining? "Why are we constantly bombarded by people who do not understand that compiler technology can solve a lot of these problems, if only we could move away from 20 year old compilers". I could also make a comment about moving away from horrible 20-year-old languages like C, but I suspect that's not an option. >I can conceive of a way in which hardware >can be constructed which would make subroutine calls inexpensive, but I >know of no machine which has it. Do it in the compiler. >Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ A prop? ...or wings? A prop? ...or wings? A prop?