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-21 10:28:45 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!in.100proofnews.com!in.100proofnews.com!snoopy.risq.qc.ca!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) 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> <6lijb.140205$%h1.139381@sccrnsc02> <3F8E9531.9040209@noplace.com> <3F8EDB1A.1010007@noplace.com> <3F914520.9080906@noplace.com> In-Reply-To: <3F914520.9080906@noplace.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <8Pdlb.4756$7t3.157424@news20.bellglobal.com> Date: Tue, 21 Oct 2003 13:14:08 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1066756420 198.96.223.163 (Tue, 21 Oct 2003 13:13:40 EDT) NNTP-Posting-Date: Tue, 21 Oct 2003 13:13:40 EDT Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:1308 Date: 2003-10-21T13:14:08-04:00 List-Id: Marin David Condic wrote: > Warren W. Gay VE3WWG wrote: > > > > I guess our faith is in the different parties. ;-) > > > > You are willing to trust that the vendors will get things going. I am > > too skeptical/cynical to have that kind of trust, beyond anything > > more than the GNAT.* packages. > > > No, I *don't* trust them to "get things going". That's why I'm nagging, > complaining, whining, pleading, etc. I expect that people with support > contracts with various vendors might send them a note saying "I want a > Conventional Ada Library that does X, Y and Z..." A lone voice crying > out in the wilderness occasionally can have an impact. :-) However, I > doubt I'm alone. OK, I phrased it wrong. You trust in the nagging of users to the vendors to help push it along. I'm not criticizing; just trying to boil the point into its most basic elements. ;-) BTW, I finally received my printed copy of the Ada Letters last week. Good work on the article. > As for the GNAT packages - that might actually make a really good start > for a Conventional Ada Library. There is visible evidence that ACT is > out there actively enhancing their Ada product line, so they would be > one of the vendors most likely to do something with a CAL. Are any of > the other vendors doing anything with their Ada product lines to enhance > them? Or are they just selling what they've got and sitting on their > hands, so to speak, with any new development? If ACT was the only one - > or perhaps the dominant one - then making ACT happy would be key to > success. Starting with what they've already got would be a good way to > do it. There seems to be several good indications coming from ACT. One of which is the support of the Win32Ada binding that comes with the Windows port. The other is that I noticed somewhere that they have accepted the maintenance of FLORIST, for which I was able to successfully submit a bug report (that did not bounce ;-). Both of these two areas alone are big areas of maintenance. So kudos to ACT for taking these progressive steps. This level of support may push other vendors into doing something similar. > > My faith is more in the development side. *WE* have the invested > > interest. *WE* can more easily *do* something. Vendors have to > > budget, plan and justify. Vendors are less likely to do "extreme > > programming"/skunkworks type of things to see if an idea will fly. > > > I didn't say that *WE* wouldn't necessarily have something to do with > it. I know that. Don't be too sensitive ;-) > What I said was that the vendors need to be involved early on in > some manner or whatever *WE* do is going to be a waste of time. I just > absolutely, 100% see a total of ZERO evidence of any of the existing > library attempts getting to any sort of point of "general acceptance" > that got the vendors interested in packaging it with their compilers or > got the ARG to declare it "Standard Ada". Apart from standards and the ARG, what about Win32Ada and FLORIST. I do believe that _some_ evidence does exist. FLORIST was started outside of ACT, though I don't know about the Win32Ada binding. > Yet there have been dozens - > or more - attempts to get various libraries of stuff started. What > evidence do you have that starting Yet Another Library Project is going > to meet with any better success unless you do something strategically > different this time? How many competing designs where there for the Ada language, before one was "accepted"? For a container library, I think there is room for several attempts before getting it "right". After all, Ada programmers are much fussier about the quality and the design than in other languages. I think one needs to leave room for evolution and experimentation. Eventally, an emerging accepted defacto standard is bound to emerge. I think, you would agree that we would like it to happen a little sooner, that's all! > Sorry if I sould "angry" - I'm not. Just excited. :-) Thats OK. We could use some excitement here. ;-) > I'm trying to get > across the point that if we really want a library effort of some sort to > succeed, we'd better look at all the ones that have "failed" in the past > and try to make a different set of mistakes. You're not the firt one to > get charged up and say "Well, lets go start writing a library..." I'm > suggesting you look at why the other efforts failed and figure out a way > around that. I'm all in favour of examination of historical attempts. I mean, why invent yet another of the same thing that failed. But based upon the discussions that I have seen here, there seems to be a lack of concensus about what it should be. Another factor now is, what "could there be?" after Ada 200Y is adopted? Once some of the issues have been solved, and the enhancements added that deal with interfaces (and/or MI) are in place, this could substantially change the landscape for such development. For many projects, this shouldn't matter, but for a container library this could be "key". So, I would suggest, let's attack some of the problems along the way. Some of the larger problems may become easier to solve later. Bug the vendors for sure, but don't entirely depend upon this. I have always taken the approach of learning from doing. So I would not discourage people from trying something new. Many projects may end up as throw-aways in the end, but that does not mean the effort is a wasted one. You seem to be worried about wasted effort(s). But people learn from these projects, and they should be regarded as research projects rather than wasted efforts. In the corporate world, this becomes harder to justify, but R&D is still required there also. We just don't hear about all of the discarded projects in IT, but you can be sure that lessons were learned (or should have been). ;-) > > *WE* don't have to answer to anyone (as open source/hobby). That > > allows us to do R&D, where the vendor (and/or our employer) would > > have trouble with. > > > Yes, but just recall all the other various and sundry "Open Source" / > Volunteer oriented projects of any stripe that get started out there. > (Should we start a list?) As I've pointed out earlier, a failed project is never completely a failure. Someone/people have learned lessons from those undertakings, even if it is just to understand their own level of commitment ;-) > I'd bet that if you actually surveyed, you'd find that 90% of them > colapse before they ever produce anything at all useful. How many mutated species survive? Do these numbers matter? I think you are concerned that Ada resources are thinner, and so you don't want to see that resource wasted. A valid concern. But a certain amount of this so called "waste" is a necessary part of any R&D. > The remainder > might make something that works, but that it is mostly produced over a > *very* long stretch of time and that it really doesn't take on the > qualities of a "Finished Product" (more like some kid's sience fair > project, usually) until there is some commercial effort out there making > money on supporting it. This is true. In the book the "Mythical Man Month", the author points out that it takes 9 times the "in the garage" effort, to take a project from one small program, to integrate it into a system of programs and to make it a finished product. Most projects take a long time to reach that point, if ever. Agreed. But note the word "most". > The few that get "Commercialized" might start > reacting fairly well and at reasonable speed to perceived needs, but it > takes them a really long time to get to that point. Even commercial products can take eons to reach that polished state.. some never get there ;-) > What is in your plan to start building a library that is going to make > that different? Well, I think that multiple teams could be assembled (resources and interest permitting), that could address a critical need. Like the Ada language competition, I think that something could emerge. > > So, yes, you're right. I would favour "organize an effort", rather > > than pleading with vendors. ;-) > > > Please go right ahead. I'll watch the effort from the sidelines. I'd > love to see you or anybody else get a library together that won some > kind of acceptance from the general Ada community and got some kind of > interest from the vendors and eventually had some sort of official > standing. I'm just betting it won't work - and I'm not a pessimist by > nature. I've just seen it fail too many times in the past to want to go > off and make the same mistakes all over again. At least, let's be > creative and make some *different* mistakes this time. :-) I am in favour of doing "different mistakes". There is nothing gained by repeating what we already have, unless you are trying to avoid a copyright issue. I'd be willing to participate as a member of a team in some capacity, but I am already overbooked with 3 other major open sourced projects at this time to do any more. Will my work be accepted? Heck if I know, but I am doing this to scratch my own itch, and hope in the process it will scratch a few other itches out there, in the process. Perhaps I need to take a different approach, and organize group efforts. For the container library, IMHO, we'll probably want to be patient with that one. Given that it's too late to affect the 200Y standard, it can also wait until 200Y is settled. From what I saw in the Ada Letters were some interesting issues, that could give any new container library effort some nice new options to work with. > Or maybe you have a *different* plan? Something other than an > all-volunteer, open source, free for the world, "Let's all get together > and build something good & wonderful for Ada and give it away hoping it > will be adopted by everyone..." effort? I'd like to see the plan, if > that's the case. > > MDC Well, I don't really have a plan (shrink), other than what I've posted in earlier posts in this thread. You raised some interesting ideas in your Ada Letters article, which might work. It would be nice in fact, if that would work. Maybe I am showing my own skepticism here, but I think for that to succeed, you'll need some Richard Stallman type that is willing to lead that charge. It will take a strong minded, vision incensed person to make sure that it is realized. Are you leading that charge? Perhaps you are holding out on us? ;-) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg