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=0.5 required=5.0 tests=BAYES_00,TO_NO_BRKTS_PCNT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,984e922902f4f4ee X-Google-Attributes: gid103376,public From: "Marin David Condic, 561.796.8997, M/S 731-96" Subject: Re: Can Ada by popularized faster ? Date: 1997/10/13 Message-ID: <97101310590185@psavax.pwfl.com> X-Deja-AN: 280218263 Sender: Ada programming language Comments: To: bpr@shell5.ba.best.com X-VMS-To: SMTP%"INFO-ADA@VM1.NODAK.EDU" X-VMS-Cc: SMTP%"bpr@SHELL5.BA.BEST.COM",CONDIC Newsgroups: comp.lang.ada Date: 1997-10-13T00:00:00+00:00 List-Id: Brian Rogoff writes: > >Seriously, for Ada to succeed it should have a niche; looking for a killer >app to propel it forward is improbable. I like your SBC idea, but that >market seems controlled by C now (is it?). Where would you propose >focusing a development effort to dislodge it? > Well, the killer-app idea isn't necessarily totally improbable. For example, there is AdaSAGE which provides a database developed in Ada and is in the public domain. (it is, isn't it?) If a compiler vendor were to glom onto it, put some helpful glue software around it to make it easy to use in their environment, the product becomes instantly more attractive. If someone used that to build a nice desktop application - like an address book or calendar or whatever - which caught on because it was inexpensive or did something real unique or was easier to use than other products - there's where you might get a market generated for add-ons. Database apps are real good for that because once someone has invested all their data in a particular format, they are naturally going to want additional capabilities not provided by the original tool. (Lots of folks build add-on software that depends on Oracle being out there, eh?) As for the SBC idea, I'd have to say my impression is that C pretty well dominates there. But think of this: Out there somewhere you've got GNAT available and the GCC back end is supposed to be pretty easy to port. Building the port of the back end would give you the ability to provide Ada, C, Fortran and maybe a bunch of other languages for your target. (Think of the sales pitch: "Sure, we think Ada is cool, but if you need language X for some subset of the system, we've got the compiler and Ada can easily connect to it!") Then there's the RTEMS RTK available so you have runtime support on a bare machine. And you've got GDB available as a starting point for developing a debugger. Oh, you've got some holes to fill, (linkers, realtime monitors, debuggers, etc.), but it's not like you're starting at bottom-dead-center. So probably 80-90% of an embedded development environment already constructed for you. It's just got to be pulled together, retargeted and made into a seamless, easy to use tool. (As an embedded developer, I havn't got the time to fool around with integrating a bunch of stuff I've pulled together from 50 different places. I just want to buy an already integrated environment and get started building my app.) So let's suppose you've got the "basic" development environment built and you plan on adding on creature comforts as you go along. Now you're probably at least "competitive" with the C compilers that are bundled with most SBCs. To get an edge, you've got to provide lots of easy to use, well thought out and well documented libraries of stuff that makes building the embedded app a lot easier. Clearly, you need libraries which make the I/O easy (lots of C kits are going to include something like this, but with Ada you could make it better) and you need things to make interfacing to the bare hardware easier. I could see how with Ada95 you could rather easily build a mini, generic scheduler which would border on being a real RTOS - except it would be lean and tailorable. The key here would be providing as much general purpose support code for the particular SBC as possible and doing it *better* than a hodge-podge collection of C subroutines. Think of it as a "thick" binding to the hardware. The thicker the binding, the less work the embedded developer has to do. If it's done well, your selling point is quicker time to market because the developer doesn't have to build all this stuff from the ground up. And since you're going to provide the source code, etc. he can always get around the binding right down to the bare metal if he has to. Oh, there'd still be lots of persuading and demonstrating to do to convince your garden variety embedded SBC developer that Ada *can* do the job and that he *wants* to use Ada to do the job, but I don't see it as impossible. One thing is clear to me - if nobody is willing to *try* to penetrate these markets, there's no use telling me how wonderful Ada is for embedded programming because no matter how badly I want to use it, I can't. I'm not well served if the Ada supporter just lies there telling me how great it's going to be. I believe in Ada as a superior language and we use it here on lots of projects. I'd love to see Ada available on inexpensive, small SBC's so I could put it to work in other areas. MDC Marin David Condic, Senior Computer Engineer Voice: 561.796.8997 Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600 Fax: 561.796.4669 West Palm Beach, FL, 33410-9600 Internet: CONDICMA@PWFL.COM =============================================================================== "Eagles may soar, but a weasle never gets sucked up into a jet engine." ===============================================================================