Personality Conflict was: why Ada is so unpopular ?

Personality Conflict was: why Ada is so unpopular ?

[Mike Brenner]

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.

Re: Personality Conflict was: why Ada is so unpopular ?

[Stephen Leake]

Mike Brenner <mikeb@mitre.org> writes:

> 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.

For what other languages do the end users have effective communication
with those at the top? Let's see, the most popular language is Visual
Basic; ever tried communicating with Microsoft? Or with Sun for Java?

> B. There is no central email address where we can submit suggestions
> for language changes. 

Yes there is: ada-comment@ada-auth.org

> 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.

At one step of the process (not the first step), this is true. It is
also true of all ISO languages, such as C and C++.

> 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.

Hmm. If you mean "bug reports about the language", as opposed to "bug
reports about a compiler", there is a central email address (as
above).

Again, what other languages have such "central email addresses"?

Certainly bug reports about compilers should go to the compiler
vendors?

> 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,

How can you say this had "to little input"? Are you aware of the
extensive design and review cycles that went into Ada 83 and Ada 95? I
suggest you review that history (available at
http://www.adaic.org/standards/ada83.html and
http://www.adaic.org/standards/ada95.html), before you comment more.

If you don't like the design of Text_IO, fine. But that's not the same
as "too little input".

> the lack of common support for the most common operating systems
> (DOS and Unix), 

Hmm. DOS is not exactly "common" anymore. Maybe you mean Windows.

I write Windows and Unix applications everyday in Ada. 

What "support" is missing? In particular, what support is missing from
Ada that is available in other languages? Not in the vendor libraries
for those languages, but in the language itself?

> and unsigned numbers.

That was a real problem in Ada 83; fixed in Ada 95. Ada 95 is 9 years
old now!

> 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.

I'll need an example to understand this issue. I have not encountered
a problem like this.

Have you proposed a detailed change to the Ada language to fix this
"problem"? Hmm, since you are unaware of the ada-comment mailing list,
probably not.

>         (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.

That's what Unchecked_Conversion is for. If you don't want the checks,
say so. Ada gives you the power to say exactly what you want, unlike
other languages.

>         (c) Some unchecked_conversions are required to generated
>         code.

Yes. Why is that a problem? For what other languages is this not true?

> 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, 

I think you are refering to the C++ standard template library. That is
certainly possible for a similar library written in Ada, and there are
many attempts at creating such a thing. For the core language, it is
simply not possible to define, in an implementation-independent way,
the "efficiency" of each construct.

> mandating inlining of certain types of code, 

Please give an example of where this would help, and how it would be
possible for every current Ada implementation. And examples of other
languages where this works well.

> and stating that certain type changes (casts) shall not use run-time
> code but be totally compile-time operations. 

Ditto.

> 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.

The Ada approach to all of this is that if you need these kinds of
optimizations, you should buy a compiler that does them. What other
language is different?

> 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).

Big assumption. And that is the point; Ada is designed to allow a wide
range of implementations (from pure source interpretation, to
byte-code interpretation, to native CISC, to native RISC). You can't
define "the code generated" for that entire range!

> 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.

Hmm. Maybe some people judge languages by the bugs in one early
implementation of an obsolete standard. Most of us prefer to use the
latest implementation of the current standard.

By that approach, C is a truly horrible language, based on the K&R
report!

> E. Some of the strongest discussions on the Ada
> discussion lists have centered around the least
> important issues (in particular capitalization and
> indenting). 

Hardly an indictment of the language. Apparently there is nothing more
important to talk about. A good sign, I'd say :).

> 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.

I gather you are speaking from personal experience. I'm sorry for your
problems, but please don't make the mistake of assuming the language
is at fault.

> 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.

Many companies are making money using Ada, and many others are making
money selling Ada tools and support. This was evident at the latest
SigAda conference.

Yes, there are far more companies making money with other languages.
That is a result of business decisions and practices, not necessarily
the design of the language. 

Yes, Ada is a niche language. To some extent, I like it that way. It
means I can get very, very good support from Ada Core Technologies.
This is only possible because they are a small company, with
excellent quality control.

Of course, there are other Ada companies with different business
models.

> 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. 

Very old news, now. Time to move on.

> 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. 

Since when does a language come up with a killer app? People do that.

Instead of bitching here, please come up with a killer app. I know I
won't be doing that anytime soon; I have real work to do.

> To succeed now, Ada will still have to come up with:
> 
>         a. a killer app,

That would be nice.

>         b. a central suggestion-collecting web page,

We have that.

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

My wife is a social worker. Every one in the computer science field
could benefit from interacting with social workers :). Or just from
reading one of the many good books on management, or team interaction,
or handling personality conflicts in the workplace.

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

