Re: Can Ada by popularized faster ?

["Marin David Condic, 561.796.8997, M/S 731-96" <condicma@PWFL.COM>]

Brian Rogoff <bpr@SHELL5.BA.BEST.COM> 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."
===============================================================================