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!news2.google.com!news.maxwell.syr.edu!nntp.abs.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: 03 Sep 2004 12:43:04 -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=LhP[ZLE2FY:0]AXZF=`TL20R]m=BkYWI7:6bU3OT9S9:3?f;=fXOXk=LjhDjIjS^>1dLmBTmK=C3> X-Complaints-To: abuse@rcn.com Xref: g2news1.google.com comp.lang.ada:3297 Date: 2004-09-03T12:43:04-04:00 List-Id: "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 used to be a real advocate of this stuff and made those arguments myself (both here and elsewhere). It (static typing) was one of the things I was unsure about losing when I switched to Common Lisp (aka Lisp in this message) for all my major work 7 years ago. So, I kept a log of all the errors that I knew would have been caught by compile time type checking. I don't rigorously follow this practice anymore, but as I recall there were only 15 or so in 50K "lines" of Lisp [1]. 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. 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 safety-critical software, Ada is more appropriate, > in most cases than Smalltalk. This is not meant to deprecate Smalltalk. > Rather, it is intended to recognize that there are differences in languages, > and some have benefits for certain kinds of problem space than others. > Smalltalk certainly has its benefits, but large-scale, safety-critical > software > is not one of them. > > > > > Functional languages free the developer from concerns about the > > > underlying representation issues, and allow one to work at a level > > > of abstraction not easily available in imperative languages. > > > > This isn't true as simply stated. There are counterexamples (most > > notably Common Lisp and to a somewhat lesser degree Scheme). What > > real functional languages buy you is the absence of side effects, > > which makes proofs about them significantly simpler > > > Ah, yes. Those wonderful counter-examples. You are correct about > the absence of side-effects (though one can argue counter-examples > even there, but I won't). Counter examples are important for getting the _concepts_ correct. If you want to say "typically this" or "typically that", that's fine and such points can carry important information. > 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. True (actually "rarely" should be replaced with "never"), but those horrors are orthogonal to being imperative. Afterall, Java, lame as it is, doesn't have this type of grime to work through. > Functional languages tend to more focused on the problem at hand > rather than the environment in which the problem will be solved and > the implications of that environment on the outcome. Partly. But typical functional languages (haskell, ml, ...) don't have any means for directly encompassing domain semantics into them. For that, you need something like Lisp macros. /Jon ---- 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. I have a few examples where _two_ orders of magnitude would not be hyperbole as you would need a fully integrated and embedded optimizing compiler to achieve an equivalent result. -- 'j' - a n t h o n y at romeo/charley/november com