Sounds interesting. Please make a concrete proposal, either here, or
at ada-comment.

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

Hmm. I believe one thing people do agree on is that Ada _does_
implement "standard software engineering principles". What ones do you
think are missing?

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

Social workers are everywhere, and are not restricted to a particular
computer language.

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

I use Ada because I am far more productive in it than in other
languages. That is due to do the design of the language, which makes
possible significant compile time checking. It is also do to the
reliability of the compilers and development tools I use, and the high
quality support I can get for them.

I have also used C and C++ for significant projects, and Visual Basic
and Java for smaller projects. I made significant effort to get the
same level of quality in those tools; I was unable to. So now I only
use Ada.

> 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.

Ah, good. We get to end with an agreement :).

-- 
-- Stephe

Re: Personality Conflict was: why Ada is so unpopular ?

[Alexandre E. Kopilovitch]

Stephen Leake wrote:

> > E. Some of the strongest discussions on the Ada
> > discussion lists have centered around the least
> > important issues (in particular capitalization and
> > indenting). 
>
> Hardly an indictment of the language. Apparently there is nothing more
> important to talk about. A good sign, I'd say :).

Exactly. And this also means that the ARG workings are in good shape - the ARG
addresses emerging important issues before than significant fraction of users
can consistently complain about them.

> Yes, Ada is a niche language. To some extent, I like it that way.

Yes, and I think that the state of art still doesn't permit a mainstream
language at this level of quality - there simply aren't enough people able and
willing to build and support an infrastructure needed for mainstream language
at that level of quality (DoD once tried and failed -:) .




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Personality Conflict was: why Ada is so unpopular ?

[Randy Brukardt]

"Stephen Leake" <stephen_leake@acm.org> wrote in message
news:mailman.20.1075131072.2270.comp.lang.ada@ada-france.org...
> Mike Brenner <mikeb@mitre.org> writes:
> > B. There is no central email address where we can submit suggestions
> > for language changes.
>
> Yes there is: ada-comment@ada-auth.org

And the Ada comment list has existed since the beginning of time (that is,
Ada 83). It's address has changed a couple of times, but it has always
existed.

The current version is completely open to the public; see
http://www.adaic.com/standards/articles/comment.html
for details about signing up.

> > 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.
>
> Hmm. If you mean "bug reports about the language", as opposed to "bug
> reports about a compiler", there is a central email address (as
> above).
>
> Certainly bug reports about compilers should go to the compiler
> vendors?

Right. The OP seems to be assuming that Ada = GNAT, which certainly is not
true. (The folks at Rational, Aonix, ICC, DDCI, Green Hills, and RRS would
certainly object to such a characterization. [Apologies to anyone I left
out.]) And sending bugs in Aonix's compiler to DDCI won't be very useful.

And certainly, complaining about bugs in a "free" product is
counter-productive. You get what you pay for, and if you want bugs fixed in
a timely manner, you need to pay (someone) for that service. Otherwise, you
are hoping that some paying customer runs into the same problem - and there
is no guarentee of that.

> > 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.
>
> I'll need an example to understand this issue. I have not encountered
> a problem like this.

