Re: IBM Acquires Rational Ada

["Marin David Condic" <mcondic.auntie.spam@acm.org>]

I understand. I've collected similar data. I've seen other studies
indicating the same thing. But all of these studies (of necessity) have the
built-in caveat "All Other Things Being Equal". Someone who comes in the
door with a truckload of libraries and development tools and natural
bindings to the OS and other people's libraries and all that other stuff,
simply isn't playing fair. :-) They've moved their ball a hundred yards
closer to the pin while Ada has to tee off from the usual line. So what if
Ada could develop all those libraries, tools, bindings, etc. and ultimately
do a better job? The problem is they aren't there now and the project starts
today. The guy who bought the cheesy, buggy, C++ compiler that came with the
GUI wizard and magical debugger and the half-million lines of class-library
code got his project out the door 6 months ahead of you because you're still
building the interface bindings to the OS.

I'm sympathetic to the notion that Ada actually is faster for development
and I believe it because I've measured the results myself. However, there
really is no getting around that "All Other Things Being Equal" caveat and
right now the other guys are cheating while the Ada community can't even
find a way to create a standard class library without a ten year language
revision cycle. Is it any wonder that developers choose C++ or Java?

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Jeffrey Carter <jrcarter@acm.org> wrote in message
news:3DF7901C.3000006@acm.org...
>
> But where we have real data (Rational's metrics on Ada compiler
> development in C and Ada), Ada was faster to completion as well as
> having fewer errors which were easier to correct.
>