Re: ADA Popularity Discussion Request

["Richard Riehle" <adaworks@earthlink.net>]

"jayessay" <nospam@foo.com> wrote in message
news:m3isb2ey3w.fsf@rigel.goldenthreadtech.com...
> "Richard  Riehle" <adaworks@earthlink.net> writes:
>
>
> > Smalltalk is an excellent tool for object-oriented programming, and
> > a good choice when the deeper concern is not software safety.
>
> Are you trying to say that Smalltalk is somehow inherently less "safe"
> than things like Ada and Eiffel?  What is "safe" here?
>
Ada and Eiffel are designed with more compile-time checking capabilities
than Smalltalk.  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).   When I speak of "underlying representation
issues" I mean the absence of side-effects that accompany the kind
of assignment that concerns an imperative language programmer.  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.   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.

Richard Riehle