From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,88ed72d98e6b3457 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-17 05:45:34 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!newsfeed.stueberl.de!ecngs!feeder.ecngs.de!peer02.cox.net!cox.net!newsfeed2.easynews.com!newsfeed1.easynews.com!easynews.com!easynews!elnk-pas-nf1!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!newsread1.news.atl.earthlink.net.POSTED!not-for-mail Message-ID: <3F8FE466.60107@noplace.com> From: Marin David Condic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (OEM-HPQ-PRS1C03) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Standard Library Interest? References: <3F816A35.4030108@noplace.com> <3F81FBEC.9010103@noplace.com> <6Ingb.30667$541.13861@nwrdny02.gnilink.net> <3F82B4A4.5060301@noplace.com> <3F82F527.3020101@noplace.com> <3F846B5E.9080502@comcast.net> <3F855460.6020804@noplace.com> <3F86211B.103@comcast.net> <3F8640CA.6090306@noplace.com> <3F881515.4060305@noplace.com> <3F8E915C.6040003@noplace.com> <3F8F3986.7000107@comcast.net> <3F8F487E.80405@noplace.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 17 Oct 2003 12:45:33 GMT NNTP-Posting-Host: 209.165.25.167 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.news.atl.earthlink.net 1066394733 209.165.25.167 (Fri, 17 Oct 2003 05:45:33 PDT) mcondic@mindspring.com NNTP-Posting-Date: Fri, 17 Oct 2003 05:45:33 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net Xref: archiver1.google.com comp.lang.ada:1069 Date: 2003-10-17T12:45:33+00:00 List-Id: 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 ======================================================================