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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no 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!postnews2.google.com!not-for-mail From: kevin.cline@gmail.com (Kevin Cline) Newsgroups: comp.lang.ada Subject: Re: ADA Popularity Discussion Request Date: 4 Sep 2004 21:36:08 -0700 Organization: http://groups.google.com Message-ID: References: <49dc98cf.0408110556.18ae7df@posting.google.com> <6F2Yc.848$8d1.621@newsread2.news.pas.earthlink.net> NNTP-Posting-Host: 170.215.189.146 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1094358968 29134 127.0.0.1 (5 Sep 2004 04:36:08 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sun, 5 Sep 2004 04:36:08 +0000 (UTC) Xref: g2news1.google.com comp.lang.ada:3325 Date: 2004-09-04T21:36:08-07:00 List-Id: jayessay wrote in message news:... > "Richard Riehle" writes: > > > "jayessay" wrote in message > > news:m3isb2ey3w.fsf@rigel.goldenthreadtech.com... > > > "Richard Riehle" writes: > > > > ... > > Ada and Eiffel are designed with more compile-time checking capabilities > > than Smalltalk. > > Static typing is largely overrated - even Hindley-Milner type systems > such as in Haskell or ML (which are significantly more potent than the > type systems of Eiffel or Ada). The whole thing sounds great in > theory and you can make some pretty plausible arguments for its > efficacy, but it just doesn't make much difference in practice. I've come to the same conclusion. Once you decide to test code before you write it, strong typing loses most of it's value. On the other hand, if I'm working on code without a good set of automated tests, then strong typing is a very nice thing to have. > Furthermore, all but a couple of these were caught immediately on > first testing of function in question. > No such errors ever manefested > themselves in production code. Yes, I know the typical rebuttal here > is "Yet!". In theory that's true, but the evidence at this point > suggests it is extremely unlikely. In theory and in practice, no useful programming language can eliminate all possibility of runtime errors. No matter what, you still have to test the code. > 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. 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 ...). Instead of a copy constructor, you have (defun clone-my-thing(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. 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. People learn LISP because they love programming. Not all LISP programmers are geniuses, but almost all are well above the mean. ... > 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. In either language, experts will refactor until a new domain-specific language appears.