Re: Perhaps there _is_ a conspiracy against Ada

Re: Perhaps there _is_ a conspiracy against Ada

[tmoran]

>And just how did you attach callback functions to GUI objects
  You are quite right for the Macintosh where the (Meridian)
compiler supplied a binding to the Mac OS that used their way
of doing things.  But event driven under DOS did not need callbacks,
because DOS didn't use callbacks.  It just had a looping task that
called things (as well as separate tasks for some of the audio+video).

>>  Having the program print something like "Constraint Error, value = -1"
>>and a traceback sure beats setting breakpoints in a program whose bug
>>symptom is a system crash.
>2. I find it faster to add events to debugger breakpoints when I find a
>testing error than to add a bunch of gratuitious print statements
>that I will later have to remove.
  No, the 'print something...' did not mean 'insert print statements'.
The compiler's run-time-system automatically generated those messages
for any unhandled exception.  And (unless you turned off checking) it
inserted exception checking code wherever it needed to.  So nothing was
required of the programmer, and he didn't have to change anything.
If a little speed increase was crucial, you could recompile with
checking off - but hearing from some distant stranger that "the
program died with error X in subroutine Y at line Z" sure beats
"the program died.".

Re: Perhaps there _is_ a conspiracy against Ada

[Kevin Cline]

tmoran@bix.com wrote:

>>And just how did you attach callback functions to GUI objects
>  You are quite right for the Macintosh where the (Meridian)
>compiler supplied a binding to the Mac OS that used their way
>of doing things.  But event driven under DOS did not need callbacks,
>because DOS didn't use callbacks.  It just had a looping task that
>called things (as well as separate tasks for some of the audio+video).
>

I was delivering for various workstation makes, using X/Motif.
I guess portability is no longer important since M$ has shown us the one true
way.

I wrote
>>2. I find it faster to add events to debugger breakpoints when I find a
>>testing error than to add a bunch of gratuitious print statements
>>that I will later have to remove.
>  No, the 'print something...' did not mean 'insert print statements'.
>The compiler's run-time-system automatically generated those messages
>for any unhandled exception.  

Not every erroneous Ada program crashes.  Sometimes they just don't behave as
you expect.

> And (unless you turned off checking) ...

I'm not the type to turn off checking while testing.

Re: Perhaps there _is_ a conspiracy against Ada

[Matthew Givens]

No conspiracy, just the realization that Ada doesn't fit in most 
environments.  Or rather, that other languages fit better in most 
business environments.

For example, I am a computer programmer working for a civilian contractor.
  We write software for the Air Force.  To be exact, we write mobility 
software (basically a database with a GUI).  Even the client is starting 
to realize that Ada isn't the best language for the job.  Not that it 
does them any good, since the AF is still doing all new code development 
in Ada.

I wish these guys would learn the concept of "Specific Tools for Specific 
Jobs."

-
"Outside of a dog, a book is a Man's best friend.  Inside of a dog it's 
very dark." << Iceman >>

Re: Perhaps there _is_ a conspiracy against Ada

[Matthew Givens]

Tom Moran <tmoran@bix.com> wrote:
>
>> I wish these guys would learn the concept of "Specific Tools for 
Specific 
>> Jobs."
>  Isn't that the flip side of the "thousands of incompatible langauges"
>that Ada was created to get away from?

Yes, it is.  However, it happens to be true.  Ada isn't right for all 
jobs, and shouldn't be treated as if it is.  The government should choose 
a number of languages (preferably small) to develop software, so they can 
combine the flexibility argument with the "too many language" argument 
and get a good compromise.

-
"Outside of a dog, a book is a Man's best friend.  Inside of a dog it's 
very dark." << Iceman >>

Re: Perhaps there _is_ a conspiracy against Ada

[Robert Dewar]

Matthew said

<<Yes, it is.  However, it happens to be true.  Ada isn't right for all
jobs, and shouldn't be treated as if it is.>>

True, but in practice a lot of decisions to use some other language than
Ada are based on no good technical reasoning at all, just prejudice and
familiarity.

