comp.lang.ada
 help / color / mirror / Atom feed
[parent not found: <401524D4.CBDA0658@mitre.org>]
* Personality Conflict was: why Ada is so unpopular ?
@ 2004-01-26 14:31 Mike Brenner
  2004-01-27 13:39 ` Marin David Condic
  0 siblings, 1 reply; 11+ messages in thread
From: Mike Brenner @ 2004-01-26 14:31 UTC (permalink / raw)
  To: comp.lang.ada

In addition to the responses given, on the thread "why Ada
is so unpopular", we must remember that it never 
was popular, and that during the "Ada mandate", it
was never mandated. However, the responses I read in 
this thread did not address the primary problem
with Ada, namely more personality conflicts
than a small project could handle.

Here are some political symptoms which fell
out of those personality conflicts:

A. It has been impossible for those of us at the
bottom of the heap (users of Ada) to effectively
communicate with those at the top, who control
what changes go into the language, and who
decide what support to give to whom.

B. There is no central email address where we can
submit suggestions for language changes.
The people who accept formal requests for 
suggestions do so only from "country delegations"
who do no listen to our posts in Ada email lists.

C. There is not central email address where we can
submit Bug reports. Therefore bug reports are
only selectively accepted by the manufacturer of 
"supported versions", making it impossible to know 
the scope and impact of the bugs, or to measure
the improvement of the language over the years.

D. Because of these personality conflicts which led
to this situation where there is no where to 
effectively email suggestions or bug reports, 
some things have gone awry with the language itself.

D-1. The design of some packages and features had
too little input. For example, the design of text_io,
the lack of common support for the most common
operating systems (DOS and Unix), and unsigned numbers.

D-2. The lack of ability of the people at the top
to counter their prevailing belief that "semantics"
has nothing to do with "efficiency". As a result of 
this false belief their decisions, their manuals, 
and their features are implemented in inefficient
ways. The 3 most egregious examples of this 
inefficiency are:

        (a) Static variables don't remain static
        when generically instantiated.

        (b) Constraint_error is raised by assuming
        a fictitious overflow when a signed number
        is moved into an unsigned number and vice
        versa, instead of just putting the bits 
        into the other field without checking anything.

        (c) Some unchecked_conversions are required
        to generated code.

To solve this, a new definition of the word
"semantics" must be created which includes how
fast something runs as part of its "meaning".
Other languages have been doing that for years,
for example, making the time-complexity of a
function a part of its runtime library documentation,
mandating inlining of certain types of code, and
stating that certain type changes (casts) shall not
use run-time code but be totally compile-time operations.
Just because somebody has the opinion that those
kinds of requirements are "not semantics", does not
mean that Ada should not have efficiency-oriented
requirements. At a minimum, that conflict should
have been put aside by saying, "okay, we'll 
tentatively agree with you that efficiency is not
part of the type of semantics you are talking about,
but we still insist that certain operations be
done at compile time"! It could have been a 
win-win situation, and will have to become so
to achieve a future success.

Examples of this kind of compromise in the "meaning"
of "semantics" include the subject of Procedural
Semantics. In Procedural Semantics, we would
define the meaning of certain Ada constructs 
in terms of the code those constructs generate. 
This would contribute greatly to solving the technical aspect 
of this personality problem, 
by permitting some constructs (tail recursion, 
unchecked conversion, instantiating static variables, and 
moving integers from an to unsigned integers) to be defined 
as being implemented by no code at all (assuming the proper 
copy optimizations are possible). 

Yes, I realize that solving the technical portion
of a personality problem addresses only the tip of
the iceberg, 
D-3. Ada today is still being judged by bugs in the DOS 
version of gnat in the text_io package, bugs which could
probably have been fixed with a few minutes of
work by someone who knew anything about that package.

E. Some of the strongest discussions on the Ada
discussion lists have centered around the least
important issues (in particular capitalization and
indenting). Yet people have been blackballed,
blacklisted, and threatened with job loss because
of these personality-related issues, and the
effect has not been lost on the community as a
whole.

F. As a result of all of those and other issues, 
many programmers who love Ada took jobs in
other fields, leading to a situation where there
are not as many cheap intern-salary labor who can analyze
the impact of change, design, code, or test in Ada,
as there are in competitor languages. For example,
I have been offered several Ada jobs over the last few years,
but at Intern wages. Who can afford to quit a real job 
for an 80 percent salary cut combined with moving
away from the coasts? And, then, there is the
problem of how a company could formulate Ada work 
in a very tiny market.

G. Finally, there are also personality conflicts at 
higher levels. The people who administered the 
"Ada Mandate" that never mandated anything ensured
that a major backlash would occur against that
imaginary mandate, and the backlash occurred,
but the Ada community had no answer to it. Now
most programs are mandated to not use Ada. While
this violates Software Engineering principles, 
no one cares, because software engineering is just
what the powerful people in control of the money
believe until they are replaced by other
powerful people. And "power politics" is just another
name for personality conflict.


CONCLUSION

To succeed in the nineties, Ada would have had
to come up with a killer app, but that would have
failed without eliminating the personality conflicts
and having a central repository of suggestions
and bug reports. 

To succeed now, Ada will still have to come up with:

        a. a killer app,

        b. a central suggestion-collecting web page,

        c. a way to eliminate the personality
        conflicts within the Ada community,

        d. a means of defining efficiency in a
        tiny but important set of Ada constructs,

        e. a means of implementing standard
        software engineering principles instead
        of indenting rules.

        f. a way to eliminate the conflicts with its
        former and potential future customers,.

        g. a way to win on both the reliability and
        the efficiency measurements. 

It's now happening yet, but it could still happen, 
because Ada is still the best design language, 
the least buggy way to code, and the easiest language
in which to conceive bug free implementations
out of all strongly-typed languages.




^ permalink raw reply	[flat|nested] 11+ messages in thread
end of thread, other threads:[~2004-01-27 18:13 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <uzncahgm1.fsf@acm.org>
2004-01-26 17:28 ` Personality Conflict was: why Ada is so unpopular ? Alexandre E. Kopilovitch
     [not found] <401524D4.CBDA0658@mitre.org>
2004-01-26 15:30 ` Stephen Leake
2004-01-26 20:11   ` Randy Brukardt
2004-01-26 23:53     ` Robert I. Eachus
2004-01-27  1:06     ` David Starner
2004-01-27  2:26       ` Randy Brukardt
2004-01-27 18:13     ` Robert A Duff
2004-01-27  1:12   ` David Starner
2004-01-27  2:08     ` Stephen Leake
2004-01-26 14:31 Mike Brenner
2004-01-27 13:39 ` Marin David Condic

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox