Re: GnatBench (from GPL edition)

["Randy Brukardt" <randy@rrsoftware.com>]

"John McCabe" <john@nospam.assen.demon.co.uk> wrote in message
news:4pa9v3lbp3i24ob3kodj0f49laco0vo68j@4ax.com...
> On Wed, 2 Apr 2008 22:20:53 -0500, "Randy Brukardt"
...
> >And the rest of
> >it is going to be very language- and implementation-specific. My
> >understanding is that that pretty much the entire Eclipse IDE resides in
its
> >plugins, so developing them is just as complex as developing a whole IDE.
>
> Well not quite as complex as once you understand the Rich Client
> Platform and the whole framework, and you have the Java Development
> Tools to set an example, I believe it's easier. You only have to
> concentrate on the bits that are important to your application.

<sarcasm>Let's see. Learn two new toolkits and a new programming language.
That's *sure* to be easy. </sarcasm>

> >Moreover, you have to develop them in a subpar programming language
(IMHO -
> >and in any event I don't know it anywhere near as well as I know Ada). So
> >what's the gain? It mainly seems to be a marketing checkbox to me.
>
> I agree with the subpar language thing, but from a marketing point of
> view, if you want to get into a market that is currently Java based,
> or C++ on Unix

No. If you can stand the syntax of those languages, you're already in a
different universe than me...

> ... then there is a good chance you will find they already
> use Eclipse. If you and a competitor both sell Ada compilers, but your
> competitor has plugged in to Eclipse and you haven't, given no other
> significant differences in functionality between your products, I
> would suggest your competitor has the upper hand.

Our competitors *always* have the upper hand; functionality seems to be
irrelevant. We only get those people who are truly concerned about price
*and* performance (and there are very few of those in the Ada community).
And those who are looking for something that our competitor's don't have at
all (Claw, MS-DOS compilers, etc.)

> Just look at who's
> involved in the Hibachi project - Aonix are effectively leading it
> with DDC-I and AdaCore having significant input, and supposedly OC
> Systems and Green Hills are expected to contribute.

We would have contributed if there was something that we could actually do.
Aonix is (partially) a Java company these days, so they (presumably) have
the expertise to write such code. We don't. I'm sure the generic Ada stuff
will work fine with us. But the compiler-specific stuff has no chance: all
of our tools only have Ada interfaces (with a few exceptions for the command
line). For instance, it would be impossible to interface our project manager
to something that is not a native compiled language (it could be done from
C, for example, but not from Java byte code or .Net for that matter).
Launching command-line tools would only provide a small subset of the full
functionality, and would be as slow as molasses.

...
> >Now, I realize that it's unlikely that many of us are going to be able to
> >build all-Ada bare machines. (The fact that people have turned to using
> >real-time executives to provide the same services that Ada already does
has
> >always mystified me; a bare machine Ada should do as well or better than
> >your typical RTOS.) But my preference is to spend some effort up front
> >wrapping any foreign code into the best designed Ada interfaces that you
can
> >get, and then (hopefully) never look at it again. That was the main
driving
> >reason for developing Claw, and that has worked out pretty well (could
have
> >been better, I suppose, but that's always true).
>
> While that's true to some extent, I don't believe the "never look at
> it again" part is feasible - things move on underneath you. E.g. the
> Win32 stuff that I believe Claw wraps has moved on a bit since I first
> heard of Claw, which means you need to follow those developments and
> update your wrappers, or risk being obsolete.

I like being obsolete. ;-) (I sure as heck am not wasting time on Vista!)

Seriously, good interfaces don't change incompatibly. (Even iffy ones like
Win32 don't change imcompatibly.) So existing code continues to work. If you
need the new functionality, then of course you have to add it in, but that
brings you back to the new development stage. Most of Win32 hasn't changed
appreciably since Windows NT 4.0 came out. Mostly, there are totally new
interfaces to support, very little change in the existing stuff.

If you are using stuff that is not like that, you have my sympathy, but I
also have to wonder if you wouldn't have been better off building it
yourself (or finding it in Ada). Houses built on quicksand don't long stand.

My personal rule is that if it isn't part of the OS, then I build it in Ada.
And if I can't build it, I don't want it. That's probably too conservative,
but I *always* get the tool I want that way, and there are few compromises
needed. Yeah, I know ("too idealistic").

                                 Randy.