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,60e2922351e0e780 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-11-20 10:01:41 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!cyclone.bc.net!news.uunet.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: Re-Marketing Ada (was "With and use") References: <3FB0B57D.6070906@noplace.com> <3FB22125.1040807@noplace.com> <3FB3751D.5090809@noplace.com> <3FB8B9BC.5040505@noplace.com> <3FBA1118.4060105@noplace.com> <0fxub.48425$bQ3.12107@nwrdny03.gnilink.net> <3FBB6527.4040702@noplace.com> <3FBCBA38.8040000@noplace.com> In-Reply-To: <3FBCBA38.8040000@noplace.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <067vb.13803$iT4.1718658@news20.bellglobal.com> Date: Thu, 20 Nov 2003 12:47:13 -0500 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1069350396 198.96.223.163 (Thu, 20 Nov 2003 12:46:36 EST) NNTP-Posting-Date: Thu, 20 Nov 2003 12:46:36 EST Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:2752 Date: 2003-11-20T12:47:13-05:00 List-Id: Marin David Condic wrote: > Warren W. Gay VE3WWG wrote: >> I have never had a problem with multi language projects. This >> only becomes a problem when impedance mismatches occur on >> interfaces and objects, in my experience. >> > Yeah, but if your compiler is C and all the libraries in your problem > domain are C and your operating system is C and all your de3velopment > tools are in C and all your programming expertise is in C, it gets > *really* tough to argue that it is economical to do some project in Ada. > Everything that diverges back to some other language is another reason > to avoid Ada. Hence, the effort should be to make Ada as capable as > possible to remove the impediments to using it. I won't disagree with this. But let's reduce the impedance mismatch, to make the decision a path of lower resistance ;-) >> If all I had to do was add a Makefile command: >> >> adagen freds_fft.h >> >> to generate a thin binding, in a consistent and >> portable way, then I'd have mighty little resistance >> to using Ada in a given project. > > Yeah, sure, there is nothing wrong with having an automatic translator > to help you get a binding. I'm not against that. I just don't think it > is a) the final answer, b) the best answer or c) the answer that is > going to persuade C hackers to come over to Ada. a) agreed and this was acknowledged up front b) again agreed (see a) c) this is a different hurdle, and I don't disagree Again, the purpose of my point was to wear down the opposition. The point is right now, even if you manage to "sell Ada", the path is too narrow for most to jump in. You can get people to learn a new language (this can be fun, if you're not on a deadline). But my point is that if they realize that 95% of their libraries must be left behind or that they have to build bindings in order to use them, they'll balk at this even more. I think this is the killer (we have already talked about the need for bindings/libraries earlier). > It *still* comes down > to "I've already got everything I need with C/C++ so why do I want to > add effort and expense to my project by doing some part of it in Ada?" > There has to be some really compelling reason to do that. No argument there! BUT, if we stop right there, then Ada has lost, will be lost, and has no hope. What I am suggesting is to make it easier. The only hope I see is the following general path (by no means the only and extensively documented one): 1. C/C++ folks need to start using Ada, but how? Make it easier to use the libraries they already have. 2. As people climb on board, more bindings and thick bindings become available (the catch up phase). 3. As the world switches over to Ada, having recognized its great benefits, more development starts to be in Ada, without starting in C + binding (C libraries start to lag). 4. New Ada friendly operating systems (or "Ada O/S shells") make it a friendly world for GP Ada work. Now I know that all of this sounds like pie in the sky. So maybe I have just admitted defeat as well :-( > Consider that if Ada had some really spiffy library that did some > wonderful things for a given problem domain and that this was a major, > new advantage over C++ in some way. Then someone says "I want to use Ada > to gain access to those features." C/C++ probably won't bind to Ada real > well - or at least they'd need to develop a binding in Ada that reduced > things to a level that C could handle. (Give the caller all sorts of > pointers instead of the data, etc.) So now you've got a good economic > reason why someone ought to do some part of their development in Ada. At > that time, the ability to bind to C becomes an asset to them. But that only works for the problem domain(s) that your spiffy new library addresses. I think we need to find a more general solution. >> The tough sell is when you have to report to management that >> it will add 3 weeks of work to build a binding to Fred's >> FFT routine, in order to use Ada. Project management will >> then ask, "can it be done in C/C++?" As soon as you answer >> affirmative to this, in the GP (non-embedded, non safety >> critical) world, the project management answer will be to >> use C/C++ instead. Bye bye Ada! >> >> If instead, you don't have to add those 3 weeks to the >> project schedule, project management might even encourage >> the use of Ada, if it even cares. Alternatively, you >> might not even have to bring it up ;-) >> >> For Open Source developers, I think this can make a difference >> too. Everyone has a limited free time, unless you have >> just won the lottery (but then would you still be coding? ;-) >> > > Ada has traditionally focused in on life-cycle costs and the problem is > that for *most* development situations, the whole life cycle is > irrelevant. Exactly. Day to day business is more concerned with quick turn around. They pay lip service to the other, but they never ever DO it. So this is why, I think, we need to make Ada more C friendly. > Its the Time To Market that is critical. Yes. Don't give them (project management) the excuse that Ada prevents the job getting done quicker. > Development > projects have to get done *Quickly* in most cases because getting there > first means market dominance or (in the case of spare-time developers > and some other projects) there is limited budget to get the project to > completion. Hence, Ada ought to do something to try to add that > leverage. Show your garden variety C++ programmer that he can get his > job done in half the time (and have lower maintence thrown in as an > added bonus) and maybe you've got something he is willing to look at. > > MDC To do this, you need to make it easy for the C++ programmer to use what he already has. Eventually he will migrate away from what he has (if he gets sold), but initially that is an important investment he cannot turn is back on. Ada asks C++ people to "bet the farm" to switch. You shouldn't be forced to make an all or nothing call on language choice. But the reality is that the decision _is_ in fact often made at this all or nothing level, due to the lack of standard interfaces between Ada95 and C++. Maybe we've missed the whole point altogether? Maybe we should have put a major push through Ada0Y to be C++ compatible, in a PORTABLE way. A consistent set of pragmas and conventions to make C++ interfacing less painful. But even if you do all this, you still have the pain of getting C/C++ macro constants into an Ada program for use. This is what I envision thinbind to be all about. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg [Remove nospam from the email address: the worms made me do it!]