Re: Perhaps there _is_ a conspiracy against Ada

[Matthew Givens]

Ken Garlington <GarlingtonKE@lmtas.lmco.com> wrote:
>
>Matthew Givens wrote:
>
>Is your client requesting waivers for such software, even under the
>current
>policy? If not, why not?

At the moment, the word is that no waivers are being granted.  All new 
software (at least on our project) will be written in Ada.

-
"Outside of a dog, a book is a Man's best friend.  Inside of a dog it's 
very dark." << Iceman >>

Re: Perhaps there _is_ a conspiracy against Ada

[Robert Dewar]

i<<At the moment, the word is that no waivers are being granted.  All new
software (at least on our project) will be written in Ada.>>

That sounds totally bogus, waivers are always granted where the conditions
are met for a waiver if it is clear that the conditions are met.

Re: Perhaps there _is_ a conspiracy against Ada

[Robert Dewar]

Ken said

<<In fact, the NRC study recognizes that Ada may not always be the best
solution
for this class of software, and it appears that DoD will be implementing
much of this study's recommendations.

Is your client requesting waivers for such software, even under the
current
policy? If not, why not?>>


Note that in the world where one is pushed strongly towards using Ada, there
tends to be an unhealthy dichotomy between two extremes:

1. OK, we will do it 100% in Ada because we have to

2. We will dump Ada completely, and do it in xxx (either getting a waiver
   or ignoring the rules).

From a technical point of view, it is often the case that the best solution
is a mixed one in which parts that are suitable are done in Ada, and parts
that are better done in some other environment (e.g. use of some already
establishd libraries) is done in some other language.

Re: Perhaps there _is_ a conspiracy against Ada

[Alan Brain]

Matthew Givens wrote:
> 
> No conspiracy, just the realization that Ada doesn't fit in most
> environments.  Or rather, that other languages fit better in most
> business environments.

The first real-world C program I did was in 1980. Since 1983 I've been
trying to convince C hackers about the benefits of Ada. Those that
actually were forced to do some real project in Ada were quickly
converted. But mainly, no-one tried.

Trying to tell people about the benefits often leads to complete
stonewalling. There has to be a logical reason for this - few
programmers have low IQs.

I've finally become convinced that C really IS better than Ada, for the
following reasons:


FOR THE PROGRAMMER

..Hacking away in C is fun, you can add trapdoors and trojan horses real
easy

..You can write neat stuff like the following code fragments:

    #define BITCOUNT(x)      (((BX_(x)+(BX_(x)>>4)) & 0x0F0F0F0F) % 255)
    #define BX_(x)            ((x) - (((x)>>1)&0x77777777)  \
                                   - (((x)>>2)&0x33333333)  \
                                   - (((x)>>3)&0x11111111)
    p = BX_(n);

    n = ((n>>1)  & 0x55555555) | ((n<<1)  & 0xaaaaaaaa);
    n = ((n>>2)  & 0x33333333) | ((n<<2)  & 0xcccccccc);
    n = ((n>>4)  & 0x0f0f0f0f) | ((n<<4)  & 0xf0f0f0f0);
    n = ((n>>8)  & 0x00ff00ff) | ((n<<8)  & 0xff00ff00);
    n = ((n>>16) & 0x0000ffff) | ((n<<16) & 0xffff0000);

   which is difficult to understand, and makes you look really, really
clever, even though it does something utterly trivial ( p is the number
of
bits in n, and n ends up with its bit order reversed )

..You'll always have a secure job, trying to make sense of other
people's code after they've left

..You'll always have a secure job, as with well-written, terse, tight
and efficient C YOU are the ONLY one who can easily understand your own
code!

..You'll always have a secure job, as large C programs always have lots
of bugs, and require oodles of maintenance

..Compiling is really easy - even when the stuff you're compiling is
utter garbage, the compiler won't tell on you

..You can ignore most of your coding errors until quite late in the day
- with any luck, until you've left the project


FOR THE SUPPLIER

..You can always find C hackers, and they're dirt cheap

..With C, you get the initial build done quick, cheap and dirty, and
make a fortune over the next 10 years putting in new bugs while removing
old
ones.


FOR THE CUSTOMER

..Because programmers and suppliers tell you so.



Ada is worse than C because

..Only Anal-retentive weenies who mumble about Quality and
Professionalism would get any fun out of Ada

..You'd get into the habit of writing stuff like

   with MACHINE_SPECIFIC;

   procedure COUNT_BITS_AND_REVERSE
     ( THE_WORD  : in out MACHINE_SPECIFIC.WORD_TYPE,
       THE_COUNT :    out MACHINE_SPECIFIC.BIT_COUNT_TYPE
     ) is

   declare

     package BIT_OPS renames MACHINE_SPECIFIC.BIT_OPERATIONS;

   begin

     THE_COUNT := BIT_OPS.BIT_COUNT_OF(THE_WORD);
     BIT_OPS.REVERSE_BIT_ORDER_OF(THE_WORD);

   exception
 
     when others => raise CODE_CORRUPTED_OR_HARDWARE_ERROR;

   end COUNT_BITS_AND_REVERSE;

   which any programmer can easily understand, even though it does trap
some of the errors caused by the over-running array bounds in the C
you've
had to PRAGMA INTERFACE to, soft errors, and hardware glitches.
   Not only that, it works on 16, 32, 64, 48 etc bit machines as well.
So you can't get lots of bucks writing different versions.
   And then the compiler barfs, and tells you what you've done wrong!

..You spend a long time looking for a job, as your code on the last
project worked so well that the project completed on time, and you were
no
longer needed.

..You spend a long time looking for a job, as the maintenance effort
needed consisted of 2 part-timers rather than the whole development team

..You spend a long time looking for a job, as no-one uses Ada

..Getting a Clean Compile of anything non-trivial is quite difficult.

..Your Ego takes a hammering by the compiler constantly showing you
where you made mistakes. And if not the compiler, the Linker!


FOR A SUPPLIER

..Ada programmers are rare and expensive. You can't hire cheap graduate
coolies.

..It costs more initially to make a system, and it takes longer. Much
worse, there's almost no maintenance, so your only revenue is from the
initial sale.


FOR A CUSTOMER

..Because the programmers and suppliers tell you so.


That's the bottom line, people. The only people who benefit from Ada are
the customers and users. The user riding on a 777 generally doesn't know
that any programming was involved, and the customers rely on advice from
their
suppliers.

Until we understand that, all arguments regarding the qualities of Ada
are irrelevant.     


aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
100026.2014 compuserve o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale
See http://www.z-world.com/graphics/z/master/8856.gif for picture

Re: Perhaps there _is_ a conspiracy against Ada

[Kevin Cline]

Alan Brain <aebrain@dynamite.com.au> wrote:


>
>The first real-world C program I did was in 1980. Since 1983 I've been
>trying to convince C hackers about the benefits of Ada. Those that
>actually were forced to do some real project in Ada were quickly
>converted. But mainly, no-one tried.

All the benefits were there, but you skipped all the drawbacks that weren't
remedied until GNAT and Ada '95.

1. No standard bindings to UNIX or X-Windows or anything else beyond the most
rudimentary I/O facilities.  Every compiler vendor rolled his own.
Portability?  Forget about it.  Compared to Ada '83, porting C programs was
easy.

2. No support for functions as objects.  This made it impossible to write
event-driven programs without resorting to yet another vendor-specific hack.

3. Extremely poor quality compilers.  I know; I tried a bunch of them: Verdix,
Telesoft (before the were bought by Alsys), and Alsys.

4. Ridiculously pitiful debuggers.

5. A complete lack of other supporting software, like performance profilers.

And no one mentions that Ada is no better than C or C++ for storage
management.  It's not a problem in embedded systems, where the problem size is
carefully bounded and dynamic allocation is simply avoided, but it's a big
problem for desktop applications.

