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

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

Marin David Condic wrote:
> Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote in message
> news:3E15CF31.1020900@cogeco.ca...
> 
>>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.
> 
> Back when Ada was first emerging, compilers were generating really crappy
> code and if a compiler worked at all, it almost certainly wasn't targeted to
> your embedded processor. If by some miracle it was, the large overhead could
> kill you. Assuming you also had the tools needed to get an executable image
> into the target - which would be a rather rash assumption at the time.
> Things eventually got better, but not before validating everyone's
> prejudices and guaranteeing that Ada would never get considered by a large
> segment of the population.

I guess this problem exists even today for certain processor models. I think
of a small single chip CPU like the Motorola MC68705 where you may only
have 2kb worth of EPROM to place your code in. Its difficult to imagine
much Ada95 code compiling into 2k, but that is not to say it couldn't be
done. Its a stretch even for assembly code, depending upon what it must
accomplish ;-)  I havn't worked with the PIC chips, but there again, I
suspect that it would be a challenge.

But surely for larger processors, it is simply a matter of vendor
support (and market).

> Things have gotten better today but Ada still fails in the embedded world
> for a variety of reasons. Sure, you can get good quality compilers that
> target some of the larger processors in use today and you might even find
> enough support tools to make the job relatively easy, but there are still
> lots of tiny processors out there that Ada doesn't (and arguably, can't)
> target and in general, Ada is pretty much totally ignored by the embedded
> world. (A few notable exceptions out there - including myself.) So if Ada's
> original requirements were aimed at satisfying the needs of embedded
> development, it seems to have failed in that market. Did it fail because it
> failed to satisfy *real* embedded requirements or did it fail for other
> reasons? (Political, social, environmental, etc?) Probably a combination of
> both.

Free compilers might give it a chance... but part of the problem is that
I don't see enough Open Sourced Ada enthusiasts chomping at the bit for
a project like this ;-)

>>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.
> 
> If Ada woke up tommorrow with everything in it you describe above, it would
> meet the general reaction of "Gee. That's interesting. C/C++ have had this
> for years and we're already heavily invested in those technologies. What
> else have you got?"

The "what else have you got?" I think can be explained in the way of
the compiler and language benefits (all else being equal). Ultimately
the siren song of lower total costs and faster to market sell.

But if the Ada95 user has to start building a database binding, a GUI
binding and an O/S binding just to get started on the _application_
(that is supposed to bring the tangible real benefit), then he's
going to sigh and give up. This leads to taking a path of lower
resisitance, no matter that it may be the road to hell ;-)

> The problem here is not that Ada shouldn't strive to have those things, but
> rather that these are just the entry price needed to even get in the game.

Agreed.

> Its not enough to be able to supplant someone's heavy investment in other
> technology. Whatever Ada does, it needs to become *better* than other
> languages out there or nobody has any reason to want to switch. 

If the libraries/bindings were there, then the differences _would_ be
at the superiority of the language/compiler. The problem is, that no
one cares about this issue because X or Y is not available at the
library support level. This is seen as a more fundamental requirement.


> It might
> even be necessary to rethink all of the library & binding stuff to do
> something totally *different* or Ada is just another "Me Too!!!" player that
> is going to be ignored because it will *never* be as good at binding to
> something as the language the thing is written in (Unix, Motif, etc.)

I don't see this as an issue. Java has all of these same issues, but
people look past this because it is "new" and is considered "the
thing to do(TM)".

> I'd say pick one and start enhancing it. 

Well I have picked the Booch components for my work, but that hardly
does anything for the rest of the community ;-)

 > We can argue all day long and into
> the night about what is the best way to ultimately come up with the
> "perfect" container library. 

Agreed.

> Doing that will insure we never have one. 

Yep.

> Grab
> something as a model, get it under a tree that can be easily expanded to
> include new things for different problem domains, build a reference
> implementation and share it with all the vendors. That would get something
> in use and start providing leverage for the developer.

That would be a good thing. Another workable approach is to get an
Ada package distribution going. I can't start one yet, but if I
find enough time, I may. I see this as being important. Right now
to compile any major Open Source project requires the end user to
download this, that and another package from this, that and another
web site in shopping cart fashion. THe poor user must then get them
all compiled and installed correctly. If all goes well, he might
get your project compiled and then installed correctly. I see this
as a horrible way to introduce C/C++ types to the "Ada way".

Mind you, this type of thing is done in the C/C++ world too, but
often times the Linux/*BSD distributions have already done the
bulk of the work for you. If not, then a "make install" does the
rest.

How many Linux distributions do you know that include the Booch
components or Florist installed as ready to compile against
Ada packages/libraries?  We are missing the boat here.

>>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.
>>
> 
> Agreed. And disagreed. As noted above, you need the bindings just to be a
> player, but I think you've got to offer something *more* 

Again, I think the "more" is the language benefits that are often
espoused here. But if the "other" is not equal or better, no one
wants to talk about the language features.

> than just that to
> sway someone away from what they already use. Also, I've never liked Ada
> bindings to C libraries because while it is technically possible, itr always
> feels like an unnatural act and demands that the Ada developer think like a
> C programmer. It would be better if Ada could go down its own path and do
> something new/different that got the same net effect as bindings might
> produce, but do it in a way consistent with Ada and offering a *better*
> answer.

I advocate thick bindings to O/S and other features (MOTIF etc.) Anything
less, is a nightmare in Ada (agreed).  Certainly the thick bindings can
build on thin bindings, but only the thick bindings should be used in
application level code (IMHO). The reality at some levels however,
is that some O/S features may not map that well. But I still see thick
bindings reducing this to a minimum.

>>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.
> 
> Really? We're here talking about how great it will be one day when Ada
> provides libraries and bindings and all that. Where are they? 

I am not sure what you are reacting to here, but basically my statement
was meant to convey the idea that for general purpose programming, there
doesn't need to be any Ada "issues" (save for the bindings/libraries).
Compiler availability, and fast CPUs eliminate much of the "compiler
issue". I didn't state this well in the above paragraph ;-)

> By the time
> Ada succeeds in getting some of the useful things already found in numerous
> other languages, the world has passed it by once again. Something needs to
> be done with Ada to institutionally/culturally get it to react faster to the
> marketplace or it will always be in "catch up" mode chasing the leaders
> rather than *being* the leader.
> 
> I like Ada and want to see it succeed, but efforts need to be focused on
> leapfrogging the competition if this is to happen.

Well, let's get a group to organize an "Ada Package Distribution". I may
be forced to do it myself, but I would rather spend my free time on
developing Open Sourced Ada applications, if possible. I have already
booked my free time for the next forseeable 6 months. I have even hatched
a name for this distribution, which I would gladly give away to
someone/group that would take on this worthy cause ;-)

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