Re: Anybody in US using ADA ? New language competition? (long)

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

Marin David Condic wrote:
> Well, Ada's original requirements were targeted towards the embedded world
> and for a whole bunch of reasons, it went over like a lead balloon with the
> embedded developers. Partly because it initially didn't satisfy those
> requirements in practice. (Eventually, it got there but not after having
> created a horrible first impression and leaving a bad taste in the mouths of
> too many embedded developers.)

In its day, I could see why embedded people had concerns (Ada is still
a very large "language"). The largeness should not be a concern for
general purpose use - GNAT just flies through compiles on my 1.2Ghz
laptop. I can only image how fast it is on current technology.

The only general fault that I would state about the Ada95 _language_
apart from a few "warts", would be the complexity of some of the rules.
But then, I suppose, if you were to implement limited types (for example)
in a new language, you'd probably still have those same complex rules
under different names/circumstances. The freezing rules are a bit tricky,
and some of the visibility aspects are a bit tricky. I also think better
could be expected of "representation rules" as well.

> I don't think there is anything inherently wrong with the language and there
> isn't anything inherently wrong with its original requirements. 

I would generally support this (with exceptions noted above).

> However, if
> I was going to write a new set of requirements for Ada (or some new
> language) to meet, I'd spend some time talking to the folks who are not
> using Ada now and find out what they want most in a programming language.

I think we've discussed this before-- the real reason IMHO is the lack
of "library support". It is less an issue of the language, but more
about the libraries and bindings. Being that Ada95 is different than
C/C++, bindings come into just about everything (for both Windows
and UNIX) -- speaking non-embedded world wise.

Also a lack of a "generally accepted" container library (standard or
not), is also a "fracturing component". I myself find the Booch
components extremely useful, but many I suppose do not like the
complexities of the instantiations required to use them.

Is it possible that the generics in the _language_ needs to be
researched to make container libraries more elegant?  Or are the
implementations of these (Booch?) the problem? Or are we too
hard on the requirements?

> I'd bet (given the history of what is being bought out there) that
> development leverage would tip the scales in its favor. "Hey guys! Pay that
> initial investment in learning curve and infrastructure development up front
> and you'll be building apps in half the time you do now and oh, P.S.,
> they'll be portable across Windoze, Unix, Linux and Mac too!!!"

I think you could eventually sell Ada if the binding/library support
was there. If developers could find all the bindings to the O/S,
database, GUI and all that other cool Open Sourced set of libraries,
then it becomes only a matter of language choice. The reality is that
using Ada for general purpose work is still very much an uphill battle
on most of these fronts, because the developer must become expert
in writing bindings to existing libraries and often O/S facilities.

Portability might be enhanced with a _standard_ preprocessor (something
like gnatprep).

> Reliability, performance, maintainability are all wonderful and desirable
> things - but first you've got to deliver! 

THat is where libraries/bindings would be a great benefit.

> Ada's problem is that it has a
> history of promising how great its going to be one day, but doesn't
> deliver - at least not on time. By this, I mean that it has promised things
> like being good for embedded development and then taking years to get
> efficient enough to do it and not being targeted to nearly enough embedded
> platforms. People went with C because Ada just talked about how great it
> would be one day. 

Embedded systems have their own challenge, because they are very much
focused on efficiency with very limited resources.  On the GP scene
however, I don't believe this needs to be much of a factor.

> Same story now for workstation/PC development. One day, if
> enough bindings and libraries are built you could develop better GUI apps
> that are more reliable. 

Yes, that's it.

> But so what? C++ and/or Java are already there with
> their libraries and bindings. 

Yep, that is the _competition_ then -- the competition is at the library
level.

> Too bad that "One Day" Ada could do it better.
> People are picking their languages and platforms today - not "One Day". If
> Ada wants to win, its got to get out in front and lead the way with
> more/better leverage *today* rather than "One Day".
> Marin David Condic

I do believe however, that language/tool choice is becoming increasingly
critical in the GP scene. Consider this:

1. Assembly language was the language of choice for operating
    systems when hardware was slow, clunky in resource strapped. This
    was so in order to be efficient (mostly), due to limited choice
    of compiler technology and memory/CPU resources and needs.

2. People started to write O/S in higher level languages: C, Modula-2
    etc. There was still a need to be "resource frugal", but the higher
    level language was decidedly much more reliable, and saved time in
    development and maintenance.

3. Large software systems like the X-Window software was written in
    C, because it was available and efficient for the hardware of that
    time. It is still in C, primarily due to its age and "legacy reasons"

4. About the same time, we have various incarnations of unreliable
    Microsoft software also being written in C initially, although
    increasingly in C++.

5. The Internet: with it came the problems of security and virus
    and hacking threats. Users are sick of Windows unreliability.
    Also a fork into the foray of java etc.

6. Users/IT is sick of securing against network hacks. Still contending
    with "instability". Systems of all kinds are getting "huge" and
    built with an "unstable foundation".

<Present Time: 2003>

7. Recognition that software reliability requires that the compiler
    technology must be very rigid.  Two alternatives:

    i)  Form a consortium to design a new language/tools.
    ii) Recognize that Ada95/Ada200y is the best new tool for
        the job.
    iii)Fork off another Ada200x variant that is targeted to
        general purpose work, leaving the embedded systems
        roots behind. Clean up warts.

8. Build new foundations (O/S etc.) in this/these new language(s).

# 4, 5 and 6 remind me of the time when O/S were unstable because
of their assembler language roots. Now we have O/S that have
some instability due to their C roots (granted a great improvement
in some cases over the assembler counterparts). Now its time to
move past C into Ada (thinking optimistically...)

I like to think optimistically, that we are headed in the 7.ii or 7.iii
direction in the near future. We cannot keep buiding humungous
systems on unstable foundations. At some point, someone is going
to say "scrap the foundation and put something more reliable there,
so that we can get _on_ with building on top reliably".  How can
you build a tower if you have to keep patching the basement?

This even applies to the embedded world still -- I
can't believe the number of software bugs I have encountered
in my Kodak digital camera.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg