Re: What's stopping you from using Ada for your next commercial project?

[Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>]

On 3/25/11 11:30 PM, Maciej Sobczak wrote:
> On 25 Mar, 13:36, Marco<prenom_no...@yahoo.com>  wrote:
>
>>> 2. Availability of resource. This is not about people on the job
>>> market that are waiting to be employed, but about people that are
>>> already working for the company - are they willing to learn Ada?
>>
>>    No - paid professionals learn whatever language is needed.
>
> No. This is for two reasons:
>
> Why on earth would anybody go through the
> pain of learning anything

(Short summary of this lengthy letter, sorry:

- Learning can be a relief in comparison.
- Most jobs require learning, though of contemporary detail only.
-The job market typically does not allow choosing by language.
- Languages are not mainly compared by feature sets (and MI is
    typically not used).)

Learning isn't necessarily a pain.  Learning interesting things can
be rewarding. People like to talk about things they learn, that
proves it.  OTOH, Learning how to tackle a hodgepodge of contemporary and
not so contemporary components of typical systems is onerous work,
needs huge amounts of attention to disconnected notional systems, and
needs much learning of messy detail having little to do with programming
languages.
These jobs may not even be well paid.  Worse, once the system is at another
level satisfying the customer/manager/..., you can likely forget
the things you have learned on this job because the next hodgepodge
of a system requires different knowledge...

Learning another language is different. The language, or the techniques
can likely be used on another project, any many programmers seem to
be looking at interesting language features.

There is quite an amount of systems of the kind mentioned above.  The job
description is somewhat invariable, and leaves little room for such
entertaining things as learning programming languages.

If there is a job requiring attention to only two or three focal points
(let alone to just one! Ha!), a job that will entail the opportunity of
focused learning, then this kind of job is a *relief* in comparison.



> if they can just go get another job across
> the street?

Where's that street? ;-)  I'm only aware of auction job markets
that permit a kind of choice---for mere programmers.  If you are
a (modern version of) bookkeeper with some programming experience,
or an electrical engineer who has seen a few C programs or Fortran
programs, things differ.  The HR departments will be attentive,
since they can easily declare programming a background task...  This
situation, of course, leaves programming professionals behind.

Consider two fictional persons:

Person 1 claims in his CV:

Knows how to build measurement instruments.  Has studied
physics and chemistry.  Demonstrably knows C++ well.

Person 2 claims in his CV:

Knows how to build measurement instruments.  Has studied
mathematics  and philosophy.  Demonstrably knows Python well.

Will an HR person even look at (2) if there is a (1)?
Will they even test the comparative programming skills
of (1) and (2)?

What I am saying is that it is not typically up to the
programmers to choose a Job by what they prefer to do,
for example a programming language they know.

Choosing by programming language is a dream that a happy few
can live.


> 2. The notion of investment continuity. If somebody has already
> invested let's say 5 years to learn something and become proficient in
> it and gained production experience and peer respect in the given
> technology, it is natural for them to continue the same path. Why on
> earth would anybody choose to become a *beginner* again, which does
> not look like a career progression at all?

There are reasons. For example, Java world, backends.  If you are fed
up with maintaining throw-away software using someone else's fad du jour,
hipster framework 2.1 two years ago, is it any different across the
street?  Fed up with trying to understand the architecture
of an undocumented, cheapo system requiring a face lift and connecting it
to yet another set of soon-to-die acronym. IOW, if you are in the Java
brigade, I bet you would readily become a beginner again if that gives
your an opportunity to think, to learn, to develop assets less tangential.

Actually, there are these market forces, moving a project from
language X to language Y because of, for example, a company take-over.
In the office world, industry seems to prefer non-standard solutions.
There is plenty of opportunity to spend considerably expensive
amounts of time with archeological analysis of old Delphi programs,
C#->Java howtos  concerning mostly the library, and so on.
Little they teach CS majors about proper engineering of systems
is manifest in the office market.

> These two reasons make it difficult to introduce Ada in an existing
> working environment.
>
> If you argue that such people are not professionals, I will disagree
> in advance. I know people with this kind of attitude and I consider
> them to be professionals in their respective specialties.
>

> 1. The features that are not eagerly implemented in C99 are also not
> eagerly expected by users, so there is no harm in keeping the status
> quo. This is different in Ada, where interfaces (or complete MI) are
> already overdue some 15 years, at least. They *must* work correctly,
> especially when combined with other language features.

Speaking of professionals, which professionals find MI familiar?
Python professionals don't care.  Ruby professionals use mixins.
Java and C# professionals would know interfaces; maybe some
know how to use types with multiple interfaces.  Objective-C
professionals know multiple (class) protocols, but not since
long. There may be a number of C++ professionals who know MI.
Are there any statistics agreeing with the claim that MI (of
interfaces) is a language feature that is typically expected?

> 2. Ada and C99 do not belong to the same category and do not even
> target the same audiences.

Why not?  In their markets, C and Ada compete.   I'd not find it
surprising if the comparison will be biased away from comparing
technical feature sets of the languages.  According to Michael
Barr's survey, knowledge of technical features of the language
C is not the highest qualification of professionals.