Re: Any research putting c above ada?

[jsa@alexandria (Jon S Anthony)]

In article <5kopik$1jos@newssvr01-int.news.prodigy.com> NKSW39B@prodigy.com (Matthew Givens) writes:

> (Ada...) all, a rigid programming environment that

Not particularly - certainly not really in comparison to C or C++.
Definitely true in comparison to Lisp, ST, and such.


> Ada also has it's weaknesses.  We're using it to develop GUI based Oracle 
> applications on a Sun system.  The compiled code for the executables is 
> tryuly enormous, in comparison with the executable generated for similar 

I have a bad feeling you are doing this using some Ada83 impl...


> Anyway, size of executables is one problem (I wrote one that had an
> executable size of almost 600K, and that was just a report
> generator, not a GUI app).

If you instantiate a lot of generics all over the place (especially if
you don't organize things sensibly) and you implementation does not
have generic code sharing, then sure, you can wind up with code bloat.
Generally, I've found this has more to do with poor understanding of
how this stuff should be used.  Typical example is instantiating
Integer_IO or whatever all over the place when one is just fine.


> Others include indequate programming tools for the language and
> tasking problems (Ada tasking won't work with the graphic front-end,
> no work-around possible, they tell me).

Well, X just plain has problems here (assuming you are using X).  But
even X works fine (as much as can be expected) with tasking built on
the OS threads.  For example, default GNAT on Solaris with X/Motif
makes multiple user sessions trivial with tasking.  I've done it.  If
the GUI has at least _some_ thread sense, then this will not be a
problem if you have any idea of how concurrent systems work.


> Not Ada per se, I understand, but the tools used with the language
> are important.

All sounds way out of date and irrelevant.


> Another thing about Ada that I deplore is generics.  A nice concept, but 
> when the same procedure has eight different bodies, it's a bit confusing 
> to debug (which body had the bug in it???).

Easy.  It is the name of the instantiation unit.  Trivial even in GDB.
Works fine.  Generics are actually very important for anything even
attempting to provide multiple setting abstractions.  They're in C++,
Eiffel, Modula-3, Clu, etc.  They are really passe' in this respect:
"everyone knows these things are vital in a statically typed language".


> Or optional parameters.  Ugh, I hate the concept.  To me, no
> parameter to a procedure should ever be optional.  At any time.
> But I guess that's just the neanerthal C programmer peeking out.

Misunderstanding.  There are no "optional" parameters.  There can be
*default* parameters, but not optional ones.  I suppose you can say,
"whatever", but this really is a big difference.


> That's what I'm talking about.  Not everyone can be equally good in
> both C and Ada.  Like me.  I program in both, but am infinitely more
> comfortable in C. The code I turn out is better, and I can do it
> quicker.  Forcing me to use Ada will produce results, but won't be
> as productive.

This argument is the only one you give that is semi-plausible.  There
really are good reasons why you would choose one language instead of
another, and Ada is certainly and obviously not "perfect for all
scenarios".  But the issues you raise are really irrelevant to this
question.  Things like, "I need a dynamic language here [Lisp or
something]", or "I need to have true vectorization of all this
computation [Fortran]" are the sorts of questions that really count in
this context.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com