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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c406e0c4a6eb74ed X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news.glorb.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!feed2.news.rcn.net!rcn!feed3.news.rcn.net!not-for-mail Sender: jsa@rigel.goldenthreadtech.com Newsgroups: comp.lang.ada Subject: Re: ADA Popularity Discussion Request References: <49dc98cf.0408110556.18ae7df@posting.google.com> <6F2Yc.848$8d1.621@newsread2.news.pas.earthlink.net> From: jayessay Organization: Tangible Date: 06 Sep 2004 17:12:54 -0400 Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: DXC=MfMCCJoDC5B;TFKL0R]m=BkYWIG:6bU3OT9S9JnTUUgT5?@kCLjhDjIjS^>Ao@GQaUcVEjL X-Complaints-To: abuse@rcn.com Xref: g2news1.google.com comp.lang.ada:3400 Date: 2004-09-06T17:12:54-04:00 List-Id: kevin.cline@gmail.com (Kevin Cline) writes: > jayessay wrote > > "Richard Riehle" writes: > > > > Also, logic errors (what most > > people would consider significantly more negative) are far rarer. > > > > There turn out to be various reasons for this, but two worth > > mentioning are the sort of bottom up style of programming as described > > by Paul Graham (a kind of agile/extreme programming) and the ability > > to move Lisp to the expressive level of the application domain. > > > > In any application/system of any significance these two go hand in > > hand. The second is achieved by crafting a constrained narrowly > > focused domain specific language _within_ Lisp, which allows the > > programmer to then work at the level of the domain, _both_ > > syntactically as well as semantically. This is why Lisp macros > > (please don't confuse with any other kind of macro you've come across > > before) are such a big deal. > > > > Now, admittedly, creating these is not something your typical code > > monkey is going to grok. This is one of the big reasons why Lisp will > > never be as "popular" as something like Java. But then your typical > > code monkey isn't going to be building your core internal application > > api either. Once you've built this though, even a code monkey will be > > a lot more productive and produce much more clean and robust code. > > > > > For example, a Common Lisp programmer rarely agnonizes over such > > > silliness as constructors, copy constructors, overloading assignment > > > operators, friends, and all the hideous little details that > > > characterize so much of C++ programming. > > I'm skeptical. In any language, data structures will require > initialization to reach the empty state. Just to be clear, I didn't say that last bit, Richard Riehle did. But you've mixed it in with my comments so it is unclear of what you are skeptical - everything quoted above or just the R.R. bit. It's also worth noting that if you substituted "Ada" for "C++" there would not be a substantive change to the bit. Anyway, other than "constructors" none of the stuff in R.R.'s quote is remotely the concern of a developer using Common Lisp. > You still have to write the code, it just has a different name. > Instead of MyThing(int mobys, ...) you have (defun > make-my-thing(mobys ...). Strictly speaking, this is usually simply not true. The normal case by far is one where this code is generated for you from a specification and it is sufficient. There are cases where this will need to be overridden or otherwise enhanced, but those are "outlying" cases. > Instead of a copy constructor, you have (defun > clone-my-thing(thing) ...). This sort of thing is _extremely_ rare, because you don't use or need "copy" semantics. You just do _not_ make copies of things unless there is some _domain_ level reason for it. [Aside: fyi, in such cases where this makes sense it is _much_ more likely that you'd be using defmethod for this sort of thing]. > And if you open files or lock mutexes or consume any other limited > resource, you are going to have to ensure they are released by > writing the equivalent of a destructor. Macros eliminate this sort of "boiler plate" code. These are nothing at all like a destructor. Most other uses of "destructors" typically revolve around "memory management" which obviously is pretty irrelevant in Common Lisp. A typical example here would be with-open-file. You simply do not need to be concerned with the maintenance of the file/os resource, etc. It is handled for you and guranteed to be cleaned up when leaving scope whether by normal or exceptional flow. Same with locks: ;;; Serialize access, lock for update, guarantee unlock on exception, ;;; and unlock/commit on success ;;; (with-protected-resource (get-database :medline-journals) (foo it) (bar it)) > When done well, C++ programming does not get mired in hideous little > details. But like most programming, it is rarely done well. And the > more popular a language, the lower the performance of the average > practitioner. Lots of people learned C++ and Java because that's what > the market demanded. So there is lots of horrible C++ code and Java > code. Mostly agree with this (though C++ does force you to deal with a lot of extraneous grime). > People learn LISP because they love programming. Not all LISP > programmers are geniuses, but almost all are well above the mean. I think you are basically correct in this also. BTW, "LISP" is basically never used anymore except by some as a shorthand for "a Lisp" or "Lisp like language", i.e., as a term for a certain class of languages. > ... > > 1. Which from experience would typically be in the range of 250K-500K > > lines of equivalent Ada/C++/Eiffel/etc. An order of magnitude is not > > hyperbole here even though most uninitiated developers will raise > > their eyebrows or roll their eyes. > > This I know to be true, although again it's not fair to compare the > C++ code from an average programmer to the LISP code from an expert. > An expert C++ programmer can reduce the line count of typical code > by 60% or more. I'm instantiating "LISP" here with Common Lisp. I'm not talking about code monkey C++/Ada/Eiffel vs Guru Lisp. The mentioned one to two orders of magnitude of typical gain holds for expert code vs expert code. > In either language, experts will refactor until a new > domain-specific language appears. I agree that experts will refactor no matter what. However, there is no way to create a domain specific _language_ _within_ C++/Ada/Eiffel/etc. I'm talking about where the the syntax as well as the semantics is just as transparently and cleanly integrated in the language as any core aspect. Where there is no bolt on interpreter needed, no hacking away trying to kludge up something with yacc/lex types of tools. And where the result supports the expression of the application code naturally and cleanly in the terms and processes of the target domain. You just can't do this with things like C++/Ada/Eiffel/etc. You can't even do this with stuff like Smalltalk, Python, or even Dylan. The key to this was succinctly captured by John Foderaro: "Lisp is a programmable programming language". /Jon -- 'j' - a n t h o n y at romeo/charley/november com