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

["Marin David Condic" <mcondic.auntie.spam@acm.org>]

Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote in message
news:3E19C980.6060902@cogeco.ca...
>
> 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 ;-)
>
That's because nobody wants to work for free and unless they desparately
need it for their own reasons, there's no incentive. The folks who build
embedded computers have stayed away from Ada in droves so they aren't going
to retarget Gnat for their own projects. Who else is going to do it unless
you pay 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.
>
Sorry, but I think I have proof that this won't work. First off, we're NOT
faster until "all other things being equal" becomes the case and compared to
C, C++ and Java, all other things are definitely not equal, are they? Then,
we've been selling higher reliability and lower life cycle costs for (let's
count them out....83, 84, 85...03) TWENTY YEARS now and it just isn't
gaining traction. (And before I get battered about the head and shoulders
with several standard sized jellyfish, I believe in high reliability and
lower life cycle costs and think these are GOOD THINGS - just not what the
general developer market is purchasing.)Why isn't it gaining traction? I
think the reason is because the market is buying Time To Market over Life
Cycle Costs and Reliability. (Good? Fast? Cheap? I think they're going Fast
and Cheap while Ada was concentrating on Good.)


> 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 ;-)
>
Yes sir. Very much so sir. And pretty much to my basic point: Ada *can't*
win out unless it provides more development leverage than its competitors.
You *might* build all those bindings if, for example, you had a library of
stuff that got 90% of your app done for you and all you had to do was glue
together the other pieces - but then you're just getting the leverage
somewhere else and making a tradeoff. But you're right - for those
developing apps that need an OS, GUI, Database, etc, they don't want to
spend time building bindings.


>
> 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.
>
See above. Superiority of the language/compiler has not sold for the last
twenty years and isn't likely to start selling soon. And a cautionary note
on bindings: That puts you in the "me too!" category and you're forever
playing "catch up" so you are forever at a disadvantage compared to the
native language of the thing you're binding to. You are much better off
defining something *different* that is within your control and offers
product distinction.


>
> 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".
>
I've made that observation before: Even if all the pieces exist, they need
to exist under one roof and in an integrated manner. Also, it would be
better if there were not 50 different choices for the same functionality
(How many container libraries are out there?) A package distribution would
be A Good Start, but how well integrated would it be? Its still a bunch of
odds and ends with questionable documentation and dubious interoperability
and no overall toolset that pulls the whole kitten caboodle together. Better
than nothing at all? Yes. Is that likely to get developers to start using
Ada? Probably not many - or at least very slow growth.

The problem here is that there has to be some kind of general endorsement of
whatever gets adopted by the vendors and user community. You personally may
write all of the libraries you like and you personally can put all of them
into the public domain if you like, but that isn't going to accomplish the
goal. It has to come from some authority to be accepted as "The Library" and
I just don't see anybody in that position jumping up to say "Lets Do It..."
(Yes, I know they're talking about containers, etc., for Ada0y, but for a
bunch of reasons this will never work as part of the language standard.)

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

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

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================