Re: How come Ada isn't more popular?

[Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>]

Charles D Hixson <charleshixsn@earthlink.net> writes:

> Markus E Leypold wrote:
>> Charles D Hixson <charleshixsn@earthlink.net> writes:
>>
>>> goes on.  I, personally, think that one factor IS the lack of a
>>> standard garbage collector.  Related to this is the awkwardness of
>>> dealing with strings of varying lengths.
>> Actually that is rather good compared to C or C++. The different
>> string package s make it possible to often use stack allocated storage
>> only or get the comfort of unbounded strings. After a while I really
>> started to like this.
>>
> Note that "After a while"?  

Yes. I couldn't decide at first when better to use Fixed and when
Unbounded strings. The problem got aggravated by my attempts to stay
minimalist and use fixed string where ever possible and also where
impossible. The insight that some algorithms are better not performed
with bounded buffers took a while to take hold.


> The first hour, the first day, the first week, and the first month
> are the most important for forming lasting impressions.

Yes, but it's not the "impressions" that count. I came from Pascal
background (after learning programming in BASIC and assembler) and
looking at Ada was love at the first glance -- as far as languages of
that family go. I often thought: Wow, there is a design decision where
everything has done right after a lot of thinking and not decided in
an ad hoc fashion.

I hope I'm not limited to my first expressions, though.

> I still remember the extreme frustration I experienced the first
> time I tried to print a string...it was an unbounded string, and I
> hadn't used Ada.Text_IO.Unbounded...and I didn't have anyone I could
> ask "What does that silly error message MEAN!?!?"

 :-). Fun, yes. The error messages of GNAT(e.g.)  are sometimes less
 than helpful. Fortunately I always had my copy of Barnes' book with
 me and from C/C++/SML etc I learned to compile often and morph
 programs through syntactically correct intermediate stages. So that
 couldn't trip me up too much :-).

> It's easier to do simple things in Fortran, C, Pascal, Modula II, PL/I
> or even Snobol.  Oh, yes, and BASIC, too.  (The other current

It's easier to do simple things with languages that have lists in
them. E.g. Lisp or Scheme (or Python for today programmers). No, I
disagree: It's not even easy to do simple things in C: Every time I'm
astounded by the contortions I've to go through for anything involving
strings of varying length (OK, I can work in large statically
allocated buffer, but this simply stinks, since it imposes arbitrary
limits). And very soon the wish comes up not to have to write out
specialized list processing code every time for 'list of ints', 'list
of floats', 'list of strings', 'list of lists of strings', 'list of
trees' etc -- and than you start to suffer and it never ends. There is
no way to write generics in C, to fake them or even graft them onto
the language as an afterthought and use a precompiler or a
preprocessor (I'm perhaps exaggerating here, but the pain is there
nonetheless. I've written those things (a generics "expander" for C
:-) and I think/hope I know about what I'm talking here).

> contenders weren't around then, I never learned Cobol, and it isn't
> easier in any assembler I ever learned.)

Well, that what all my recent posts to this group try to assert: That
there are languages beyond assembler (including C) and the pascalish
family (including Ada). Of course I'm posting to c.l.a. so I know that
this might develop into flame bait. But it wasn't me, starting to bash
C (It was J R Carter :-), and when we start to discuss the respective
merits and dis-merits of various languages than we can as well go the
whole way and accept the fact that development has not stopped with
imperative compiled languages. I'm also pining for the days when I
almost understood everything the compiler did and there was no VM and
no JIT and no whatever-optimization. If you're a control freak like
me, you just feel better if you understand everything at least in
principle and can say things like "this statement/call expands to the
following instruction sequence but ..., so if you compare you can ..."
and if you can -- in principle -- recreate your own tools (which is of
course an illusion). 

But those days are long gone and, if I think about it for a moment,
good riddance. Give me a modern functional languages with lot's of
complicated types and katamorphisms every day. I finally want to get
things done -- and I suggest to compare e.g. haskell.org or Jon
Harrop's demo source for OCaml with the list of "free projects" on the
ACT site (or where ever ...) and moreover the scope of ambition of
those projects and I'm starting to anticipate what an expressive
language can be. 

Let me put it like that: Trees and graphs are fundamental models in
computer science, mathematics and finally document processing (XML
...). An expressive language supports to manipulate those easily
without much ado, without wrapping objects or iterators or factory
patterns around a simple concept, without the need for explicit memory
management, preferably by recursive functions which are the natural
form of expressing a transformation of those structure.

How does Ada stand there? How does C? Both bad. Fixing the argument
(Why/where does Ada fail?) on C vs. Ada misses an important
point. Both languages are relatively good in shoveling bits from one
place (bus, memory, ports, interfaces) to another and doing not too
complicated things to those bits.  But that is not where the real
interesting things happen these days.  Say, in example, "scene
graph". Can you feel the complexity :-)? Do you want to maintain it
with explicit pointers and memory management in an imperative fashion?
I don't.

But whatever - YMMV (that applies to everyone on c.l.a. :-)

Regards -- Markus