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!news2.google.com!news.maxwell.syr.edu!newsfeed.icl.net!feed.news.tiscali.de!news.belwue.de!news.uni-stuttgart.de!carbon.eu.sun.com!new-usenet.uk.sun.com!not-for-mail From: Ole-Hjalmar Kristensen Newsgroups: comp.lang.ada Subject: Re: ADA Popularity Discussion Request Date: 06 Sep 2004 09:49:42 +0200 Organization: Sun Microsystems Message-ID: References: <49dc98cf.0408110556.18ae7df@posting.google.com> <6F2Yc.848$8d1.621@newsread2.news.pas.earthlink.net> NNTP-Posting-Host: khepri06.norway.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: new-usenet.uk.sun.com 1094456983 526 129.159.112.195 (6 Sep 2004 07:49:43 GMT) X-Complaints-To: usenet@new-usenet.uk.sun.com NNTP-Posting-Date: 6 Sep 2004 07:49:43 GMT User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:3356 Date: 2004-09-06T07:49:43+00:00 List-Id: >>>>> "j" == jayessay writes: j> "Richard Riehle" writes: >> "jayessay" wrote in message >> news:m3isb2ey3w.fsf@rigel.goldenthreadtech.com... >> > "Richard Riehle" writes: >> > j> ... >> Ada and Eiffel are designed with more compile-time checking capabilities >> than Smalltalk. j> Static typing is largely overrated - even Hindley-Milner type systems j> such as in Haskell or ML (which are significantly more potent than the j> type systems of Eiffel or Ada). The whole thing sounds great in j> theory and you can make some pretty plausible arguments for its j> efficacy, but it just doesn't make much difference in practice. j> I used to be a real advocate of this stuff and made those arguments j> myself (both here and elsewhere). It (static typing) was one of the j> things I was unsure about losing when I switched to Common Lisp (aka j> Lisp in this message) for all my major work 7 years ago. So, I kept a j> log of all the errors that I knew would have been caught by compile j> time type checking. I don't rigorously follow this practice anymore, j> but as I recall there were only 15 or so in 50K "lines" of Lisp [1]. j> Furthermore, all but a couple of these were caught immediately on j> first testing of function in question. No such errors ever manefested j> themselves in production code. Yes, I know the typical rebuttal here j> is "Yet!". In theory that's true, but the evidence at this point j> suggests it is extremely unlikely. Also, logic errors (what most j> people would consider significantly more negative) are far rarer. j> There turn out to be various reasons for this, but two worth j> mentioning are the sort of bottom up style of programming as described j> by Paul Graham (a kind of agile/extreme programming) and the ability j> to move Lisp to the expressive level of the application domain. j> In any application/system of any significance these two go hand in j> hand. The second is achieved by crafting a constrained narrowly j> focused domain specific language _within_ Lisp, which allows the j> programmer to then work at the level of the domain, _both_ j> syntactically as well as semantically. This is why Lisp macros j> (please don't confuse with any other kind of macro you've come across j> before) are such a big deal. j> Now, admittedly, creating these is not something your typical code j> monkey is going to grok. This is one of the big reasons why Lisp will j> never be as "popular" as something like Java. But then your typical j> code monkey isn't going to be building your core internal application j> api either. Once you've built this though, even a code monkey will be j> a lot more productive and produce much more clean and robust code. I do not consider myself a Lisp programmer, but I have programmed enough Lisp to conclude that you probably are correct that the ability to create a constrained narrowly focused domain specific language within Lisp could very well outweigh the advantages of static typing. But for the last years I have been mainly working with soft real time, multi-threaded systems. I am aware of the existence of real-time garbage collectors, but what about multi-threading? Common Lisp used to be pretty weak in this respect, has this changed? -- C++: The power, elegance and simplicity of a hand grenade.