Re: ADA Popularity Discussion Request

[jayessay <nospam@foo.com>]

"Richard  Riehle" <adaworks@earthlink.net> writes:

> One of the benefits of assertions (DbC) is that one can simply
> declare a range of unacceptable conditions as part of the design
> and be assured that those conditions will not be permitted to
> occur.

There is nothing about this that is incompatible with dynamic typing.
If you wanted you could implement the whole Eiffel Dbc thing (and then
some) as a set of macros using CLOS within Common Lisp.  As I recall
now, someone actually did this (I will try to find it).


>    Moreover, a well-designed program must be about more than simple
> correctness, even as hard as that is.

Agreed (if for no other reason than what "correctness" means is
typically vague - even in very well designed and specified systems.)


> In particular, as the deployed design is required to deal with the
> real world, it must be able to adapt itself to the unexpected.

This is a particularly apropos aspect of systems built with dynamic
systems.  Evolvable and adaptable are key descriptors.


> Let me give you an example.  In am system I know something about,
> one with a large number of components, a programmer included a
> routine that had a built-in constraint (not a type constraint), in
> the form of an if ... end if statement.  The constraint was cleverly
> written and the language in use was not strongly typed, so the

Just to be clear "not strongly typed" and "not type safe" have nothing
to do with dynamically typed.


> but the test scripts (well-designed) did not catch the error.  When
> it occurred, the system failed, and no one knew why until a
> considerable amount of analysis was performed.

Also, just for clarity, are you saying you believe static typing would
have made a difference here?  You can dream up plausible scenarios
where it might have but equally plausible scenarios it wouldn't have.
I actually think dynamic typing would be significantly more
efficacious here (if not any more than static typing in prevention,
then certainly in immediately pinpointing the problem).


> Finally, I truly hope that no Lisp programmer, Smalltalk enthusiast,
> or their ilk will persuade the designers of flight avionics to begin
> using those languages.

I'm not advocating this - mostly because I don't think this domain
needs the kind of flexibility and expressiveness that comes from Lisp.
This stuff belongs to a very well bounded and concretely defined
domain.


> It is bad enough that some of them have chosen to use C and C++.  We
> need to, as always, select the right tool for the job at hand.

This, OTOH is just implicitly cast FUD, presumably intended to imply
that something like Common Lisp would not "work well" here.  I will
absolutely make the claim that such an offering would be every bit as
robust and "correct" as anything fielded.  It is likely it would also
be rather more maintainable.

Maybe you are simply saying that the resources available here are
still just too small to make this a viable option.  I'm sure there are
still a lot of things out there with just a few kilobytes available.
Then again, Garmine has some pretty impressive boxes and last I looked
Avidyne was still using WindozeNT/2000(!!!) as its base.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com