Ada '83 had some great features, but it was useless for the vast majority of
developers for these reasons.  When Ada '95 appeared TWELVE! years later,
it was too late.  We know that software developed in C++ can be delivered, but
most organizations have no experience using Ada for commercial applications.
And few companies are willing to bet a million dollars to find out if it will
work.  So stop complaining about lazy C++ programmers, get off the government
dole, and join the real world.

Re: Perhaps there _is_ a conspiracy against Ada

[Tom Moran]

clines@delete_this.airmail.net (Kevin Cline) said:
> 2. No support for functions as objects.  This made it impossible to write
> event-driven programs without resorting to yet another vendor-specific hack.
  Having done event driven programs in Ada on both PC and Mac I can
testify that it was not only possible, but rather easy.  Ada also had
the advantage that multitasking paradigms in addition to "event-driven"
could be easily used without having to roll your own tasking supervisor.
 
> 3. Extremely poor quality compilers.  I know; I tried a bunch of them: Verdix,
> Telesoft (before the were bought by Alsys), and Alsys.
  I can't speak to any of those, but the RR compiler I used was quite
good.  Perhaps you were simply unlucky in your choice of compilers.
  
> 4. Ridiculously pitiful debuggers.
  Having the program print something like "Constraint Error, value = -1"
and a traceback sure beats setting breakpoints in a program whose bug
symptom is a system crash.
 
> 5. A complete lack of other supporting software, like performance profilers.
  Perhaps on the compilers you used. There was a nice profiler with the
RR PC compiler.
Admittedly, it came with the "Pro" version, not the $99 version.  I
can't seem to recall any profiler coming with the "Borland C++ 3.1" or
the Computer Innovations C compilers that I used in the same time frame.

Re: Perhaps there _is_ a conspiracy against Ada

[Kevin Cline]

Tom Moran <tmoran@bix.com> wrote:

>
>clines@delete_this.airmail.net (Kevin Cline) said:
>> 2. No support for functions as objects.  This made it impossible to write
>> event-driven programs without resorting to yet another vendor-specific hack.
>  Having done event driven programs in Ada on both PC and Mac I can
>testify that it was not only possible, but rather easy.  Ada also had
>the advantage that multitasking paradigms in addition to "event-driven"
>could be easily used without having to roll your own tasking supervisor.

And just how did you attach callback functions to GUI objects 
since the language did not support passing functions or procedures as
arguments?  Sure, each vendor defined a way to do that, but I had a
requirement to port this program to multiple architectures and compilers.

> 
>> 3. Extremely poor quality compilers.  I know; I tried a bunch of them: Verdix,
>> Telesoft (before the were bought by Alsys), and Alsys.
>  I can't speak to any of those, but the RR compiler I used was quite
>good.  Perhaps you were simply unlucky in your choice of compilers.

Not 100% sure, but I don't believe the RR compiler supported SGI
or Sun in 1991.

>> 4. Ridiculously pitiful debuggers.
>  Having the program print something like "Constraint Error, value = -1"
>and a traceback sure beats setting breakpoints in a program whose bug
>symptom is a system crash.

1. At least one of the Ada compilers I used was incapable of producing a
backtrace.

2. I find it faster to add events to debugger breakpoints when I find a
testing error than to add a bunch of gratuitious print statements
that I will later have to remove.  

Re: Perhaps there _is_ a conspiracy against Ada

[Robert Dewar]

<<And just how did you attach callback functions to GUI objects
since the language did not support passing functions or procedures as
arguments?  Sure, each vendor defined a way to do that, but I had a
requirement to port this program to multiple architectures and compilers.>>

The ability to port a program does not mean that you require that the
program be movable with zero changes, just that the parts that need
changing are well defined and easily changed.

In fact a number of compilers implemented the semi-standard for subprogram
pointers defined by the CIFO specification, so programs written to the
CIFO spec would in fact work on quite a variety of compilers.

Note that if you required 100% portability with zero change, then you
would say that no C program is portable, which is an exaggeration!

Re: Perhaps there _is_ a conspiracy against Ada

[Kevin Cline]

dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

