Re: ADA Popularity Discussion Request

[jayessay <nospam@foo.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 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