Re: Time to join the fold?

[Steve Whalen <swhalen@netcom.com>]

What Tucker said... AND

From a technical management perspective, I'll try to
throw in another "dimension" to the guess work on:

    How long will it take for an experienced programmer
    coming from C or Assembler or other language 
    that does not "impose" significant type and structure 
    discipline on the programmer, to become productive in
    Ada95.

Obviously, there's no real answer: maybe a few months,
maybe never, depending on the person and support they
get (or don't get).

However, you have one important, but usually overlooked 
advantage to learning and using Ada95 effectively: 

    You already know your problem domain.

The only way I can think of to illustrate my "dimension"
is with the dreaded "hypothetical": the scenario:

    Experienced Assembly language programmers (of "equal" 
    talent/productivity) are both assigned to learn a new 
    problem domain AND a new language and implement a small 
    system (both are learning the same new problem domain, 
    one will program in C, the other Ada95).

I can almost guarantee you that the person learning C will
appear to be more productive early on in the "race" because
the compiler will not place any roadblocks in their way.

The C programmer will probably have a functioning program
before the (frustrated) Ada95 programmer has gotten the first 
program to compile.
 
However, toward the end of the "race", the Ada95 programmer
should have a (correctly) functioning SYSTEM, while the
C programmer is still debugging PROGRAMS (because of the
deep logic flaws that untyped languages tend to encourage,
or at least give you no help in finding).

From my experience, I'd say you are in a BETTER position to
switch to Ada95 than most, because you alread have a working
"program", and therefore, a thorough knowledge of your problem domain
(although as Tucker points out, you may have logic bugs you'll
discover in your current system just from trying to properly
define them to Ada95).

I'd present Ada95 to management as a way to produce a higher 
quality end product, and NOT oversell it as a way to get 
"something" functioning the fastest. Maybe another way to
say it: C will almost always win the race to get the
first "something" running, but Ada95 will win the race to 
get a stable, quality product into customers hands. 

Steve

P.S. Please note that I did not include C++ in the "early race
winning" category on purpose.  While I don't want to start another
Ada95 vs C++ war, my oveservation is that while C++ has some neat
features, I see too many projects that spin out of control because
with C++ you don't get the "mandatory benefits" that come with the
strongly typed/structured approach of Ada95, but you do get much of
the complexity/power.

To badly paraphrase a quote I once saw attributed to C++'s designer: C
makes it easy to shoot youself in the foot, C++ makes it a little
harder to shoot yourself, but when you do, you blow your whole leg off
[end of bad paraphrasing job]...

My observation from real world C++ projects (most poorly managed) is
that C++ makes it pretty easy to blow up whole city blocks, especially
when there is weak management of the system design and development
process.

In less than perfect environments, I think you still get a lot of
Ada95's benefits, often in spite of the environment. However, it IS
possible to have a management and environment so undisciplined that
I'd recommend C over Ada95 too (and for the same reasons I recommend
Ada95 over C++ "in general": fewer city blocks blown up, and the
project eventually gets done (if not done "well")).


-- 
{===--------------------------------------------------------------===}
                Steve Whalen     swhalen@netcom.com
{===--------------------------------------------------------------===}