Re: Is General Kind the harbinger of doom

Re: Is General Kind the harbinger of doom

[Mark A. Breland]

In article 56@almaden.ibm.com, jnestoriak@vnet.IBM.COM () writes:
>
>I've heard this complaint of "not enough Ada programmers" over and
>over here.  Is this really the case?  It seems to me that a shortage
>of programmers for a particular language is always contrived.  Anyone
>who graduates from a decent University with a degree in Computer
>Science who can't learn a new programming language in less than a
>month must have slept through too many classes.  Is it really
 ^^^^^
I'd probably agree with you on this point *syntactically*; however,
*semantically* it's an entirely different story.  The nuances and
subtlies of Ada require a broader experience base with the language
and the platform on which it's implemented to develop a full understanding
of its behavior.

>unreasonable to expect employers to give a few weeks of education
>to their new hires (whether experience or from school)?  I'd like to
>think I'm a genius because I was able to quickly learn "that
>terribly complex and hard to understand" language Ada, but I get the
>feeling that it's not too rare an ability.

What you see here is an instance of MIL-STD-MGR at work.  It's not
surprising to see Ada contractors manage in the same manner as their largest
customer (i.e., DoD)...reactively.  They've got 40 programming positions to
fill so what do they do?  Submit a requisition for Body, warm-Ada-proficient,
CFE-1815A-2167A-SM/F quantity 40.  There's a problem...do something to make
it go away.  It's difficult for them to shake the mindset that people are
readily interchangeable, yet must have all perquisite specializations.

However, this does not have to be the case...more gems of proactive managers
are surfacing, but most frequently in the commercial environment.
Personally, when I hire, and I have to choose between a perfect Ada
Adonis/Diana stud/babe or a competent software engineer lacking Ada exposure
but having expertise in the applied technology,  I'll go for the applied
technology expert every time.  The benefit of their application expertise
outweighs the cost of any necessary Ada training.  One or two Ada gurus
in-house to tackle esoteric Ada-issues, coupled with a stable of
application-expert software programmers, will increase your cost
effectiveness and reduce program completion risk.  Unless you want to shop
around for the first half of your scheduled program time looking for a full
staff of Ada competents...  ;)

---
Mark A. Breland - Microelectronics and Computer Technology Corporation (MCC)
Ada Fault Tolerance                               | voice:    (512) 338-3509
3500 West Balcones Center Drive                   | FAX:      (512) 338-3900
Austin, Texas 78759-6509   USA                    | internet: breland@mcc.com

Re: Is General Kind the harbinger of doom

[Wes Groleau X7574]

There has been posted disagreement on whether it's easy to learn Ada
and whether there is a shortage of people who know Ada.  My three cents:

It is definitely VERY easy (and I see lots of evidence daily) to learn enough
about any language to write what looks like a token-by-token translation
from the language you learned first.  Often in the style you learned first.

It's also easy in SOME languages to apply good software engineering principles
IF you have been trained in them OR if you have enough intelligence to 
recognize and adopt them when exposed to them in the workplace.

Unfortunately (judging by the people I've worked with/under/over) thirty
percent of the Ada programmers cannot write their native language (English)
much less Ada.  And the former problem has a "negative synergistic effect" on
the latter.

Another twenty percent have hard-coded into their brain that Ada is inferior
to (pick one) C, FORTRAN, LISP, FORTH, assembly, yes, even COBOL.  Their code
either attempts to prove their point or they "try to make the best of it" and
write as close to their <lang> style as they can stretch the LRM to allow.
Examples: (1) adopting the pervasive C bias against identifiers having
more than three characters or containing any vowels.  (In fairness to C
programmers, this bias not held by all--only a slight majority).  (2) One guy
went so far as to write an Ada procedure for each LISP function he wanted to
call, then wrote his program in a variant of LISP that left out the parentheses
and used semicolons instead of commas!  
in their <lang> styles to the most extreme limits of the LRM.