Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[jayessay <nospam@foo.com>]

Ole-Hjalmar Kristensen 

> >>>>> "KC" == Kevin Cline <kevin.cline@gmail.com> writes:
> 
> <snip>
> 
>     >> 
>     >> Does this prove that perl is the best language?  If so, perhaps we
>     >> should all switch our avionics projects over to perl.  Must be it will
>     >> be easier to code and maintain, safer to fly, and run just as fast.
> 
>   KC> It doesn't prove that Perl is the best language for every job.  But
>   KC> the original thread was about Ada popularity.  Relatively few people
>   KC> write avionics code, or any safety-critical software.  I do think that
>   KC> a lot of projects currently being written in C++, Java, or C# could be
>   KC> done much more cheaply and effectively in Perl or a similar language.
> 
>     >> 
>     >> The things that make a language a "good" language are many and
>     >> complex, and are different in different circumstances.  If I need a
>     >> small utility that compares lines in different text files, I find perl
>     >> much easier than Ada.  On the other hand, if I have a very large
>     >> project that must always perform "correctly", I've not found a
>     >> language that can beat Ada.
> 
>     KC> But large projects in Ada or C++ or Java or C# might be small or
>     KC> medium-sized projects in a higher-level language.

I have found this to be _very_ true.


> Maybe. It depends on how large the projcet is, and how good you are
> to create reusable components/abstractions within the project,

Not really, as that should be true no matter what language you use.


> and how good a fit your problem is to the facilites provided by the
> "higher-level" language.

This is key.  The robustness, maintainability, evolvability, and
"correctness" of a program is directly and closely related to how
close its expression is to the language of the problem domain.

In the case of Lisp, this is where the "Lisp is a programmable
programming language" comes in.  You can always create a (possibly
hierarchical set of) domain specific language that directly supports
the most natural, clean, and direct means of expressing the
definitions and process within the domain.  People often talk of
"hoisting the language up to the level of the domain".

It used to be (and I suppose in many places still is the case) that
people thought this sort of thing could be done with components and
component libraries.  But this is an error.  No library (no matter how
good it is - and most are very poor) will ever have the level of
expressiveness as even a decent (let alone good) domain specific
language.


>     KC> If you have a project that must always perform "correctly", then you
>     KC> better prove it correct.  Strong typing can help, but is not
>     KC> absolutely necessary to that effort.
> 
>     KC> For the rest of us, the most important thing is to get tested code
>     KC> done quickly.  I don't know about you, but I can write and test 14
>     KC> lines of code a whole lot faster than I can write and test 80 or 160.
> 
> I usually find that my ability to create programs is limited by my
> thought process, not my typing speed :-)

He's not refering to the same limitation, and he's right.


/Jon

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