Re: Standard Library Interest?

[Marin David Condic <nobody@noplace.com>]

Stephane Richard wrote:
> 
> *** yes that would be a neat little insight to build on.  no doubt about it.
> Is this the only sure way to go in the right direction?  what do we aim with
> this library?  To have something that can put Ada back in it's fair share of
> the market, whether embedded or general purpose wise.  Am I right?  as a
> general statement of course. :-)
> 
The primary gopal ought to be to give the developer as much leverage as 
possible. The reason for that goal is to make Ada more attractive to 
select as the language of implementation on new products. It isn't the 
only thing that would make Ada more popular, but it is a significant thing.


> *** If I am right, then a simple comparison of the "popular" language's
> libraries and the ones for ada should be enough to elaborate a complete and
> detailed list of what's missing in Ada to at least provide the same feautres
> as the "popular" languages. no?
> 
It doesn't hurt to generate ideas. Looking at existing libraries (those 
provided by other languages and those that are provided separate from 
the language) The problem is that you've got to be careful not to put 
the cart before the horse. You may want a stack of ideas to present to 
the vendors & their customers so they could pick from the list what 
their priorities would be, but you don't want to start designing or 
developing until you have done that critical step.


> *** In that frame of mind.  We definitaly need libraries of all kinds, not
> just data structures like Charles, Mats Weber's Ada Component Library and
> the likes.  what's missing? as far as bindings are concerned?  well yes
> MIDI/Audio bindings (thin and more so a thick MIDI and DIgital Audio
> binding) for one.  in the same field, bindings to popular Linux Sounds
> architectures like ALSA woudl be a good idea too so that Ada developers can
> exploit those fields of development.  We have Engine_3D, AdaOpenGL, AdaSDL
> for the graphic side...how about libraries of 3D animated graphics?  usign
> those bindings so that they can be exploited too.  We got APQ right now for
> a Database BInding, it's getting pretty good too.  But there's more to be
> done, and Database in the industry is a must and should be considered.
> There's no way that these ideas wouldn't help the outcome of the library
> itself because they are sought after features of the "popular" languages.
> 
Yes, libraries to cover all sorts of programming needs - not just data 
structures. But a) Data structures are what you're going to build the 
rest of the stuff on top of, so its an important foundation and b) you 
have to be careful not to get too ambitious and kill this with too much 
work.

Here's a few relevant points:

The ARG may get around to sticking some sort of container library into 
Ada0x. If they do that, we'd be wasting our time implementing something 
else or implementing anything that might be using containers. Better to 
find out what is likely to happen with the ARG *FIRST* before writing a 
single line of code.

If you get to grandeose in the list of things to implement, it divides 
the attention and nothing will get done. Pick *one* thing to build as a 
first step. The rest of the list can be kept in your back pocket for 
when you've got something successfully built and in use. Given that it 
is not intuitively obvious to even the most casual observer what that 
one thing should be, you need to have the ARG/Vendors *tell* you what 
they want first. (Containers? Math? Network support? What isn't going to 
be in Ada0x and what is next on the vendors'/customer's wish list?)

This is why I keep harping on the need to have early involvement by the 
vendors. If they *won't* tell you what they want or they *won't* accept 
what you build, you're going to go off and build a million lines of code 
that nobody in particular wants and its not going to accomplish 
anything. I don't have that kind of spare time in my life to waste. I 
want to make sure that if I *do* put forth some effort on this, that it 
stands a chance of succeeding.

> 
> *** well since we do aim to have the library distributed with the compilers,
> we'd definitaly need some feed back from the vendors.  No doubt about that
> either.  we need to know from anyone (vendors and/or organizations) that
> we're heading in the right direction.  but my first guess is that if we give
> Ada what it's missing when compared to the "popular" languages.  It would be
> hard for anyone to say we're not on the right track.  If not sooner in the
> library's development then later but these missing features should
> definitaly be implemented.
> 
But what is available in other languages (like C) is a *huge* amount of 
territory. The sheer magnitude of it is part of what makes it "popular". 
  What customers are buying is the hugeness - in part. So let's think 
about this: In order to provide Ada users with what makes other 
languages popular, we have to develop a million lines of code. After 
devoting a few man-years to the effort, we find out that the vendors 
have no interest in the library because it doesn't meet their 
expectations. We've all quit our jobs and built this thing on 
speculation and are in divorce court over it, and the vendors don't want 
it?????

That's why I'd refuse to write so much as a single line of code until I 
knew there was an interested customer out there. We're not talking about 
just a linked-list package here. Its got to be ***BIG*** to be useful 
and unlike a linked-list package, ***BIG*** is going to take more than a 
handfull of evenings and weekends to build.

Note that Boeing doesn't just start building 747's "On Spec" and 
inventory them while waiting to see if any airlines want to buy them. 
They don't even start the engineering on a 747 without first talking to 
the airlines about what they're likely to want. You don't throw time and 
money into a big project without *FIRST* getting the customer on board 
with it.



> *** and that's just as far as libraries go.  There's other parts missing as
> well.  At least some parts that need fine tuning at least :-)....Ada Core
> Technologies has GPS which seems to be a good all around Ada IDE that seems
> to integrate a good set of features expected in an IDE, but perhaps there 's
> more that could be integrated.  and other tools (aplications) that could be
> developed to give ada developers even more flexibility and integration as
> per Ada and related technologies.
> 
There's a whole lot of stuff that it would be good for Ada to have. 
However, what you're talking about here is what software companies would 
view as a whole product line. I absolutely am not against developing a 
whole product line. Libraries, GUI builders, IDEs, Developmental 
Tools,Operating Systems, End-User Applications, etc. But I have to 
*work* for a living and this is too much to consider on any sort of 
part-time, uncompensated volunteer work basis. I also am not going to go 
about doing fine quality engineering work for the benefit of some vendor 
as a "charity" cause - I'll go work in a soup kitchen and give my 
charity to the poor.

Beyond getting something started, this job becomes *WAY* too big to be 
done strictly by uncompensated volunteers. It will need some kind of 
funding, but as I've observed, that need not be a huge amount and there 
might be ways of making it pay for itself. But until you discuss that 
with the potential "buyers" you have no clue and you're setting it up 
for failure.

How you fund it is an open question, but I think if the vendors don't 
want to pay for it outright, they need to consider some other form of 
"back-end" compensation. See Robert Leif's "Ada Developers Cooperative 
License" articles in Ada Letters and some of the related things on 
http://www.softdevelcoop.org/ This may not be the ultimate answer, but 
it provokes some ideas about how the development might be funded with 
payment coming to the developers after it is actually successful.




> 
> *** I can't help but agree that sooner or later, the vendors will have to
> get busy with this project.  at least the ones that do plan on moving to
> Ada0X :-).  They'll need to step in for two reasons.
> 

***!!!SOONER!!!*** not "Later". If you wait until later, you are a) 
going to waste lots of time and effort doing things you shouldn't be 
doing and b) set the whole thing up for failure because you didn't do 
what the vendors wanted.

I won't stop anyone who wants to go off and build a library on 
speculation. I'll just give odds and take bets on its ultimate success 
and make a pile of money when it fails. My advice would be: "Go ahead 
and do the job - but be sure to do it in a way that optimizes the 
chances of success." That means getting the vendors involved early in 
the game.

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

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

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================