Wed, 21 Jun 2000 17:37:45 -0400
> -----Original Message-----
> From: W. Wesley Groleau x4923 [mailto:[log in to unmask]]
> Sent: Thursday, June 15, 2000 9:40 AM
> To: [log in to unmask]
> Subject: Re: Future of Ada -- Not enough "Ada people"
> > ....Personally I don't understand why anyone
> > would specifically demand good Ada knowledge for a long
> > term assignment, as long as the applicant was well versed
> > in at least two or three other high level languages.
> > (Actually - having tried to maintain Ada code written in
> > the early days by C programmers, maybe I should retract that :-)
> Yes. I had the same reaction to Pascal written by Fortran folks.
> (integer constants for enumerated types, nested ifs instead
> of cases or even elsifs to check the case...)
> Wes Groleau
While Pascal & Fortran programmers may initially code in "PascalAda"
and "Adatran" it's still Ada. If we emphasize our opinion that beginner's
Ada is not as good as our "Ada style" Ada, we will hurt Ada's growth.
The message to the software community MUST BE that it's easy for
good programmers from other languages to learn and use Ada.
My experience was that the fewer differences between an individual's
prior experience and "software engineering with Ada" the easier their
transition. But regardless a good programmer/software engineer can
make the transition. Programmers coming from a "weakly typed"
language background will "hate" their first "strongly typed" language.
Programmers coming from "hacker" cultures will "hate" their first
"engineered" project. Programmers use to functional decomposition
will have some difficulty adjusting to an object oriented style.
This has nothing to do with Ada. Ada can accomodate any organization's
style. An AdaTran project whose code I reviewed had implemented
Fortran's intrinsic types, didn't use other user defined types, and
"use"d packages that performed implicit type conversions, just like they
were use to. The AdaTran system work and the team was happy.
The better news is that several projects latter when the team had more
experience they redesigned the system to avoid some poorly performing
aspects of their initial design. They also used domain analysis and
used generics to create a design that was fewer lines of code and allowed
their organization to achieve 80-90% verbatim reuse (vs 30% reuse with
Fortran) and at the same time achieve performance equal to that achieved
in 15 years refining their Fortran implementation.
Software Systems Engineer
AdaSoft at Johns Hopkins Applied Physics Lab.
email: [log in to unmask]
phone: (240) 228-3030 (live M-F 9:30am-4:30pm, voicemail anytime)
fax: (240) 228-6779