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: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?

I agree that nobody wants to do their day job for "free", but there seems
to be no shortage of people wanting to work on O/S, compiler and other
related GNUish things. So I would have to disagree slightly ;-)

I suppose once GNAT is better integrated into GCC, then any ports of GCC
to various hardware will hopefully imply an automatic Ada port to the
same.

...
>>>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. 

But, but.. this was my point... the "20 years+" of presenting the
reliability case has not worked because all _other_ things were
NOT equal. If they _WERE_, the reliability case might gain some
ground.  But the "20 years+" has not worked because the other
problem remained unsolved. If all other things are not near equal,
nobody wants to care about "reliability". They are too focused on
what they have to do (getting to market as you say).

To make the reliability case important, you have to provide all
of the other "prerequesit library support" first. Without this,
it doesn't matter what the other point is (reliability).

To conclude then, I don't buy the fact that reliability is
unimportant to people. What I see is that other people feel
that other factors weigh into the decision a lot higher than
reliability, and those then are factors that must be met first.

> (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.)

I believe that reliability is still important to people, but as you
have pointed, it is not on the top of the list. Reliability "weighs
in", but not as strongly as cost and time-to-market.

Most software shops (excluding possibly Microsoft), want to
ship reliable products.  But again, they have decided to
weight more in favour of "time to market".

>>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. 

Again, it might if the "all _other_ things" were equal. As long as
they are not, then I agree, that this will not always be enough
in its favour.

> 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.

I don't know if I buy this point. In a real sense the Ada.Text_IO
is a binding to the O/S whether it is a UNIX or Windows O/S or
some native Ada95 O/S.  Sure, the Ada.Text_IO is "me too!" --
we'd expect that every language provide some I/O support ;-)

I do see your point on the "catching up" with other binding
support. But until the binding support reaches "critical mass"
in supporting what developers expect to interface to today, there
can be little or no _new_ developments. Efforts are being spent
"catching up" instead. But I optimistically hope (perhaps foolishly)
that things may turn out differently ;-)


>>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. 

Yes.

> Also, it would be
> better if there were not 50 different choices for the same functionality
> (How many container libraries are out there?) 

I would agree, but having them all in one place would be a good start.

Natural selection may eliminate (over time) the cruft. What the distribution
needs to do, is to allow the user to uncheck those packages he does not
want to install.

> 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.

Agreed, that this collection would not be "cohesive" in terms of types
etc., but it would make re-use of the code a whole lot simpler. Even if
you ignore that, it would make installing your software much easier for
me to install, since I would just have to compile your software against
the "Ada distribution".

Without the distribution, I'd have to go fishing around the net for the
various packages you employed, compile and install all of them. And this
is a pain, but easily done by Ada people, but non-Ada types would just
throw their arms up in the air over this.

 > 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.

I believe that a failure to do this, would put Ada into the same
situation that Linux was once in, before 1994:

   - Pick up the Linux pieces
   - Pick up the GNU compiler
   - Pick up the sources to the various GNU/UNIX commands needed
   - compile the various components
   - assemble into an organized file system
   - integrate, integrate and integrate...

To make Ada more "friendly", you _must_ make the library support easier.
Otherwise, you are back to a piece-meal approach, which only works
for the die-hards.  I think that any Ada distribution would be a big
boost to the effort, and may help spur software development in
general. If nothing else, it may prevent people from having to
re-invent the wheel so often.

> 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. 

You have to allow time for that. Linux started out as someone's pet
project. But people saw the usefullness of it, and later eliminated
the piece-meal approach. This made it available to people who didn't
have the expertise or time to put a complete UNIX (like) system
together. Now, even grandmothers can run Linux (should they
choose to) ;-)

> 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

In my mind, its only necessary to make it easily installed as a
distribution. If someone were to keep this distribution up to date,
then this saves all of its users from having to do the same (they
only have to re-install the lastest update of the distribution now,
and recompile their own code). This is a valuable service.

GCC is not a standard, in and of itself. Yet it is hugely popular.
I remember being pleasantly surprised when I saw that it was the
native compiler for a DataGeneral machine I had to port to, a
few years ago.  If the "Ada Distribution" were popular, portions
of it might "leak" into a standard, which would be a good thing.

But it is initially only important that it become generally
accepted. This then could create the "defacto standard".

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