Re: Is the Writing on the Wall for Ada?

[Marin David Condic <nobody@noplace.com>]

Jan Kroken wrote:
> 
> 1. A garbage collector
> 
> I know perfectly well that the Ada 95 standard allows for GC, but what
> does that help me when the implementation doesn't have it.  The
> argument against GC is that it's not desireable for realtime systems,
> but I have never written a real time system in my life, so why should
> I not have one? Solidarity?
> 

The problem seems to be that nobody wants one bad enough to want to pay 
for it. The subject has been raised here before and the usual response 
from those working for vendors has been "Our customers don't seem to 
care". Since GNAT is available in source, its possible someone could go 
cobble it in there and try to get it accepted for the general 
distribution, but again, nobody seems to care enough to do that. 
Conclusion: It must not be very important or someone would have done it 
by now. (Idea: Get together with everyone else who has ever asked here 
for GC in Ada and start a project to add it to Gnat. Chances are, if it 
can be enabled/disabled easily, it would be able to get into the general 
distribution. Why *wouldn't* ACT, et alia accept it if it can be 
disabled and it otherwise works reliably?)

> 2. Better organization on disk
> 
> The java idea of organizing packages in directories is really a good
> idea. Same with .jar files, and the CLASSPATH.
> 

I don't know what that means. Disk-stuff is external to the language. 
The compilation environment could organize packages any way they like 
and if somehow or other it is desirable to keep each package in a 
directory, that could probably be done. It sounds more like an IDE issue 
- and that could forever be debated just like "What is the best text 
editor for programming?". (Let's see if the emacs crowd will come out of 
the woodwork now! :-) The language can't really fix that. It would have 
to be a byproduct of your development environment and there you'd have 
to point a vendor at something specific and say "I want one that will do 
it this way..." If its a really good concept, it might make an 
interesting project to add another IDE for Ada - or modify one of the 
ones out there already.



> 3. OO
> 
> I know the tagged record thingie is considered OO, but that's just
> playing with words. OO as a concept is more than inheritance.
> 

It seems that you get more than inheritance with tagged records and 
packages. What did you want? (Is this the great "method->object vs 
object->method debate? :-) You have all the features you need to support 
full OO Programming from OO Design - just maybe not in the syntax you'd 
be used to. Realistically, it wouldn't be possible to perform major 
surgery on Ada's syntax to make it more like some languages that started 
out as OO Concepts. There's too much history and need for upward 
compatibility to go radically modifying the syntax in any serious way. 
You've got to take the good with the bad - the capabilities are there, 
but not necessarily as conveniently as you might like because of prior 
history. But a solution does exist. Practically speaking we can't just 
say "Ada would be better if only Ada were Eiffel..." - Trying to make 
Ada look like some other language just won't work and will only annoy 
existing users.



> 4. Dynamic strings
> 
> Dynamic strings, with proper library support. It's quite possible it's
> in there, but it's not coincidence that the example Ada programs I've
> read all seems to impose random limits, like line lengths of input
> files limited to 80 characters and such.
> 
See Ada.Strings.Unbounded. One might wish for more string-manipulation 
utility from the package, but all the basics are there. Most of the 
fixed-length examples you see are the result of history - Ada83 didn't 
have unbounded strings. Personally, I almost *never* use the fixed 
length strings anymore when programming for general use on a PC. You've 
got to read them in as fixed (for now - lets see what Ada0x does) but 
then I instantly convert them to unbounded strings. When designing 
objects, I may have parameters or function returns that are the standard 
type "String" because you sometimes need these as parameters to other 
"standard" routines, but that's just a quick call to To_String (X) or 
To_Unbounded_String (X) on the way in or out. But for any internal 
manipulation, I use only unbounded strings and am quite happy to do so.

MDC

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================