I think he's referring to the fact that static actual parameters aren't
static inside a generic unit. He, of course, is making the fundamental
assumption that generics are just an include file -- which is certainly not
true in Ada. The "contract model" of generics (which insures that you can
reason about the code in a generic without knowing anything other than the
declaration of the generic) is considered an important part of the model.
Moreover, it allows sharing of generic implementations, which can greatly
reduce the size of programs.

Such static actual parameters are actually static if referenced from the
instantiation. That was true in Ada 83, and it is true in Ada 95. But lots
of compilers have bugs in this area. So perhaps the OP is blaming the
language for buggy compilers? (The standard wording itself also has bugs in
this area; it doesn't match the ACATS, and it is agreed that the ACATS is
correct, since the current wording is incompatible with Ada 83. There are no
compilers tested under the ACATS that have requested a variance on these
tests, so I can safely assume that compilers implement the Ada 83 rule.)

> >         (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.
>
> That's what Unchecked_Conversion is for. If you don't want the checks,
> say so. Ada gives you the power to say exactly what you want, unlike
> other languages.

Ada 200Y will have the 'Mod attribute to deal with this problem. See AI-340,
which was approved at the last meeting. The fact that Ada 95 didn't deal
with this is simply a mistake; there are going to be some in 500+ pages of
Standard.

Note again that the OPs contention that "people at the highest levels"
(whatever that means) don't understand these issues is obviously false --
otherwise, there wouldn't already be a solution in place.

Also note that implementers are encouraged to add these features to their
compilers as soon as they want to; several implementers (based on public
statements) are actively adding Ada 200Y features right now. You won't have
to wait many years to get some of them.

...
> > 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.
>
> Ah, good. We get to end with an agreement :).

Yes. :-)

The OP seems to be another person who would rather complain rather than
help. There is some much activity - the ARG (and Ada-Comment), SIGAda,
various free software efforts, etc. Get involved! If the OP did, he'd find
that the people there aren't really any different than himself. And, Ada can
always use more help.

                 Randy Brukardt

Re: Personality Conflict was: why Ada is so unpopular ?

[Robert I. Eachus]

Randy Brukardt wrote:

>>Mike Brenner <mikeb@mitre.org> writes:
>>
>>>B. There is no central email address where we can submit suggestions
>>>for language changes.
>>
>>Yes there is: ada-comment@ada-auth.org

It doesn't matter.  For a couple of years, my office was next to Mike's 
at MITRE, and even when I moved down the hall, I was still available. 
Also both MITRE Bedford and MITRE Washington had significant input into 
the Ada 9X requirements process, not to mention my involvement in the 
actual development.  Ben Brosgol, Dave Emery, and I did a lot of the 
Information Systems Annex work.  (Dave and I were both at MITRE Bedford 
when that was going on.)

Incidently, I am not really picking on Mike about this.  It is very 
similar to the discussion about preprocessors.  Why don't Ada 
programmers use pre-processors?  Not because they are not available, 
Verdix always had a pre-processor, and now GNAT has one, I don't know 
about other compilers.  But I don't care.  There is a Ada programming 
culture and it says that pre-processor are icky.  Shrug!  Changes to the 
language STANDARD won't change that, just as changing the standard can't 
fix most of Mike's complaints.  They are really cultural opinions, and 
that is just not something that the ARG can fix.

To be honest, it is not something that anyone on the ARG or at WG9 wants 
to fix.  Ada serves a several specific groups.  Ada serves them well. 
And we must consider that base important when trying to "reach out" to 
the C and C++ communities, which have a different culture.

Actually, let me give one further example.  In Ada 0Y there will 
probably be a feature that allows calls to operations on tagged types to 
be made in the object.operation syntax.  Will it help convert C++ 
programmers to Ada?  I don't think so.  In fact, I think that most Ada 
programmers will ignore it, just like pragmas that can have 
pre-processor-like effects are ignored, Unchecked_Conversion is seldom 
used, and so on.  Those are cultural not language decisions.  We can put 
the features there, but we can't make Ada programmers like them.

