Re: ADA Popularity Discussion Request

[kevin.cline@gmail.com (Kevin Cline)]

jayessay <nospam@foo.com> wrote in message news:<m3656vfgmf.fsf@rigel.goldenthreadtech.com>...
> "Richard  Riehle" <adaworks@earthlink.net> writes:
> 
> > "jayessay" <nospam@foo.com> wrote in message
> > news:m3isb2ey3w.fsf@rigel.goldenthreadtech.com...
> > > "Richard  Riehle" <adaworks@earthlink.net> 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.