><<And just how did you attach callback functions to GUI objects
>since the language did not support passing functions or procedures as
>arguments?  Sure, each vendor defined a way to do that, but I had a
>requirement to port this program to multiple architectures and compilers.>>
>
>The ability to port a program does not mean that you require that the
>program be movable with zero changes, just that the parts that need
>changing are well defined and easily changed.

Well-defined?  Certainly.  Easily changed?  Not without resorting
to some macro preprocessor that would have confused Ada compilers and
debuggers ignorant of anything equivalent to # source line directives.

>In fact a number of compilers implemented the semi-standard for subprogram
>pointers defined by the CIFO specification, so programs written to the
>CIFO spec would in fact work on quite a variety of compilers.

Which ones, and when?  "A variety of compilers" didn't include the varieties
I was using.

>Note that if you required 100% portability with zero change, then you
>would say that no C program is portable, which is an exaggeration!

The techniques for writing portable C in 1991 were simple and well-known,
and a single set of source files could be made to work on a very large number
of hardware and operating system combinations.
Most of the portability problems for C programs were actually due to
variations in operating system services, which couldn't even be called in a
standard way using  Ada-83.  With no preprocessor, working around Ada-83's
missing features was considerably more aggravation.

Re: Perhaps there _is_ a conspiracy against Ada

[Alan Brain]

Kevin Cline wrote:
... a whole heap of stuff that I agree with, close to 100% in fact.

Plus:

> Ada '83 had some great features, but it was useless for the vast majority of
> developers for these reasons.  When Ada '95 appeared TWELVE! years later,
> it was too late.  We know that software developed in C++ can be delivered, but
> most organizations have no experience using Ada for commercial applications.
> And few companies are willing to bet a million dollars to find out if it will
> work.  So stop complaining about lazy C++ programmers, get off the government
> dole, and join the real world.

???? Sorry, no can do. I've never worked for the US Government, nor for
the US DoD. (OK, so some of my code did work its way onto USN ships).
Never been on the Dole either (even when unemployed). And C++
programmers are NOT lazy. Heck, the job I'm in at the moment means I
have to program in C++, and it's at least 5 times as much work to do the
same task as in Ada-95.
 
-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
100026.2014 compuserve o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale
See http://www.z-world.com/graphics/z/master/8856.gif for picture

Perhaps there _is_ a conspiracy against Ada

[Larry Kilgallen]

A discussion in a another venue involved two VMS folk, one of whom
used to work in the (non-military) shop where the other still worked.
The topic was Ada, and the departed employee asked whether the shop
was still using Ada.  The response was that yes, existing VMS systems
were still using Ada, but lately the shop was using more Windows NT
so it was unlikely that Ada would be used in the future unless someone
came up with an Ada compiler for Windows NT !

Larry Kilgallen

Re: Perhaps there _is_ a conspiracy against Ada

[Robert Dewar]

Nick Roberts said

<<Windows NT Ada compiler EXE size: 302KB
Binding to NT API size: 4MB (and growing daily)>>

Can you explain what you are talking about here???

Re: Perhaps there _is_ a conspiracy against Ada

[Robert Dewar]

Tom said

<<> Windows NT Ada compiler EXE size: 302KB
> Binding to NT API size: 4MB (and growing daily)

                          ^^^
Dear me, that's almost as bad as Visual Basic...>>


Yes, but unfortunately there is no "binding to NT API" that is anything
like 4MB, I have no idea what this is talking about ...

Re: Perhaps there _is_ a conspiracy against Ada

[Stephen Leake]

Robert Dewar wrote:
> 
> Tom said
> 
> <<> Windows NT Ada compiler EXE size: 302KB
> > Binding to NT API size: 4MB (and growing daily)
> 
>                           ^^^
> Dear me, that's almost as bad as Visual Basic...>>
> 
> Yes, but unfortunately there is no "binding to NT API" that is anything
> like 4MB, I have no idea what this is talking about ...

The source for Win32Ada occupies 5.50 MB, according to Win95. I don't
have it compiled, so I don't know what the object size is. Maybe this is
what he's talking about?

-- 
- Stephe