At that is what most of Mike's complaints boil down to.  I can do THIS 
in Ada, but I don't like the way I have to do it.  If anyone has a 
solution to that common complain, let me know, because I sure don't.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Personality Conflict was: why Ada is so unpopular ?

[David Starner]

On Mon, 26 Jan 2004 14:11:00 -0600, Randy Brukardt wrote:
> And certainly, complaining about bugs in a "free" product is
> counter-productive. You get what you pay for, and if you want bugs fixed in
> a timely manner, you need to pay (someone) for that service. Otherwise, you
> are hoping that some paying customer runs into the same problem - and there
> is no guarentee of that.

If I have a bug in GCC, it generally gets fixed in a timely manner. If
it's important enough, a patch may get backported from the mainline
to the release branch by Debian developers (which is purely a volunteer
position.) To me, submitting a bug to a developer is a courtesy; it's
usually easy to work around the bug then write up a good bug report, but
writing up a bug report means a better program for everyone.

Now, I've submitted several bugs on GNAT. They've got dismissed offhand;
the one that would have required significant work, or documentation of the
limitation in the manual got neither, and Robert Dewar (who commented
personally on it) has publically claimed that the feature it used (UTF-8
source code) has never been used. The other, which was a regression, got
closed because the regression probably occurred in the C part of the
compiler. 

There are no maintainers for the Ada part of GCC that have any motivation
to keep the Ada part of GCC working for everyone, unlike the Apple, Red
Hat and Debian maintainers who work to keep the rest of the compiler
generally usable. ACT only really cares about the compiler it sends to its
clients, and it shows.

> And certainly, complaining about bugs in a "free" product is
> counter-productive. 

The fact is, it's not. If I find a bug in the C, C++, Eiffel, or Lisp
compilers on my system, or one of hundreds of other programs, I will get a
polite response. That doesn't mean I will get a bug fix, but I can't
afford to pay for a guaranteed bug fix, and probably won't ever. If I
can't get the same service from my Ada compiler as I do from my C
compiler, that is a valid reason to change languages.

Re: Personality Conflict was: why Ada is so unpopular ?

[David Starner]

On Mon, 26 Jan 2004 10:30:46 -0500, Stephen Leake wrote:
> 
> What "support" is missing? In particular, what support is missing from
> Ada that is available in other languages? Not in the vendor libraries
> for those languages, but in the language itself?

That seems like an artificial distinction. If my C code works on every
Unix platform, why should I worry about whether the code depends on C
functions or on POSIX ones? Further out, is it not an advantage that a
language have libraries regularly available to do something where Ada has
no corresponding libraries? Or that a C library is well-maintained where
an Ada binding to that library is not?

Re: Personality Conflict was: why Ada is so unpopular ?

[Stephen Leake]

David Starner <dvdeug@email.ro> writes:

> On Mon, 26 Jan 2004 10:30:46 -0500, Stephen Leake wrote:
> > 
> > What "support" is missing? In particular, what support is missing from
> > Ada that is available in other languages? Not in the vendor libraries
> > for those languages, but in the language itself?
> 
> That seems like an artificial distinction. If my C code works on every
> Unix platform, why should I worry about whether the code depends on C
> functions or on POSIX ones? 

Because you may need to port it to a different operating system?

More to the point, the OP was complaining about the language standard
itself, not the libraries available for it.

> Further out, is it not an advantage that a language have libraries
> regularly available to do something where Ada has no corresponding
> libraries? Or that a C library is well-maintained where an Ada
> binding to that library is not?

Yes, these are valid points. But the OP did not seem to be saying
that. Part of the reason I phrased my response this way was to make
him think about this distinction.

-- 
-- Stephe

Re: Personality Conflict was: why Ada is so unpopular ?

[Randy Brukardt]

"David Starner" <dvdeug@email.ro> wrote in message
news:pan.2004.01.27.00.43.18.820533@email.ro...
> On Mon, 26 Jan 2004 14:11:00 -0600, Randy Brukardt wrote:
> > And certainly, complaining about bugs in a "free" product is
> > counter-productive. You get what you pay for, and if you want bugs fixed
in
> > a timely manner, you need to pay (someone) for that service. Otherwise,
you
> > are hoping that some paying customer runs into the same problem - and
there
> > is no guarentee of that.
>
...
> There are no maintainers for the Ada part of GCC that have any motivation
> to keep the Ada part of GCC working for everyone, unlike the Apple, Red
> Hat and Debian maintainers who work to keep the rest of the compiler
> generally usable. ACT only really cares about the compiler it sends to its
> clients, and it shows.

Perhaps. Economics says that you can't give the same service to free
customers as you do to ones that pay money, or pretty soon you don't have
any paying customers.

> > And certainly, complaining about bugs in a "free" product is
> > counter-productive.
>
> The fact is, it's not. If I find a bug in the C, C++, Eiffel, or Lisp
> compilers on my system, or one of hundreds of other programs, I will get a
> polite response. That doesn't mean I will get a bug fix, but I can't
> afford to pay for a guaranteed bug fix, and probably won't ever. If I
> can't get the same service from my Ada compiler as I do from my C
> compiler, that is a valid reason to change languages.

Are any of these other languages maintained by commercial companies without
significant other products?

Ada (the language) is built around the notion of multiple vendors competing
for your business with some assurance that the language that those vendors
support is similar in important ways. If your current vendor is not
supporting you well enough, try a different vendor. This needn't be
expensive: $800 gets you a current Janus/Ada compiler and a year's worth of
support.

I realize that changing compilers isn't always possible.

It should be the case that vendors treat everyone with respect. But there is
an awful lot of "customer abuse" going around these - some companies make a
habit of it. I don't see anyone in the Ada industry anywhere near as bad as
some of the mass market software companies (Intuit comes to mind).

In any case, if all of this is simply a gripe about one particular person or
vendor, it's relevance to Ada as a whole is pretty much nil. Certainly the
Ada standard is not going to change someone's personality or business
practices!

                         Randy.

Re: Personality Conflict was: why Ada is so unpopular ?

[Marin David Condic]

Ada might have done better with two simple overriding rules: A) Know who 
your customer is. B) Figure out how to make that customer unbelievably 
happy.

Ada bungled the job with embedded developers early on because it didn't 
pay attention to the needs of the guys in the trenches who were doing 
the job and had the ability to say to any management: "If you make me 
use Ada, I can't get the job done" (They may not have the power to 
select the language, but they sure have the veto power over a language! 
;-) In the early days it was too big, too slow, too buggy and too 
expensive - not to mention it didn't provide features that the garden 
variety embedded developer considered essential to getting the job done.

As languages go, Ada probably had more money thrown at it than any other 
language in history. It should have used some of that money on "Market 
Research".

O.K. So the pooch got screwed on that one. How to fix it now? Start with 
(A) above - figure out what market you want to address. Then go to (B) - 
Ask people in that market what they want out of a language. Maybe offer 
them some suggestions for possible new and wonderful capabilities, and 
find out what they say. Figure out what they need to get the most 
possible leverage from the language and give it to them.

That's not exactly rocket science, eh? :-)

MDC


Mike Brenner wrote:
> In addition to the responses given, on the thread "why Ada
> is so unpopular", we must remember that it never 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Personality Conflict was: why Ada is so unpopular ?

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Right. The OP seems to be assuming that Ada = GNAT, which certainly is not
> true. (The folks at Rational, Aonix, ICC, DDCI, Green Hills, and RRS would
> certainly object to such a characterization. [Apologies to anyone I left
> out.]) ...

SofCheck, Inc.

- Bob