What is wrong with Ada?

What is wrong with Ada?

[martinbishop]

I've never been scared of "non mainstream" languages, but I was
wondering, what is wrong with Ada?  Why don't more people use it?
What
do most people think of it?  To me, it seems like a nice, concise, and
safe language, but I haven't used it yet.

Re: What is wrong with Ada?

[Chip and Allie Orange]

"martinbishop" <jedibebop@gmail.com> wrote in message 
news:1176150704.130880.248080@l77g2000hsb.googlegroups.com...
> I've never been scared of "non mainstream" languages, but I was
> wondering, what is wrong with Ada?  Why don't more people use it?
> What
> do most people think of it?  To me, it seems like a nice, concise, and
> safe language, but I haven't used it yet.
>

Hi Martin,

I'm just now starting to learn Ada, but I've been "looking at it" for quite 
a while.  I'd say the answer to your question is that no one uses it much, 
because, no one uses it much.

My boss won't allow anything at work that isn't already being used by 
everyone else.  A lot of software choices are made for more or less those 
reasons.  As a corollary to this, it's impossible for us to hire anyone with 
Ada programming experience, as an entry level programmer, and hiring someone 
without experience in your software development systems of choice "just 
isn't done".  Since what we have access to are endless visual studio 
programmers, that was used as an argument for what we should be using to 
develop with.

The other reason I see is that it's not easily compatible with ActiveX, COM, 
.net, and all the other interfacing standards that development add-ons are 
sold for (in the Windows world).  It's advantages of taking less effort, in 
the long term, to maintain a given project, are offset by having to "roll 
your own" everything in the beginning.


Just a newbie's outside view, but maybe you'll want to do what I'm doing: 
jump in and begin preaching to the unconverted!

    Chip

Re: What is wrong with Ada?

[Jeffrey R. Carter]

martinbishop wrote:
> I've never been scared of "non mainstream" languages, but I was
> wondering, what is wrong with Ada?  Why don't more people use it?
> What
> do most people think of it?  To me, it seems like a nice, concise, and
> safe language, but I haven't used it yet.

Nothing is wrong with Ada. It is a language for SW engineers. Since 98% 
of SW developers are coders, not SW engineers, 98% prefer languages for 
coders.

-- 
Jeff Carter
"Oh Lord, bless this thy hand grenade, that with it thou
mayst blow thine enemies to tiny bits, in thy mercy."
Monty Python and the Holy Grail
24

Re: What is wrong with Ada?

[Brian May]

>>>>> "martinbishop" == martinbishop  <jedibebop@gmail.com> writes:

    martinbishop> I've never been scared of "non mainstream"
    martinbishop> languages, but I was wondering, what is wrong with
    martinbishop> Ada?  Why don't more people use it?  What do most
    martinbishop> people think of it?  To me, it seems like a nice,
    martinbishop> concise, and safe language, but I haven't used it
    martinbishop> yet.

This was discussed recently.

See http://groups.google.com.au/group/comp.lang.ada/browse_thread/thread/21960280f1d61e84/4f32ef40e541eff7
-- 
Brian May <bam@snoopy.apana.org.au>

Re: What is wrong with Ada?

[martinbishop]

On Apr 9, 8:25 pm, Brian May <b...@snoopy.apana.org.au> wrote:
> >>>>> "martinbishop" == martinbishop  <jedibe...@gmail.com> writes:
>
>     martinbishop> I've never been scared of "non mainstream"
>     martinbishop> languages, but I was wondering, what is wrong with
>     martinbishop> Ada?  Why don't more people use it?  What do most
>     martinbishop> people think of it?  To me, it seems like a nice,
>     martinbishop> concise, and safe language, but I haven't used it
>     martinbishop> yet.
>
> This was discussed recently.
>
> Seehttp://groups.google.com.au/group/comp.lang.ada/browse_thread/thread/...
> --
> Brian May <b...@snoopy.apana.org.au>

Ahh, Thanks for that.

I've seen Ada "benchmarks", and it seems the compiler is great, and
the language seems really nice (verbose, but I kind of like that over
languages like Haskell and such).  I figured most people didn't use it
for business or just general popularity reasons, but I thought there
might be some hidden "bad things" or something.

Thanks for all the replies

Re: What is wrong with Ada?

[gautier_niouzes]

"Chip and Allie Orange":

> The other reason I see is that it's not easily compatible with ActiveX, COM,
> .net, and all the other interfacing standards that development add-ons are
> sold for (in the Windows world).  It's advantages of taking less effort, in
> the long term, to maintain a given project, are offset by having to "roll
> your own" everything in the beginning.

Did you look at GNATCOM ?
It provides automated interfacing with COM for the GNAT Ada compiler.
______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: What is wrong with Ada?

[gautier_niouzes]

> Ahh, Thanks for that.
>
> I've seen Ada "benchmarks", and it seems the compiler is great, and
> the language seems really nice (verbose, but I kind of like that over
> languages like Haskell and such).  I figured most people didn't use it
> for business or just general popularity reasons, but I thought there
> might be some hidden "bad things" or something.

No bad thing, only bad marketing (at least in the early days)!
______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: What is wrong with Ada?

[Pascal Obry]

Jeffrey R. Carter a �crit :

> Nothing is wrong with Ada. It is a language for SW engineers. Since 98%
> of SW developers are coders, not SW engineers, 98% prefer languages for
> coders.

Agreed 100%. Another way to put it, let me ask : What's wrong with
developers ? Why do they like unsafe languages ? Why do they like
fighting a language all the time ? Why do they like unreadable code ?
Why do they like to play with a debugger ? Why do they like to play
Sherlock Holmes during hours to look for a bug ? Here are the real
questions to me, again nothing wrong with Ada to me !

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: What is wrong with Ada?

[Markus E Leypold]

Pascal Obry <pascal@obry.net> writes:

> Jeffrey R. Carter a �crit :
>
>> Nothing is wrong with Ada. It is a language for SW engineers. Since 98%
>> of SW developers are coders, not SW engineers, 98% prefer languages for
>> coders.
>
> Agreed 100%.

I don't. It's the attidute that is off-putting and gives software
engineering a bad name.

> Another way to put it, let me ask : What's wrong with
> developers ? Why do they like unsafe languages ? 

I think I already answered that. Still, on c.l.a, the myth persists
that "developers like unsafe languages". In actual reality it's the
other way round: For one reason or other -- as I explained often
enough, not related to technical merits of the languages in question
-- people like other languages, they just happen to be "unsafe".

(And even that might be questioned, since the big contenders at large
are (probably in that order) Excel, Php, Perl, Python and not only C
... -- Excel and the 3 Ps are not unsafe in the same sense as C/C++
are).


> Why do they like fighting a language all the time?

Well -- difficult to say: Why _are_ there language wars at c.l.a all
the time? Why does the Ada folks like to fight Java and C++? Somebody
here should be in the position to answer that question.

> Why do they like unreadable code?

> Why do they like to play with a debugger ? 

Good question. That "real Ada software engineers" (like "real men")
never need a debugger might be the reason why gdb is so badly
integrated with Gnat. That's a thought. 

BTW, the OP asked, I think, what is wrong with Ada. Just now I
remember: For one thing, the gdb <=> gnat integration.

> Why do they like to play Sherlock Holmes during hours to look for a
> bug?

Strange. That would mean, Ada programs have no bugs. That is indeed
new to me. And believe me, the conceptual bugs (as opposed to type
system violations) are the bugs that are harder to discover and to
debug -- and for those a well integrated debugger is really useful
when they occur.

> Here are the real
> questions to me, again nothing wrong with Ada to me !

Pascal, you're person which a proven track record and a good standing
in the Ada community (whereas I'm probably better known as a constant
complainer, but hope that I have my reasons). But THIS post is
absolute nonsense and not worthy to yourself.

I'm not so young myself but I dislike it, when people (metaphorically)
lean back in their rocking chairs and start (metaphorically)
complaining about the youth of today and how everything was better at
their time.

Regards -- Markus

Re: What is wrong with Ada?

[Markus E Leypold]

"martinbishop" <jedibebop@gmail.com> writes:

> On Apr 9, 8:25 pm, Brian May <b...@snoopy.apana.org.au> wrote:
>> >>>>> "martinbishop" == martinbishop  <jedibe...@gmail.com> writes:
>>
>>     martinbishop> I've never been scared of "non mainstream"
>>     martinbishop> languages, but I was wondering, what is wrong with
>>     martinbishop> Ada?  Why don't more people use it?  What do most
>>     martinbishop> people think of it?  To me, it seems like a nice,
>>     martinbishop> concise, and safe language, but I haven't used it
>>     martinbishop> yet.
>>
>> This was discussed recently.
>>
>> Seehttp://groups.google.com.au/group/comp.lang.ada/browse_thread/thread/...
>> --
>> Brian May <b...@snoopy.apana.org.au>
>
> Ahh, Thanks for that.
>
> I've seen Ada "benchmarks", and it seems the compiler is great, and
> the language seems really nice (verbose, but I kind of like that over
> languages like Haskell and such).  I figured most people didn't use it
> for business or just general popularity reasons, but I thought there
> might be some hidden "bad things" or something.

One "bad" thing (but that might not touch you) is availability of
compilers: There is a number of plain commercial compilers, some stuff
that is free as in beer (i.e. not avialable in 2 years from now) and
finally GNAT. GNAT comes in 2 versions: The FSF version which has a
run time with a linking exception and the AdaCore version which is
either available with a GPL runtime license or a (not quite so cheap)
paid license which has a linking excepetion.

That means, with the AdaCore "free" version you can only build GPLed
software, since the runtime is linked against the executable. 

It is, I think, important to point that out, since here the situation
is different from what is custom with other "free" compilation systems
(where the use of a certain compiler rarely affects the license under
which you have to distribute your executables).

Problem with the FSF version (which would have the linikng exception)
is, that it is integrated in the GCC source tree now, but there are no
QC'd releases with GCC, so its not always in a good shape, the efforts
of various vounteers notwithstanding.

Also support for compiler versions on various platforms (Windows,
Linux, *BSD, VMS, ...) is varies: The Linux support is really good
(esp. on Debian), but often only old or unstable versions (Windows:
AFAIK you only get a old MingW version or 3.15p), or the AdaCore
version is available. For VMS it has been a long time anybody has
actually seen a free version.

(My research might not be up to date any more, so anybody here in
c.l.a. is welcome to correct me here).

One further thing you might consider, is, that AdaCore recently has
stripped the linking exception from a number of libraries (Florist,
GtkAda, PolyOrb) which they partly developed and traditionally
maintained. No community fork has happened at the time which preserved
the original more liberal licenses, so at the moment a number of
important libraries are only publicly available for GPL development.

This again is different from what you'll find in other language
communities. Most other languages (to take on example) have either no
GTK binding (which often is an indication that the language has only
few followers any more or is not used for user application
programming) or if it exists, it is under LGPL or similar. With Ada
the situation is different: GtkAda is under strict GPL and doesn't
even compile with other (Windows or Linux PC) Ada compilers
AFAIK. Other bindings are completely platform specific (like CLAW) and
proprietary. (Again that might not be a bad thing dependend on what
you intend to do with it).

You'll find similar situation for a number of other libraries.

There are free libraries, though, like Tash (a Ada-Tk binding) and a
number of excellent data structure and container libaries.

So to wrap it up: There is nothing wrong with the language per se, but
dependend on what you might want to do with it, the availability of
tools and libraries and the conditions to which they are available
might affect you or not.

Regards -- Markus

Re: What is wrong with Ada?

[Pascal Obry]

Markus,

>> Why do they like unreadable code?
> 
>> Why do they like to play with a debugger ? 
> 
> Good question. That "real Ada software engineers" (like "real men")
> never need a debugger might be the reason why gdb is so badly
> integrated with Gnat. That's a thought. 

gdb is used with Ada just not so often.

>> Why do they like to play Sherlock Holmes during hours to look for a
>> bug?
> 
> Strange. That would mean, Ada programs have no bugs. That is indeed

No, did not say that. But I certainly do not enjoy that and I have far
less this role when programming in Ada than in C++.

>> Here are the real
>> questions to me, again nothing wrong with Ada to me !
> 
> Pascal, you're person which a proven track record and a good standing
> in the Ada community (whereas I'm probably better known as a constant
> complainer, but hope that I have my reasons). But THIS post is
> absolute nonsense and not worthy to yourself.

Well maybe because I've been "fighting"[1] a C++ application recently to
work properly. An application full of bugs, awful buffer overflows,
unreadable... so I'm probably tired and have less control over myself :)

Pascal.

[1] : given the context I really think fighting is the proper word

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: What is wrong with Ada?

[Markus E Leypold]

Pascal Obry <pascal@obry.net> writes:

> Markus,
>
>>> Why do they like unreadable code?
>> 
>>> Why do they like to play with a debugger ? 
>> 
>> Good question. That "real Ada software engineers" (like "real men")
>> never need a debugger might be the reason why gdb is so badly
>> integrated with Gnat. That's a thought. 
>
> gdb is used with Ada just not so often.

Right. But when it is used, it is sorely needed, since this then is
one of the conceptual bugs I mentioned.


>>> Why do they like to play Sherlock Holmes during hours to look for a
>>> bug?
>> 
>> Strange. That would mean, Ada programs have no bugs. That is indeed

> No, did not say that. But I certainly do not enjoy that and I have far
> less this role when programming in Ada than in C++.

Agreed. Still, we are talking about 2 different kinds of bugs
here. Stray pointers, integer overflows (which usually lead to
straxing pointers), heap corruption and so on are all very annoying
and certainly don't occur in Ada so often (but they do: It's possible
to read quite a lot of nonsense from a Stream and if the compiler
itself produces the bug all bets are off ... :-( ). But that doesn't
mean I could avoid looking for bugs (for hours) in Ada programs. So
Adas type system is NOT a way to "avoid bugs" but to avoid unsafe
execution (which is 

My complaint, BTW, with C/C++ would not the type system so much (it
slows you down by a constant but predicatable factor, but it is
managable) but rather the absence of local procedure and useful
generics. And with time I've found that really sucks: It's almost
impossible to write a non trivial reusable component without
implementing some kind of meta compiler.

I'm bit surprised that everybody focuses so much on the type system
(every time one of these threads occur): Lack of generics is - in my
eyes - a much more serious problem and (until recently) also plagued
languages that had (more or less) a safe type system.

>>> Here are the real
>>> questions to me, again nothing wrong with Ada to me !
>> 
>> Pascal, you're person which a proven track record and a good standing
>> in the Ada community (whereas I'm probably better known as a constant
>> complainer, but hope that I have my reasons). But THIS post is
>> absolute nonsense and not worthy to yourself.

> Well maybe because I've been "fighting"[1] a C++ application recently to
> work properly. An application full of bugs, awful buffer overflows,
> unreadable... so I'm probably tired and have less control over myself :)

Oh well - I real can understand that. But since I've also been
"fighting" other software written in supposedly better languages, I
think the problem is more one of bad software engineering. You would
perhaps have had a better start (because _you_ could read the source
easier) if the application had been in C++, but from my experience
there are bad apps out there in every, also supposedly good,
languages. Often it's the interface documentation that makes or breaks
a day (and just to point a bit back to the Ada world: GtkAda is not
glowing example in this respect). 

The factor that contributes most to unusability of unfixability of
software is perhaps, that many people who release software, just
release "source", not a product. A product has at least some semblance
of user documentation (how, when and for what do I use it, how do I
trouble shoot etc.). Free software often doesn't have that. Commercial
bespoke software often hasn't got it, too -- simply because the
customer is not willing to pay it, the project has taken more time and
effort than planned and the contractor has to cut corners because the
customers is not willing to extend the contract. Short sighted on both
sides (but mostly on the customers side).

>
> [1] : given the context I really think fighting is the proper word

:-).


Regards -- Markus

Re: What is wrong with Ada?

[Jeffrey R. Carter]

Pascal Obry wrote:
> Jeffrey R. Carter a �crit :
> 
>> Nothing is wrong with Ada. It is a language for SW engineers. Since 98%
>> of SW developers are coders, not SW engineers, 98% prefer languages for
>> coders.
> 
> Agreed 100%. Another way to put it, let me ask : What's wrong with
> developers ? Why do they like unsafe languages ? Why do they like
> fighting a language all the time ? Why do they like unreadable code ?
> Why do they like to play with a debugger ? Why do they like to play
> Sherlock Holmes during hours to look for a bug ? Here are the real
> questions to me, again nothing wrong with Ada to me !

The answer is: because they're coders, not SW engineers.

Let's get circular.

-- 
Jeff Carter
"Run away! Run away!"
Monty Python and the Holy Grail
58

Re: What is wrong with Ada?

[Jean-Pierre Rosen]

Markus E Leypold a �crit :
> Pascal Obry <pascal@obry.net> writes:
> 
>> Markus,
>>
>>>> Why do they like unreadable code?
>>>> Why do they like to play with a debugger ? 
>>> Good question. That "real Ada software engineers" (like "real men")
>>> never need a debugger might be the reason why gdb is so badly
>>> integrated with Gnat. That's a thought. 
>> gdb is used with Ada just not so often.
> 
> Right. But when it is used, it is sorely needed, since this then is
> one of the conceptual bugs I mentioned.
> 
Sorry, but I beg to disagree here. Conceptual bugs are found by 
reasonning on the source, not with a debugger. Every now and then you 
may need to check the value of a variable at some point in execution to 
validate or invalidate an hypothesis, but even there, I find a proper 
trace message much faster and more precise than using a debugger.
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: What is wrong with Ada?

[Dmitry A. Kazakov]

On Tue, 10 Apr 2007 15:59:27 GMT, Jeffrey R. Carter wrote:

> Pascal Obry wrote:
>> Jeffrey R. Carter a �crit :
>> 
>>> Nothing is wrong with Ada. It is a language for SW engineers. Since 98%
>>> of SW developers are coders, not SW engineers, 98% prefer languages for
>>> coders.
>> 
>> Agreed 100%. Another way to put it, let me ask : What's wrong with
>> developers ? Why do they like unsafe languages ? Why do they like
>> fighting a language all the time ? Why do they like unreadable code ?
>> Why do they like to play with a debugger ? Why do they like to play
>> Sherlock Holmes during hours to look for a bug ? Here are the real
>> questions to me, again nothing wrong with Ada to me !
> 
> The answer is: because they're coders, not SW engineers.
> 
> Let's get circular.

Let me break the circle:

It is because SW engineering is not engineering. And that is because CS is
not much science. It rather sways between applied mathematics and "stamp
collecting."

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: What is wrong with Ada?

[Chad R. Meiners]

On Apr 10, 12:12 pm, Jean-Pierre Rosen <r...@adalog.fr> wrote:
> Markus E Leypold a écrit :> Pascal Obry <pas...@obry.net> writes:
>
> >> Markus,
>
> >>>> Why do they like unreadable code?
> >>>> Why do they like to play with a debugger ?
> >>> Good question. That "real Ada software engineers" (like "real men")
> >>> never need a debugger might be the reason why gdb is so badly
> >>> integrated with Gnat. That's a thought.
> >> gdb is used with Ada just not so often.
>
> > Right. But when it is used, it is sorely needed, since this then is
> > one of the conceptual bugs I mentioned.
>
> Sorry, but I beg to disagree here. Conceptual bugs are found by
> reasonning on the source, not with a debugger. Every now and then you
> may need to check the value of a variable at some point in execution to
> validate or invalidate an hypothesis, but even there, I find a proper
> trace message much faster and more precise than using a debugger.
> --
> ---------------------------------------------------------
>             J-P. Rosen (r...@adalog.fr)
> Visit Adalog's web site athttp://www.adalog.fr


I disagree. Sometimes trace messages add line noise and maintaince
requirements to the code base, and it is much easier to trace through
the algorithm step by step (using conditional breaks when necessary).
It is particularly handy to use a debugger when interfacing to other
people's component libraries.  That being said, trace messages are
usually very efficient too.

cavat: I have found debuggers more useful in languages like C++ than
Ada, but then again Visual Studios has an excellent debugger.

Re: What is wrong with Ada?

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Tue, 10 Apr 2007 15:59:27 GMT, Jeffrey R. Carter wrote:
>
>> Pascal Obry wrote:
>>> Jeffrey R. Carter a �crit :
>>> 
>>>> Nothing is wrong with Ada. It is a language for SW engineers. Since 98%
>>>> of SW developers are coders, not SW engineers, 98% prefer languages for
>>>> coders.
>>> 
>>> Agreed 100%. Another way to put it, let me ask : What's wrong with
>>> developers ? Why do they like unsafe languages ? Why do they like
>>> fighting a language all the time ? Why do they like unreadable code ?
>>> Why do they like to play with a debugger ? Why do they like to play
>>> Sherlock Holmes during hours to look for a bug ? Here are the real
>>> questions to me, again nothing wrong with Ada to me !
>> 
>> The answer is: because they're coders, not SW engineers.
>> 
>> Let's get circular.
>
> Let me break the circle:
>
> It is because SW engineering is not engineering. And that is because CS is
> not much science. It rather sways between applied mathematics and "stamp
> collecting."

Two completely unrealistic and untenable attitudes. Both of you.

Regards -- Markus

Re: What is wrong with Ada?

[Markus E Leypold]

Jean-Pierre Rosen <rosen@adalog.fr> writes:

> Markus E Leypold a �crit :
>> Pascal Obry <pascal@obry.net> writes:
>>
>>> Markus,
>>>
>>>>> Why do they like unreadable code?
>>>>> Why do they like to play with a debugger ?
>>>> Good question. That "real Ada software engineers" (like "real men")
>>>> never need a debugger might be the reason why gdb is so badly
>>>> integrated with Gnat. That's a thought.
>>> gdb is used with Ada just not so often.
>> Right. But when it is used, it is sorely needed, since this then is
>> one of the conceptual bugs I mentioned.
>>
> Sorry, but I beg to disagree here. Conceptual bugs are found by
> reasonning on the source, not with a debugger. 

In development, yes. Not if they crop up after deployment. Then your
approach would be to re-reason the whole source. Not a viable
approach. Mine is, to track the test test case with a debugger of some
sort to some likely origin (let's say something like: This record
already comes corrupted from the database module) and then apply
reasoning. But the debugger comes rather handy for determeinining
where to look. 

The cocpetual bugs I'm talking about, are basically bugs like
violation of more complex post conditions that cannot be expressed in
the type system.

>Every now and then you
> may need to check the value of a variable at some point in execution
> to validate or invalidate an hypothesis, but even there, I find a
> proper trace message much faster and more precise than using a
> debugger.

Depends on the quality of the debugger. I prefer not to rebuild the
executable with tracing instrumentation if I got a nice debugger.

(And, BTW, sometimes inserting tracing instrumentation changes the
behaviour. That was so with my "Gnat doesn't handle controlled types
right on 'Read and 'Write in variant sections" bug, and it sucked
plenty.)

Regards -- Markus

Re: What is wrong with Ada?

[Chip Orange]

<gautier_niouzes@hotmail.com> wrote in message 
news:1176193942.294580.109900@e65g2000hsc.googlegroups.com...
> "Chip and Allie Orange":
>
>> The other reason I see is that it's not easily compatible with ActiveX, 
>> COM,
>> .net, and all the other interfacing standards that development add-ons 
>> are
>> sold for (in the Windows world).  It's advantages of taking less effort, 
>> in
>> the long term, to maintain a given project, are offset by having to "roll
>> your own" everything in the beginning.
>
> Did you look at GNATCOM ?
> It provides automated interfacing with COM for the GNAT Ada compiler.
>

I haven't given it the attention it deserves, but I did say "easily".  I 
also largely meant .net controls, since I was just handed those, on another 
project, as the only API a certain manufacturer was going to offer.

I'm not sure when GNATCOM was released as stable, and I'm not sure if it is 
compatible with ActiveX, but I'm guessing GNATCOM was released long after 
ActiveX was in use, and yes, I've also been handed several APIs from 
manufacturers, only available in ActiveX, some years ago, when on another 
project, and I needed to choose a programming environment to deal with them.

I'm not defending any of this, just pointing out how many IT shops are run, 
with their IT managers making the decisions on development environments 
using the criteria I've pointed out. :(

Chip

Re: What is wrong with Ada?

[Markus E Leypold]

"Chad  R. Meiners" <chad.rmeiners@gmail.com> writes:

> On Apr 10, 12:12 pm, Jean-Pierre Rosen <r...@adalog.fr> wrote:
>> Markus E Leypold a �crit :> Pascal Obry <pas...@obry.net> writes:
>>
>> >> Markus,
>>
>> >>>> Why do they like unreadable code?
>> >>>> Why do they like to play with a debugger ?
>> >>> Good question. That "real Ada software engineers" (like "real men")
>> >>> never need a debugger might be the reason why gdb is so badly
>> >>> integrated with Gnat. That's a thought.
>> >> gdb is used with Ada just not so often.
>>
>> > Right. But when it is used, it is sorely needed, since this then is
>> > one of the conceptual bugs I mentioned.
>>
>> Sorry, but I beg to disagree here. Conceptual bugs are found by
>> reasonning on the source, not with a debugger. Every now and then you
>> may need to check the value of a variable at some point in execution to
>> validate or invalidate an hypothesis, but even there, I find a proper
>> trace message much faster and more precise than using a debugger.
>> --
>> ---------------------------------------------------------
>>             J-P. Rosen (r...@adalog.fr)
>> Visit Adalog's web site athttp://www.adalog.fr
>
>
> I disagree. Sometimes trace messages add line noise and maintaince
> requirements to the code base, 

And in sad reality, exactly the tracing you need to find that special
bug, ist not in place at the given moment. Also the idea to instrument
for tracing every piece of source strikes me a s remarkably similar to
the philosophy of inserting checks for overflows and invalid pointers
over the whole source base: I thought that we had done away with stuff
of that kind -- "for every piece if source you should also ..." --
exactly by delegating that to tools: Either the compiler or a
debugger.

Which reminds me, that I wished that the compiler and the debugger
would work well enough together that I could just say: I now want a
trace (including parameters) of every call to modules M, M', ... and
would get it without too much fiddling. This is in my eyes what
debuggers are (should be) good for.

> and it is much easier to trace through
> the algorithm step by step (using conditional breaks when necessary).
> It is particularly handy to use a debugger when interfacing to other
> people's component libraries.  That being said, trace messages are
> usually very efficient too.

They are. But why do I have to insert them by hand instead of attach
them via a suitable source level debugger?

> cavat: I have found debuggers more useful in languages like C++ than
> Ada, but then again Visual Studios has an excellent debugger.

And the gnat-gdb is notoriously bad.

My experience generally is the same. Of course, I don't need a
debugger this often in other languages. The C debuggers are often
rather good (due to the close correspondence between generated machine
code and source), the Gnat gdb was nuisance and the ocaml debugger was
impressive (but i don't need it so often, since my development style
there is much more incremental -- continous testing and recompilation
comes much more natural in functional languages IMHO).

Regards -- Markus

Re: What is wrong with Ada?

[Ludovic Brenta]

Markus E Leypold writes:
> Which reminds me, that I wished that the compiler and the debugger
> would work well enough together that I could just say: I now want a
> trace (including parameters) of every call to modules M, M', ... and
> would get it without too much fiddling. This is in my eyes what
> debuggers are (should be) good for.

Look into DTraq: http://www.mckae.com/dtraq.html

Never used it myself, but it seems to be what you want.  Thank you,
ASIS, and thank you, McKae Technologies.

-- 
Ludovic Brenta.

Re: What is wrong with Ada?

[Randy Brukardt]

"Markus E Leypold"
<development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> wrote in
message news:tkejmsgtsq.fsf@hod.lan.m-e-leypold.de...
...
> Other bindings are completely platform specific (like CLAW) and
> proprietary. (Again that might not be a bad thing dependend on what
> you intend to do with it).

There is a subset of Claw available that is GMGPL licensed. But it is
certainly a Windows-only system at this time.

                             Randy.

Re: What is wrong with Ada?

[Simon Wright]

Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> Good question. That "real Ada software engineers" (like "real men")
> never need a debugger might be the reason why gdb is so badly
> integrated with Gnat. That's a thought.

gdb seems to me to be no worse integrated with GNAT than with other
languages. But then I'm working with supported tools ...

Re: What is wrong with Ada?

[Markus E Leypold]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> Markus E Leypold writes:
>> Which reminds me, that I wished that the compiler and the debugger
>> would work well enough together that I could just say: I now want a
>> trace (including parameters) of every call to modules M, M', ... and
>> would get it without too much fiddling. This is in my eyes what
>> debuggers are (should be) good for.
>
> Look into DTraq: http://www.mckae.com/dtraq.html
>
> Never used it myself, but it seems to be what you want.  Thank you,
> ASIS, and thank you, McKae Technologies.

Indeed that is very near. In practice it would suffice. But I meant
was actually different, i.e. that one doesn't need to change the
executable at all (DTraq only automates the instrumentation as I
understand it). The debugger has all means available to inspect the
application memory, the compiler could provide layout and type
information. That should suffice to "tap" even uninstrumented
executables automatically (but requires tighter integration with the
compiler).

Regards -- Markus

Re: What is wrong with Ada?

[Markus E Leypold]

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

> "Markus E Leypold"
> <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> wrote in
> message news:tkejmsgtsq.fsf@hod.lan.m-e-leypold.de...
> ...
>> Other bindings are completely platform specific (like CLAW) and
>> proprietary. (Again that might not be a bad thing dependend on what
>> you intend to do with it).
>
> There is a subset of Claw available that is GMGPL licensed. But it is
> certainly a Windows-only system at this time.

This IS nice to hear. 

Randy -- I should ask that in a personal mail, but since it is also of
interest at least to new comers in this group (and the Ada vendor FAQ
doesn't exist any more?):

Does Janus Ada run / work with Linux? I see a version for 386 Unix,
but that seems to be for Interactive, SCO and friends: Something I
haven't seen for some time any more. Is there a Linux version planned?

Regards -- Markus

Re: What is wrong with Ada?

[Markus E Leypold]

Simon Wright <simon.j.wright@mac.com> writes:

> Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
>
>> Good question. That "real Ada software engineers" (like "real men")
>> never need a debugger might be the reason why gdb is so badly
>> integrated with Gnat. That's a thought.
>

> gdb seems to me to be no worse integrated with GNAT than with other
> languages. 

At least with C it's much better integrated.

> But then I'm working with supported tools ...

That is no question of supported or unsupported, but of strange syntax
quirks, of tab-completion showing one syntax, but the command
acceptiong only the other, of strange and annoying questions (paging
me 50 instances of some init() function if I say break Init is
absolutely annoying).

As as far as "supported tools" go: The positions I meet here in
c.l.a. are a bit self contradicting (and actually different from what
I find elsewhere): "Yes there are even free tools", "No there are no
problems with Ada compilers", "If you can't afford $<big number> for
support from <major vendor> you're not professional enough". But: "Why
don't more people start to use Ada?" (Mind that includes hobbyists and
people relegated to hobbyist status because they aren't big business,
like myself).

So yes, free tools exist -- as long as don't have too much
expections. But no -- don't use the free tools if you do anything,
because problems are only and are already fixed in the supported
versions, and anyway if you're serious you have buy a supported
version.

(Only that all that sort of ground rules don't apply with other
languages from C++ to Java so I'm not surprised that some people have
a more relayed attitude towards those -- "let's try and feel them,
startusing them seriously if they feel nice and then buy support (or
simply experts :-), when we really need it").

Perhaps we shouldn't call Adacore GPL Gnat or FSF Gnat the free
version but refer to them consequently as the "cost free non serious
version, only for playing around by hobbyists". Of course then I don't
wonder that "nobody uses Ada", since it's only serious people anyway
(Software Engineers as opposed to the unwashed masses of coders) that
use Ada.

OK -- it was perhaps not you who earned that diatribe (so please feel
free to ignore it) but somebody or somebodies here certainly have.

Regards -- Markus

Re: What is wrong with Ada?

[Georg Bauhaus]

On Tue, 2007-04-10 at 16:32 +0200, Markus E Leypold wrote:
> Pascal Obry <pascal@obry.net> writes:

> > Another way to put it, let me ask : What's wrong with
> > developers ? Why do they like unsafe languages ? 
> I think I already answered that.

> > Why do they like fighting a language all the time?
> Well -- difficult to say:...

> > Why do they like unreadable code?
> > Why do they like to play with a debugger ? 
> 
> Good question....

> THIS post is
> absolute nonsense and not worthy to yourself.

Erh, `already answered', `difficult to say', `good question'
and then `post is nonsense'??? Seems like another opportunity
of addressing a few important observations of an alleged 
programmer sample has been missed.

Suppose I try to frame Pascal's questions with notions of programming
extracted from the Windows/VB/Excel/ASP world, or from the
PHP/Perl/apache world and mix them with the (stereo-)typical
Ada or C++ surroundings, what will I be comparing?

A good starting point might be to see what programming in a
(stereo-)typical shop means. A construed tentative grouping
is
- "scripting shops" (Perl, PHP, Python, ASP, ...)
- "forms shops" (VB, Delphi, C#, ...)
- "accounting shops" (Cobol, APL, Java, ...)
- "observation shops" (C, Fortran, Ada, ...)
- "media shops" (don't know :-/ ...)
and
- "vehicle and missile control shops" (C, C++, Ada, ...)

And if we compare the mean programmer skill in the respective
shops listed above, can we reasonably expect to find means
that differ significantly? Or can we at least expect to find
per-shop-quantiles that show some structure in the distribution of
skill that is different in each shop type?

I can follow Pascal's questions as an expression of a valid observation,
maybe even an observation with sufficient statistical reliability. On
rare occasions of reading some computing history literature, I find that
younger programmers like clever solutions more than programmers who have
grown older.  Ada culture puts cleverness at a different level of
abstraction, other kinds of harmful low level cleverness are delegated
to the C culture. Knowing clever {}-culture solutions still saves you
the trouble of adding business critical obfuscation.

Re: What is wrong with Ada?

[Markus E Leypold]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> On Tue, 2007-04-10 at 16:32 +0200, Markus E Leypold wrote:
>> Pascal Obry <pascal@obry.net> writes:
>
>> > Another way to put it, let me ask : What's wrong with
>> > developers ? Why do they like unsafe languages ? 
>> I think I already answered that.
>
>> > Why do they like fighting a language all the time?
>> Well -- difficult to say:...
>
>> > Why do they like unreadable code?
>> > Why do they like to play with a debugger ? 
>> 
>> Good question....
>
>> THIS post is
>> absolute nonsense and not worthy to yourself.
>
> Erh, `already answered', `difficult to say', `good question'
> and then `post is nonsense'??? 

Well, creative quoting get's you (almost) anywhere. 

> Seems like another opportunity
> of addressing a few important observations of an alleged 
> programmer sample has been missed.
>
> Suppose I try to frame Pascal's questions with notions of programming
> extracted from the Windows/VB/Excel/ASP world, or from the
> PHP/Perl/apache world and mix them with the (stereo-)typical
> Ada or C++ surroundings, what will I be comparing?
>
> A good starting point might be to see what programming in a
> (stereo-)typical shop means. A construed tentative grouping
> is
> - "scripting shops" (Perl, PHP, Python, ASP, ...)
> - "forms shops" (VB, Delphi, C#, ...)
> - "accounting shops" (Cobol, APL, Java, ...)
> - "observation shops" (C, Fortran, Ada, ...)
> - "media shops" (don't know :-/ ...)
> and
> - "vehicle and missile control shops" (C, C++, Ada, ...)
>
> And if we compare the mean programmer skill in the respective
> shops listed above, can we reasonably expect to find means
> that differ significantly? Or can we at least expect to find
> per-shop-quantiles that show some structure in the distribution of
> skill that is different in each shop type?
>
> I can follow Pascal's questions as an expression of a valid observation,
> maybe even an observation with sufficient statistical reliability. On
> rare occasions of reading some computing history literature, I find that
> younger programmers like clever solutions more than programmers who have
> grown older.  Ada culture puts cleverness at a different level of
> abstraction, other kinds of harmful low level cleverness are delegated
> to the C culture. Knowing clever {}-culture solutions still saves you
> the trouble of adding business critical obfuscation.

And your point is? 

George -- As much as I like a good flame war or an intelligent
conversation (there is even a certain amount of overlap) -- this time
I'll not fall for your attempt :-).

I think, that c.l.a. is probably the wrong place to start any
insightful study into QA or programming culture which should be based
on at least some data. You talk as if there is just some data around
te corner ("differ significantly", "per-shop-quantiles", "distribution
of skill", "shop type"), but it's all a lot of handwaving at the end
of the day ("can we reasonably expect", "I can follow ... expression
of a valid observation") and we end up with "culture" arguments which
a malleable without end almost by definition. 

What you sketch encompasses multiple (perhaps rather interesting)
studies, which might also end totally inconclusive. But there is not
even a solid methodology yet how to conclude such studies (and no, I
don't think McKinsey, Anderson or any university has such methodology
in THIS area, since empirical studies in software engineering are
quite rare and still in their infancy -- if you compare SE with
psychology (empirical studies on not so hard subjects) or natural
science (empirical studies on lots of hard subjects). 

You are welcome to try to conduct those studies (and if you need
infrastructure or some organizational umbrella I'll gladly help out,
either to find or to found one :-). But mind, a brainstrom does not a
study make. Nor do anecdotes on c.l.a.

Regards -- Markus

Re: What is wrong with Ada?

[Brian May]

>>>>> "Pascal" == Pascal Obry <pascal@obry.net> writes:

    Pascal> Why do they like fighting a language all the time 

People I have talked to avoid Ada because of the perception (real or
otherwise) that you have to fight the language all the time, and there
is only one way of doing things[1].

Not that I agree with this reasoning.

Notes:

[1] Unlike in, say Perl, where there are many ways of stating exactly
the same thing.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: What is wrong with Ada?

[Georg Bauhaus]

On Wed, 2007-04-11 at 00:15 +0200, Markus E Leypold wrote:
> > I can follow Pascal's questions as an expression of a valid observation,
> > maybe even an observation with sufficient statistical reliability.
> 
> And your point is? 

With all due respect, my points.


> George -- As much as I like a good flame war or an intelligent
> conversation (there is even a certain amount of overlap) -- this time
> I'll not fall for your attempt :-).

I'm only trying to put what I think could be substance to your
arguments which I think can be turned into meaningful, comparable
observations.

>  You talk as if there is just some data around
> te corner.

There are data, if "tentative" is the right qualification for criteria
used in comparing SE (idiomatic Ada, superhuman diligence C, etc.)
to frowned upon coding.

> we end up with "culture" arguments which
> a malleable without end almost by definition. 

Not by the definitions I know.
Watch "anger" (because of Ada), "work", "most of the time",
and "better" in these quotes:

"Anger induced by compilers refusing to compile sources", and
"The code then worked most of the time", and
"In the end, the programmers said that this new-to-them approach
worked  better (for the coding result)."

AFAIK, this isn't a singular observation when switching from a
"permissive language" to a "grumbling language" like Ada.
Anger, for sure, is not a compiler thing, and has been measured
before. Etc..

>  if you compare SE with
> psychology (empirical studies on not so hard subjects) or natural
> science (empirical studies on lots of hard subjects). 

Hard subjects like fluid dynamics or breaking distance prediction?
I could add another question to Pascal's list on scientific pride
in this regard. OTOH, no reason to stop trying to find what it is
that makes a base type system like that of Ada empirically superior
where  superiority is measured as in the recent report on comparing
embedded systems classes using C to those using Ada, other things
being equal. Using an Ada mode of expression appears to entail
better results sooner and more frequently. (Even if other languages
have this mode of expression, too, the observation means something!)

Going from

  type Percent is digits 7 range 0.0 .. 100.0;
    -- ...


  P: Percent;

to

  <nothing>


  float p;  /* ... */

doesn't imply different executable programs. But it does
imply a different mode of expression that is not necessitated
by the properties of the respective programming languages.
(I could have written P: Float; in the first example, and could have
introduced a type alias in the second at least.)
Given a frequency distribution of these styles, we might conclude
there is a culture thing (because modes of expression imply different
non-technical backgrounds) or not.
 Source code is available on-line, and near your workplace.

Re: What is wrong with Ada?

[Jean-Pierre Rosen]

Chad R. Meiners a �crit :
> I disagree. Sometimes trace messages add line noise and maintaince
> requirements to the code base, 
Huh?
Trace messages are put just to check an hypothesis, and removed 
immediately afterwards. Certainly not kept in configuration, and limited 
to a couple of lines!

> and it is much easier to trace through
> the algorithm step by step (using conditional breaks when necessary).
My experience is that recompiling (generally a single body where you 
added the trace) is much faster than starting the debugger, setting 
breakpoints, skipping lots of unnecessary breaks, and so on.

Moreover, a trace message gives you exactly the information you need, 
while interpreting a particular (complicated) structure from a debugger 
is generally quite difficult. Did you ever try to understand an ASIS 
"Element" ?

Caveat: I always provide a special trace function in my programs for 
this purpose.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: What is wrong with Ada?

[Georg Bauhaus]

On Wed, 2007-04-11 at 11:40 +0200, Jean-Pierre Rosen wrote:

> > and it is much easier to trace through
> > the algorithm step by step (using conditional breaks when necessary).

Having a trace of the steps helps (my) understanding, though.

> My experience is that recompiling (generally a single body where you 
> added the trace) is much faster than starting the debugger, setting 
> breakpoints, skipping lots of unnecessary breaks, and so on.

Depending on the debugger, conditional breaks etc etc can be
packaged as a debugger procedure, and the program reloaded
without restarting the debugger. Ok, this doesn't count for
one time tests.

Re: What is wrong with Ada?

[Jason King]

I'm an MIS guy not a CS guy and this is my take.
If I have a business task to accomplish I'm looking for the tool or set 
of tools that will get my task accomplished quickly and the solution be 
maintainable.
We don't use c/c++ at our shop because its difficult to get the task 
accomplished quickly so we look to other tools.  As we survey the 
landscape we see vb, delphi, ada, java etc.
Initially ada looks very attractive because we're an Oracle shop and 
pl/sql (the stored procedure/trigger language inside the Oracle db) is 
based on ada-83.  Then we look for database access, tools to build 
client guis and tools to build web applications.  The tools available 
are substantially inferior in number and outside documentation to the 
ones available for java.  Then the bosses look around to see how hard it 
is to hire new people for the shop as our client list expands.  There 
aren't a whole bunch of ada developers out there but there are schools 
on several continents churning out armies of java developers.   Maybe 
the one ada developer is more productive than 1.5 or even two java 
developers but when we have to overcome the lack of tools + the lack of 
developers that makes us look other places.
In a world where we could search Amazon and find as many ada books as 
java books or get as many cvs with ada experience as java experience 
then ada would be an obvious choice.  In the world as it exists the 
availability of support materials and experienced developers outweighs 
the technical merits of ada.
martinbishop wrote:
> I've never been scared of "non mainstream" languages, but I was
> wondering, what is wrong with Ada?  Why don't more people use it?
> What
> do most people think of it?  To me, it seems like a nice, concise, and
> safe language, but I haven't used it yet.
> 

Re: What is wrong with Ada?

[tmoran]

>aren't a whole bunch of ada developers out there but there are schools
>on several continents churning out armies of java developers.
   In the early days of the California gold rush, miners lived in tents
because lots of people were able to put up tents in a hurry.  Later they
realized that, though quick, tents aren't as robust against the elements
as houses, and the miners who made money built houses, even when they had
to hire some skilled craftsmen to do it.

Re: What is wrong with Ada?

[kevin cline]

On Apr 10, 11:31 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Tue, 10 Apr 2007 15:59:27 GMT, Jeffrey R. Carter wrote:
> > Pascal Obry wrote:
> >> Jeffrey R. Carter a écrit :
>
> >>> Nothing is wrong with Ada. It is a language for SW engineers. Since 98%
> >>> of SW developers are coders, not SW engineers, 98% prefer languages for
> >>> coders.
>
> >> Agreed 100%. Another way to put it, let me ask : What's wrong with
> >> developers ? Why do they like unsafe languages ? Why do they like
> >> fighting a language all the time ? Why do they like unreadable code ?
> >> Why do they like to play with a debugger ? Why do they like to play
> >> Sherlock Holmes during hours to look for a bug ? Here are the real
> >> questions to me, again nothing wrong with Ada to me !
>
> > The answer is: because they're coders, not SW engineers.
>
> > Let's get circular.
>
> Let me break the circle:
>
> It is because SW engineering is not engineering.

You are right about that.  Other engineering disciplines apply
physical laws to the construction of human artifacts.  There are no
physical laws governing software.  Were it not for the limitations of
human intellect, we could instantaneously produce correct, optimal
machine code to meet any need.  Software engineering attempts to
define practices for developing reliable software given our limited
abilities.  It is a social science.

Re: What is wrong with Ada?

[Brian May]

>>>>> "Jean-Pierre" == Jean-Pierre Rosen <rosen@adalog.fr> writes:

    Jean-Pierre> My experience is that recompiling (generally a single
    Jean-Pierre> body where you added the trace) is much faster than
    Jean-Pierre> starting the debugger, setting breakpoints, skipping
    Jean-Pierre> lots of unnecessary breaks, and so on.

Assuming you notice that a bug exists. This is a big problem I have
had especially with most interpreted languages. The only way you can
be sure the code is bug free is too regularly test every possible
path, including different error conditions. Otherwise you find that
after a minor but unexpected error condition your previously working
code calls display__error() instead of display_error() and it becomes
a fatal function-not-found error (even if you swear: I didn't change
that line!).
-- 
Brian May <bam@snoopy.apana.org.au>

Re: What is wrong with Ada?

[Randy Brukardt]

"Markus E Leypold"
<development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> wrote in
message news:tairc4km9k.fsf@hod.lan.m-e-leypold.de...
...
> Randy -- I should ask that in a personal mail, but since it is also of
> interest at least to new comers in this group (and the Ada vendor FAQ
> doesn't exist any more?):
>
> Does Janus Ada run / work with Linux? I see a version for 386 Unix,
> but that seems to be for Interactive, SCO and friends: Something I
> haven't seen for some time any more. Is there a Linux version planned?

We don't have a Linux version at this time. My guess is that it wouldn't be
particularly difficult to port the old Unix version, but at lot of things
that seem "not too hard" have a way of taking a lot more time than expected.
It's on the roadmap but isn't scheduled for now. (Demand could change that,
of course.)

                               Randy.

Re: What is wrong with Ada?

[Jean-Pierre Rosen]

Brian May a �crit :
> Assuming you notice that a bug exists. This is a big problem I have
> had especially with most interpreted languages. The only way you can
> be sure the code is bug free is too regularly test every possible
> path, including different error conditions. Otherwise you find that
> after a minor but unexpected error condition your previously working
> code calls display__error() instead of display_error() and it becomes
> a fatal function-not-found error (even if you swear: I didn't change
> that line!).
Hmm... We are talking Ada here. Double underscores are not allowed 
(precisely to avoid that kind of issue), and it is impossible to build 
an incomplete program!

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: What is wrong with Ada?

[Dmitry A. Kazakov]

On 11 Apr 2007 16:05:30 -0700, kevin  cline wrote:

> On Apr 10, 11:31 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Tue, 10 Apr 2007 15:59:27 GMT, Jeffrey R. Carter wrote:
>>> Pascal Obry wrote:
>>>> Jeffrey R. Carter a �crit :
>>
>>>>> Nothing is wrong with Ada. It is a language for SW engineers. Since 98%
>>>>> of SW developers are coders, not SW engineers, 98% prefer languages for
>>>>> coders.
>>
>>>> Agreed 100%. Another way to put it, let me ask : What's wrong with
>>>> developers ? Why do they like unsafe languages ? Why do they like
>>>> fighting a language all the time ? Why do they like unreadable code ?
>>>> Why do they like to play with a debugger ? Why do they like to play
>>>> Sherlock Holmes during hours to look for a bug ? Here are the real
>>>> questions to me, again nothing wrong with Ada to me !
>>
>>> The answer is: because they're coders, not SW engineers.
>>
>>> Let's get circular.
>>
>> Let me break the circle:
>>
>> It is because SW engineering is not engineering.
> 
> You are right about that.  Other engineering disciplines apply
> physical laws to the construction of human artifacts.

They apply science. Engineering is about applying a science for solving
practical problems.

> There are no physical laws governing software.

I don't think that physical vs. spiritual plays any essential role. What
does, is the quality of the science being applied. One just cannot have
solid engineering based on CS. It is a question of maturity. A science
matures in hundreds of years. It would be silly to expect that we could
have SW engineering after just 50 years.

> Were it not for the limitations of
> human intellect, we could instantaneously produce correct, optimal
> machine code to meet any need.  Software engineering attempts to
> define practices for developing reliable software given our limited
> abilities.  It is a social science.

Yes. SW developing works much like an artistic activity or like a
scientific research or like both. It is not because people like it, however
many including myself do. It because there is no other choice (like
construction).

This in turn determines the [irresponsible] attitude of developers, their
[strange] preferences, the ways projects are [mis]managed and finally the
[awful] languages being used... (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Ada vendor FAQ (was: What is wrong with Ada?)

[Ludovic Brenta]

Markus E Leypold writes:
> (and the Ada vendor FAQ doesn't exist any more?):

If that is the case, then I suggest that the list of compilers in the
Ada Programming wikibook at [1] should be the FAQ. There is also a
chapter [2] for libraries. I would encourage Ada tool vendors to list
their products there (short descriptions with links appreciated, full-
page ads will probably get trimmed down).

[1] http://en.wikibooks.org/wiki/Ada_Programming/Installing
[2] http://en.wikibooks.org/wiki/Ada_Programming/Libraries

--
Ludovic Brenta.

Re: What is wrong with Ada?

[Peter C. Chapin]

"kevin  cline" <kevin.cline@gmail.com> wrote in
news:1176332730.826176.286450@y5g2000hsa.googlegroups.com: 

> You are right about that.  Other engineering disciplines apply
> physical laws to the construction of human artifacts.  There are no
> physical laws governing software.

I'm not sure that's entirely true. For example, it appears that some 
solvable problems are fundamentally intractable (the NP complete problems), 
and others are provably unsolvable in the general case (the undecidable 
problems). There is some kind of structure to computational problems and we 
didn't invent that structure. It is a fact of nature. Software engineers 
have to deal with these inherent properties of the universe to build 
software that solves real world problems. It sounds similar to "ordinary" 
engineering to me.

Peter

Re: What is wrong with Ada?

[Markus E Leypold]

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

> "Markus E Leypold"
> <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> wrote in
> message news:tairc4km9k.fsf@hod.lan.m-e-leypold.de...
> ...
>> Randy -- I should ask that in a personal mail, but since it is also of
>> interest at least to new comers in this group (and the Ada vendor FAQ
>> doesn't exist any more?):
>>
>> Does Janus Ada run / work with Linux? I see a version for 386 Unix,
>> but that seems to be for Interactive, SCO and friends: Something I
>> haven't seen for some time any more. Is there a Linux version planned?
>
> We don't have a Linux version at this time. My guess is that it wouldn't be
> particularly difficult to port the old Unix version, but at lot of things
> that seem "not too hard" have a way of taking a lot more time than expected.

That effect I know. :-).

> It's on the roadmap but isn't scheduled for now. 

Good to hear (but not see me as a merket at the moment).

> (Demand could change that, of course.)

Of course demand only grows when there is a product offering ;-).

Re: What is wrong with Ada?

[Markus E Leypold]

"Peter C. Chapin" <pchapin@sover.net> writes:

> "kevin  cline" <kevin.cline@gmail.com> wrote in
> news:1176332730.826176.286450@y5g2000hsa.googlegroups.com: 
>
>> You are right about that.  Other engineering disciplines apply
>> physical laws to the construction of human artifacts.  There are no
>> physical laws governing software.
>
> I'm not sure that's entirely true. For example, it appears that some 
> solvable problems are fundamentally intractable (the NP complete problems), 
> and others are provably unsolvable in the general case (the undecidable 
> problems). There is some kind of structure to computational problems and we 
> didn't invent that structure. It is a fact of nature. Software engineers 
> have to deal with these inherent properties of the universe to build 
> software that solves real world problems. It sounds similar to "ordinary" 
> engineering to me.

Also "ordinary engineering" does more than just apply phyisical
laws. I.e. there is the whole issue of stabdardization and how to use
standards properly. Project management also is -- more or less -- a
part of engineering.

Regards -- Markus

Re: What is wrong with Ada?

[Bob Spooner]

"Brian May" <bam@snoopy.apana.org.au> wrote in message 
news:sa4irc33idm.fsf@margay.local...
>>>>>> "Pascal" == Pascal Obry <pascal@obry.net> writes:
>
>    Pascal> Why do they like fighting a language all the time
>
> People I have talked to avoid Ada because of the perception (real or
> otherwise) that you have to fight the language all the time, and there
> is only one way of doing things[1].
>
> Not that I agree with this reasoning.
>
> Notes:
>
> [1] Unlike in, say Perl, where there are many ways of stating exactly
> the same thing.

When I find myself fighting the language, it usually means that I need to 
revisit my design.
-- Bob 

Re: What is wrong with Ada?

[kevin cline]

On Apr 11, 6:45 pm, Brian May <b...@snoopy.apana.org.au> wrote:
> >>>>> "Jean-Pierre" == Jean-Pierre Rosen <r...@adalog.fr> writes:
>
>     Jean-Pierre> My experience is that recompiling (generally a single
>     Jean-Pierre> body where you added the trace) is much faster than
>     Jean-Pierre> starting the debugger, setting breakpoints, skipping
>     Jean-Pierre> lots of unnecessary breaks, and so on.
>
> Assuming you notice that a bug exists. This is a big problem I have
> had especially with most interpreted languages. The only way you can
> be sure the code is bug free is too regularly test every possible
> path, including different error conditions.

This is also true of compiled languages.  The compiler can not detect
all errors, so you still have to test every possible path, including
different error conditions.

> Otherwise you find that
> after a minor but unexpected error condition your previously working
> code calls display__error() instead of display_error() and it becomes
> a fatal function-not-found error (even if you swear: I didn't change
> that line!).

Or you could discover that after an unexpected condition the resulting
exception is not caught, and the program exits instead of
recovering.

> --
> Brian May <b...@snoopy.apana.org.au>

Re: What is wrong with Ada?

[kevin cline]

On Apr 11, 6:45 pm, Brian May <b...@snoopy.apana.org.au> wrote:
> >>>>> "Jean-Pierre" == Jean-Pierre Rosen <r...@adalog.fr> writes:
>
>     Jean-Pierre> My experience is that recompiling (generally a single
>     Jean-Pierre> body where you added the trace) is much faster than
>     Jean-Pierre> starting the debugger, setting breakpoints, skipping
>     Jean-Pierre> lots of unnecessary breaks, and so on.
>
> Assuming you notice that a bug exists. This is a big problem I have
> had especially with most interpreted languages. The only way you can
> be sure the code is bug free is too regularly test every possible
> path, including different error conditions....

Are you claiming that use of Ada makes it safe to release code that
has never been tested?

Re: What is wrong with Ada?

[Pascal Obry]

kevin cline a �crit :

> This is also true of compiled languages.  The compiler can not detect
> all errors, so you still have to test every possible path, including
> different error conditions.

Of course not all but lot more than for interpreted languages as in this
is case it is 0%.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: What is wrong with Ada?

[Pascal Obry]

kevin cline a �crit :
> On Apr 11, 6:45 pm, Brian May <b...@snoopy.apana.org.au> wrote:
>>>>>>> "Jean-Pierre" == Jean-Pierre Rosen <r...@adalog.fr> writes:
>>     Jean-Pierre> My experience is that recompiling (generally a single
>>     Jean-Pierre> body where you added the trace) is much faster than
>>     Jean-Pierre> starting the debugger, setting breakpoints, skipping
>>     Jean-Pierre> lots of unnecessary breaks, and so on.
>>
>> Assuming you notice that a bug exists. This is a big problem I have
>> had especially with most interpreted languages. The only way you can
>> be sure the code is bug free is too regularly test every possible
>> path, including different error conditions....
> 
> Are you claiming that use of Ada makes it safe to release code that
> has never been tested?

Are you reading properly ?

"The only way" for interpreted languages, for compiled languages (as
said in my previous message) the compiler will detect lot of mistakes.
So it is not the only way in this case. I'm wondering if you are not
moving to the troll side!

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: What is wrong with Ada?

[Markus E Leypold]

"kevin  cline" <kevin.cline@gmail.com> writes:

> On Apr 11, 6:45 pm, Brian May <b...@snoopy.apana.org.au> wrote:
>> >>>>> "Jean-Pierre" == Jean-Pierre Rosen <r...@adalog.fr> writes:
>>
>>     Jean-Pierre> My experience is that recompiling (generally a single
>>     Jean-Pierre> body where you added the trace) is much faster than
>>     Jean-Pierre> starting the debugger, setting breakpoints, skipping
>>     Jean-Pierre> lots of unnecessary breaks, and so on.
>>
>> Assuming you notice that a bug exists. This is a big problem I have
>> had especially with most interpreted languages. The only way you can
>> be sure the code is bug free is too regularly test every possible
>> path, including different error conditions....
>
> Are you claiming that use of Ada makes it safe to release code that
> has never been tested?

Actually -- why not? In my experience spuriously tested Ada code
usually has the quality of extensively tested C code. Perhaps my cases
where not really comparable, but it is astonishing how much Ada code
is "just right" if it compiles.

Of course we're not talking about embedded programs / control systems
of whatever kind here. And those should probably better verified
and/or extenseively formally reviewd instead of only tested.

Remember: Formal review is a (proven) much better QA tool than
testing.

Regards -- Markus

Re: What is wrong with Ada?

[Robert A Duff]

Brian May <bam@snoopy.apana.org.au> writes:

>...The only way you can
> be sure the code is bug free is too regularly test every possible
> path, ...

Well, yeah, static checking is helpful, but I think you overstate the
case:

There is no way to be sure the code is bug free!  Not in any language.
Not using testing, nor any other method (including so-called
proof of correctness).

Testing every possible path is not enough.  Here's a function that
detects prime numbers (except that it has a bug):

    function Is_Prime (X: Integer) return Boolean is
        -- Returns True if and only if X is prime.
    begin
        if X = 2 then
            return True;
        else
            return False;
        end if;
    end Is_Prime;

If I test with inputs 2 and 4, it gives the right answer for both,
and I have covered all paths.  But I have failed to detect the bug.

And it is impossible to cover all paths in a program containing
unbounded loops or recursion, because there are an infinite number of
them.

- Bob

Re: What is wrong with Ada?

[Alexander E. Kopilovich]

Jason King wrote:
>I'm an MIS guy not a CS guy and this is my take.

Well if you are from there then it is easy to asnwer - because it is current
reality, which matters in MIS, and not high princples and/or sophisticated
tastes.

> As we survey the landscape we see vb, delphi, ada, java etc.

So your enviroment is Windows - as you considered VB and Delphi.

>Initially ada looks very attractive because we're an Oracle shop and 
>pl/sql (the stored procedure/trigger language inside the Oracle db) is 
>based on ada-83.  Then we look for database access, tools to build 
>client guis and tools to build web applications.  The tools available 
>are substantially inferior in number and outside documentation to the 
>ones available for java.

Well, not only to the Java, but even more so to VB and Delphi.

But why do you think that GUI layer should be programmed using the same
language that middleware? You can (and perhaps should) separate your GUI
stuff from the core of you application - and this GUI layer can be perfectly
developed using VB or Delphi and then made available to the core in the form
of DLL or ActiveX or .NET controls. (Altough if you choose Java for GUI layer
you'll probably have much more trouble with that separation.)

>  Then the bosses look around to see how hard it 
>is to hire new people for the shop as our client list expands.  There 
>aren't a whole bunch of ada developers out there but there are schools 
>on several continents churning out armies of java developers.

Well, if you need armies of developers then surely you must choose Java.
But do you really want those armies? Perhaps just 2-3, well, at the edge of
imagination, 5 developers would suffice, even if your client list explodes.
And there will be no trouble to find so few developers with reasonable 
knowledge of Ada (especially if your business is so successfull and rapidly
expanding).

>In a world where we could search Amazon and find as many ada books as 
>java books or get as many cvs with ada experience as java experience 
>then ada would be an obvious choice.

Well, you can search Amazon and find there very few Ada books (which aren't
outdated). But you need not more, because those are proper books, and they
describe Ada quite well. 

Actually I do not think there is (and even could be) any books of comparable
quality and language coverage for Java.

>  In the world as it exists the 
>availability of support materials and experienced developers outweighs 
>the technical merits of ada.

The word "support" is crucial here. Ada is exactly support-oriented language.
But "support" for Ada means regular professional support, and not a kind of
random support from the elements in and around the industry.

Therefore, if you can afford such regular professional support (for example,
like that provided by AdaCore for users of their GNAT Professional compiler)
then you can use Ada for you business applications quite succesfully. But if
not, then, well, perhaps you better do not try to use Ada in you business
applications unless your developers are great Ada enthusiasts.

Re: What is wrong with Ada?

[Dmitry A. Kazakov]

On Thu, 12 Apr 2007 14:47:19 -0400, Robert A Duff wrote:

> Brian May <bam@snoopy.apana.org.au> writes:
> 
>>...The only way you can
>> be sure the code is bug free is too regularly test every possible
>> path, ...
> 
> Well, yeah, static checking is helpful, but I think you overstate the
> case:
> 
> There is no way to be sure the code is bug free!  Not in any language.
> Not using testing, nor any other method (including so-called
> proof of correctness).
> 
> Testing every possible path is not enough.  Here's a function that
> detects prime numbers (except that it has a bug):
> 
>     function Is_Prime (X: Integer) return Boolean is
>         -- Returns True if and only if X is prime.
>     begin
>         if X = 2 then
>             return True;
>         else
>             return False;
>         end if;
>     end Is_Prime;
> 
> If I test with inputs 2 and 4, it gives the right answer for both,
> and I have covered all paths.  But I have failed to detect the bug.

Tests should cover all program states. Covering all paths is a rough
approximation of.

> And it is impossible to cover all paths in a program containing
> unbounded loops or recursion, because there are an infinite number of
> them.

But the number of program states is finite, or else the program is wrong
anyway? However the inputs and outputs of a program can be infinite,
uncountable, like hardware random generators or clocks.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: What is wrong with Ada?

[Peter C. Chapin]

> But the number of program states is finite, or else the program is wrong
> anyway?

In a Turing complete programming language it is possible to write programs 
with unbounded amount of state. Indeed... this is the essence of Turing 
completeness.

P.S. If I understand SPARK properly, the SPARK subset of Ada is not Turning 
complete because for any given program there is a bound on how much state 
information the program might use. As a result the halting problem is 
decidable for SPARK programs. This is a consequence of the lack of dynamic 
allocation and recursion. Of course useful programs can still be written 
with SPARK despite its theoretical incompleteness. I imagine that making 
SPARK less powerful than a Turing machine is the whole point of the 
restrictions it imposes. Turing machines are hard to analyze.

Peter

Re: What is wrong with Ada?

[Dmitry A. Kazakov]

On 12 Apr 2007 19:54:05 GMT, Peter C. Chapin wrote:

>> But the number of program states is finite, or else the program is wrong
>> anyway?
> 
> In a Turing complete programming language it is possible to write programs 
> with unbounded amount of state. Indeed... this is the essence of Turing 
> completeness.
> 
> P.S. If I understand SPARK properly, the SPARK subset of Ada is not Turning 
> complete because for any given program there is a bound on how much state 
> information the program might use. As a result the halting problem is 
> decidable for SPARK programs. This is a consequence of the lack of dynamic 
> allocation and recursion. Of course useful programs can still be written 
> with SPARK despite its theoretical incompleteness. I imagine that making 
> SPARK less powerful than a Turing machine is the whole point of the 
> restrictions it imposes. Turing machines are hard to analyze.

Yes, one should give up some power for security.

This is why one should be suspicious to the arguments: "look how powerful
is the language feature X!"

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: What is wrong with Ada?

[Georg Bauhaus]

On Thu, 2007-04-12 at 14:47 -0400, Robert A Duff wrote:

> And it is impossible to cover all paths in a program containing
> unbounded loops or recursion, because there are an infinite number of
> them.

Just out of curiosity: If I have a suitable annotated program,
is there a tool that can give a good estimate on the number of
steps along a selection of paths that indicates the program
is running in circles? (Not that I expect to be still alive when
the test has finished... :-)

Re: What is wrong with Ada?

[Brian May]

>>>>> "Robert" == Robert A Duff <Robert> writes:

    Robert> There is no way to be sure the code is bug free!  Not in
    Robert> any language.  Not using testing, nor any other method
    Robert> (including so-called proof of correctness).

The problem I have had in the past is code along the lines of:

rc = do_step_1(...);
if (!rc) {
   report_error("step 1 failed");
   return FALSE;
}

rc = do_step_2(...);
if (!rc) {
   report_error("step 2 failed");
   return FALSE;
}

rc = do_step_3(...);
if (!rc) {
   report_error("step 3 failed");
   return FALSE;
}

rc = do_step_4(...);
if (!rc) {
   report_error("step 4 failed");
   return FALSE;
}

...

(Yes, exceptions would also help to a limited extent; this code was
PHP4 which didn't support exceptions).

Running automatic tests might not be possible. For example, if the
steps involve creating a TCP connection. Maybe you could deliberately
bring the network down before running the test, but this may produce
the error in step 1 (this could be looking resolving a DNS name), not
step 2 (establishing the connection), step 3 (sending data), or step 4
(receiving expected response).

As a result, the code is properly tested, using manual techniques. The
first time.

Eventually, over time the code evolves. Maybe somebody does a search
and replace for /error/message/ and accidently changes one of those
report_error to report_message in the process, without noticing it. Or
maybe somebody decides that report_error needs another parameter, but
forgets to change the references in this file.

The result is that previously good code suddenly becomes bad with no
warning, it appears to work fine, and as far as I can tell it would be
difficult to test unless you have a compiler that will these issues
up.

All the cases I have had and can remember where good code becomes bad
like this are issues that any compiler could pick up on easily.

(another technique I use is to use a revision control system, and
review the changes I have made before committing them - this isn't
guaranteed but sometimes I do pick up changes I didn't intend to
commit).
-- 
Brian May <bam@snoopy.apana.org.au>

Re: What is wrong with Ada?

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Tests should cover all program states. Covering all paths is a rough
> approximation of.

> But the number of program states is finite, or else the program is wrong
> anyway? 

Don't understand that. Assuming the program terminates fo a give input
I the number of states it goes through during execution -- S_1 ... S_n
-- is finite. The number of valid input sets is usually less well
defined, but assuming (and this is wrong) they are finite, i.e. the
sets I \from I_1, I_2 ... I_n are the only valid input then you still
have a finite number of program states. Still the number of possible
inputs might be rather large (i.e. to a type setter it's all possible
books :-), so exhaustive testing is impossible (and your "Tests should
cover all program states" is just saying, that you can't test enough).

But the set of all inputs is not necessarily finite -- i.e. in the
case that the user might enter one data item after the other and get
some answer about that item until he enters a end-of-input symbol
(stupid example: an interactive prime tester). Since it is nonsense to
artificially restrict the length of the user interaction just to get a
finite set of input sequences, we will have to live with a infinite
number of potential inputs to the program. So the paths covered are
also inifinite (program state is still finite since the machine has
only finite state).

Regards -- Markus

Re: What is wrong with Ada?

[Brian May]

>>>>> "Bob" == Bob Spooner <rls19@psu.edu> writes:

    Bob> When I find myself fighting the language, it usually means
    Bob> that I need to revisit my design.

True.

Unfortunately many people prefer to blame the language :-(.

This happens a lot, for example see:

http://worsethanfailure.com/Articles/Tool_Blame.aspx
http://worsethanfailure.com/Articles/The_End_of_the_String_as_We_Know_It.aspx
-- 
Brian May <bam@snoopy.apana.org.au>

Re: What is wrong with Ada?

[Jason King]

Folks, this exchange has something to do with the lack of popularity for 
Ada.  Basically I've just been told I don't ask the right questions, I 
don't understand the development process, my concerns are irrelevant to 
proper software development and that the average Ada developer is so 
much better than any other sort of developer that any project can be 
completed with 2 or 3 of them.
I _like_ Ada.  If I didn't have to reinvent so many wheels I'd use it.
Another post has a link to available libraries and maybe I'll see some 
things that help me do that.
Don't sneer at MIS guys.  Lots of us use and swear by Oracle and as I 
said in my first post pl/sql is pretty much a subset of Ada 83.  You 
should build on that.  I keep coming back to Ada because I don't like 
the conceptual impedance of some pieces in an Ada-like language and 
other pieces in a C-like language. Work with us pl/sql people and you 
might find large sets of database developers using Ada as a middleware 
or front-end tool.
Alexander E. Kopilovich wrote:
> Jason King wrote:
>> I'm an MIS guy not a CS guy and this is my take.
> 
> Well if you are from there then it is easy to asnwer - because it is current
> reality, which matters in MIS, and not high princples and/or sophisticated
> tastes.
> 
>> As we survey the landscape we see vb, delphi, ada, java etc.
> 
> So your enviroment is Windows - as you considered VB and Delphi.
> 
>> Initially ada looks very attractive because we're an Oracle shop and 
>> pl/sql (the stored procedure/trigger language inside the Oracle db) is 
>> based on ada-83.  Then we look for database access, tools to build 
>> client guis and tools to build web applications.  The tools available 
>> are substantially inferior in number and outside documentation to the 
>> ones available for java.
> 
> Well, not only to the Java, but even more so to VB and Delphi.
> 
> But why do you think that GUI layer should be programmed using the same
> language that middleware? You can (and perhaps should) separate your GUI
> stuff from the core of you application - and this GUI layer can be perfectly
> developed using VB or Delphi and then made available to the core in the form
> of DLL or ActiveX or .NET controls. (Altough if you choose Java for GUI layer
> you'll probably have much more trouble with that separation.)
> 
>>  Then the bosses look around to see how hard it 
>> is to hire new people for the shop as our client list expands.  There 
>> aren't a whole bunch of ada developers out there but there are schools 
>> on several continents churning out armies of java developers.
> 
> Well, if you need armies of developers then surely you must choose Java.
> But do you really want those armies? Perhaps just 2-3, well, at the edge of
> imagination, 5 developers would suffice, even if your client list explodes.
> And there will be no trouble to find so few developers with reasonable 
> knowledge of Ada (especially if your business is so successfull and rapidly
> expanding).
> 
>> In a world where we could search Amazon and find as many ada books as 
>> java books or get as many cvs with ada experience as java experience 
>> then ada would be an obvious choice.
> 
> Well, you can search Amazon and find there very few Ada books (which aren't
> outdated). But you need not more, because those are proper books, and they
> describe Ada quite well. 
> 
> Actually I do not think there is (and even could be) any books of comparable
> quality and language coverage for Java.
> 
>>  In the world as it exists the 
>> availability of support materials and experienced developers outweighs 
>> the technical merits of ada.
> 
> The word "support" is crucial here. Ada is exactly support-oriented language.
> But "support" for Ada means regular professional support, and not a kind of
> random support from the elements in and around the industry.
> 
> Therefore, if you can afford such regular professional support (for example,
> like that provided by AdaCore for users of their GNAT Professional compiler)
> then you can use Ada for you business applications quite succesfully. But if
> not, then, well, perhaps you better do not try to use Ada in you business
> applications unless your developers are great Ada enthusiasts.
> 
> 
> 
> 
> 

Re: What is wrong with Ada?

[Stuart]

"Georg Bauhaus" <bauhaus@futureapps.de> wrote in message 
news:1176412709.5632.55.camel@localhost.localdomain...
> On Thu, 2007-04-12 at 14:47 -0400, Robert A Duff wrote:
>
>> And it is impossible to cover all paths in a program containing
>> unbounded loops or recursion, because there are an infinite number of
>> them.
>
> Just out of curiosity: If I have a suitable annotated program,
> is there a tool that can give a good estimate on the number of
> steps along a selection of paths that indicates the program
> is running in circles? (Not that I expect to be still alive when
> the test has finished... :-)

SPARK does analyze loops for stability (stops doing anything apparently 
useful) and reports how many iterations it takes (its index).  That is a 
fairly crude description - I expect Peter or Rod might chip in with some 
more detail.

A Google search on "flow analysis" and "loop stability" throws up quite 
useful references - including an ACM paper on: "Information-Flow and 
Data-Flow Analysis of while Programs" by Bergeretti and Carre.

-- 
Stuart 

Re: What is wrong with Ada?

[Harald Korneliussen]

On Apr 12, 8:47 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> There is no way to be sure the code is bug free!  Not in any language.
> Not using testing, nor any other method (including so-called
> proof of correctness).
>
In so-called dependently-typed languages, you can use the type system
to ensure the correctness of a program, at least such a program as
your primality checker. The type-theorists talk about this curry-
howard isomorphism thing, which apparently is an isomorphism between
programs and proof.

I think the SPARK people would agree that there are indeed methods to
assure that code is bug-free, at least to the extent that the
specification is bug-free (and even that can to some degree be checked
mechanically!). Not to say that it is easy, cheap, or even feasible in
very many cases, but don't you underestimate a good type system.

Re: What is wrong with Ada?

[Georg Bauhaus]

On Thu, 2007-04-12 at 21:59 -0500, Jason King wrote:
>  Work with us pl/sql people and you 
> might find large sets of database developers using Ada as a middleware 
> or front-end tool.

Would Cobol style records be relevant in current database
programming? I'm asking because of Annex F, Information Systems
combined with the elaborate base types of Ada always seemed to be
a good match for an RDBMS that uses more than INT, REAL,
and CHARACTER VARYING. (Is anyone in the wild actually using
a money type or a decimal type in table definitions?)

Re: What is wrong with Ada?

[Georg Bauhaus]

On Fri, 2007-04-13 at 08:39 +0100, Stuart wrote:

> A Google search on "flow analysis" and "loop stability" throws up quite 
> useful references - including an ACM paper on: "Information-Flow and 
> Data-Flow Analysis of while Programs" by Bergeretti and Carre.

Thanks.
I didn't know the key word.

Re: What is wrong with Ada?

[Harald Korneliussen]

On Apr 12, 3:04 pm, Markus E Leypold
> laws. I.e. there is the whole issue of stabdardization and how to use
> standards properly.

That was a very interesting typo, actually.

Re: What is wrong with Ada?

[Adam Beneschan]

On Apr 13, 3:46 am, "Harald Korneliussen" <vinterm...@gmail.com>
wrote:
> On Apr 12, 3:04 pm, Markus E Leypold
>
> > laws. I.e. there is the whole issue of stabdardization and how to use
> > standards properly.
>
> That was a very interesting typo, actually.

It's even more interesting if you rearrange the first four letters a
bit.

                                     -- Adam

Re: What is wrong with Ada?

[Dmitry A. Kazakov]

On Fri, 13 Apr 2007 02:16:56 +0200, Markus E Leypold wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Tests should cover all program states. Covering all paths is a rough
>> approximation of.
> 
>> But the number of program states is finite, or else the program is wrong
>> anyway? 
> 
> Don't understand that. Assuming the program terminates fo a give input
> I the number of states it goes through during execution -- S_1 ... S_n
> -- is finite. The number of valid input sets is usually less well
> defined, but assuming (and this is wrong) they are finite, i.e. the
> sets I \from I_1, I_2 ... I_n are the only valid input then you still
> have a finite number of program states. Still the number of possible
> inputs might be rather large (i.e. to a type setter it's all possible
> books :-), so exhaustive testing is impossible (and your "Tests should
> cover all program states" is just saying, that you can't test enough).
> 
> But the set of all inputs is not necessarily finite -- i.e. in the
> case that the user might enter one data item after the other and get
> some answer about that item until he enters a end-of-input symbol
> (stupid example: an interactive prime tester). Since it is nonsense to
> artificially restrict the length of the user interaction just to get a
> finite set of input sequences, we will have to live with a infinite
> number of potential inputs to the program. So the paths covered are
> also inifinite (program state is still finite since the machine has
> only finite state).

What I meant is that we cannot write a correct program running on a finite
machine which would non-trivially processes an infinite input. [ <=>
uncountable sets cannot be enumerated. ]

Consider a program P that counts the number of key presses. This program is
necessarily incorrect. Because a correct P would have an infinite number of
states.

Obviously, for an unlimited input, if you use Integer, you have to deal
with Constraint_Error, if you use Unbounded_String be prepared to
Storage_Error [*]. Otherwise the program is not non-testable, it is
*proven* wrong.

Non-testability is rather practical. For all, if P has n states then a test
program T(P) should have > 2**n states, and T(T(P)) should have >
2**(2**n)...

------------
* but Storage_Error cannot be handled in Ada!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: What is wrong with Ada?

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Fri, 13 Apr 2007 02:16:56 +0200, Markus E Leypold wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> Tests should cover all program states. Covering all paths is a rough
>>> approximation of.
>> 
>>> But the number of program states is finite, or else the program is wrong
>>> anyway? 
>> 
>> Don't understand that. Assuming the program terminates fo a give input
>> I the number of states it goes through during execution -- S_1 ... S_n
>> -- is finite. The number of valid input sets is usually less well
>> defined, but assuming (and this is wrong) they are finite, i.e. the
>> sets I \from I_1, I_2 ... I_n are the only valid input then you still
>> have a finite number of program states. Still the number of possible
>> inputs might be rather large (i.e. to a type setter it's all possible
>> books :-), so exhaustive testing is impossible (and your "Tests should
>> cover all program states" is just saying, that you can't test enough).
>> 
>> But the set of all inputs is not necessarily finite -- i.e. in the
>> case that the user might enter one data item after the other and get
>> some answer about that item until he enters a end-of-input symbol
>> (stupid example: an interactive prime tester). Since it is nonsense to
>> artificially restrict the length of the user interaction just to get a
>> finite set of input sequences, we will have to live with a infinite
>> number of potential inputs to the program. So the paths covered are
>> also inifinite (program state is still finite since the machine has
>> only finite state).
>
> What I meant is that we cannot write a correct program running on a finite
> machine which would non-trivially processes an infinite input. [ <=>
> uncountable sets cannot be enumerated. ]

That is, excuse me, wrong. I thought that you had fallen for that
fallacy. Let me explain:

The machine itself might go only through a finite number of
states. But the user input might be a sequence of key presses that
might terminate arbitrarily late. The input is finite, but the
"processing state space" and the output space are only finite. This is
possible: Imagein a "machine" that only counts/indicates wether the
number of keypresses entered in a sequence from power-on to the end of
sequence mark are odd or even: Finite program, finite states (rather
easy indeed). But the set of all "legal" input sequences is
infinite. Nonetheless the program is correct.

> Consider a program P that counts the number of key presses. This program is
> necessarily incorrect. Because a correct P would have an infinite number of
> states.

In this case yes. But see above. Logically an example that shows an
attempt to produce an artefact with property X (your program) that
fails, does not prove its impossible. I've shown that your proposition
doesn't hold (except if you define "non-trivially" as requiring an
infinete number of "processing states".

> Obviously, for an unlimited input, if you use Integer, you have to deal
> with Constraint_Error, if you use Unbounded_String be prepared to
> Storage_Error [*]. Otherwise the program is not non-testable, it is
> *proven* wrong.
>
> Non-testability is rather practical. For all, if P has n states then a test
> program T(P) should have > 2**n states, and T(T(P)) should have >
> 2**(2**n)...

See above: You're wrong.

Regards -- Markus

Re: What is wrong with Ada?

[Jason King]

Generally in an Oracle database (this generalization based on about 15 
years experience in several industries) you find these datatypes employed.
VARCHAR2 - A string datatype that has the Oracle-specific behavior that 
trailing spaces are ignored in comparisons, eg
DECLARE
    x varchar2(10) := 'abc   ';
    y varchar2(10) := 'abc';
BEGIN
    IF x = y THEN
       dbms_output.put_line('They match');
    END IF;
END;
produces the output 'They match' on the console.  That, btw, is pl/sql 
but I'm sure the keywords and structure look familiar to everybody in c.l.a.
NUMBER(precision) -- integer
NUMBER(precision,scale) -- decimal number, Oracle stores these 
internally in a bcd-like manner so no floating-point rounding errors occur.
DATE -- actually date and time to seconds.
Recent versions of Oracle have added several flavors of
TIMESTAMP(precision) -- date and time to <precision> fraction of seconds
e.g.
DECLARE
    when timestamp(6); -- time to seconds/100000

In pl/sql code but not actually in the database itself you often see 
BOOLEAN which can have the values true, false and null, although 
booleans cannot be persisted as such into the database.

MSSQL has a currency datatype and several flavors of numeric datatypes, 
but as to how common their usage is I don't know because virtually all 
my real database work has been against Oracle.
For business applications I'd be surprised to see extensive use of REAL 
(esp if it maps to a c-style float or double) because of rounding 
issues.  The decimal item that business applications are most concerned 
about is generally money and rounding is fatal wrt money.
Recent versions of Oracle allow structured data in tables e.g.
create type address_t (   -- new object type
    address1 varchar2(50),
    address2 varchar2(50),
    city     varchar2(30),
    state    varchar2(3),
    zip      varchar2(9),
    country  varchar2(3)
    -- we could define methods as well as members
);
create table contacts (
    name varchar2(50),
    address address_t
);
Creates a table that contains an address as part of the datatype. 
Inside Oracle this is fairly straightforward to access, e.g.
BEGIN
    FOR c IN (SELECT * from CONTACTS ) LOOP
        -- iterate through contacts table
        dbms_output.put_line(c.address.state) ; -- print contact's state
   END LOOP;
END;
Accessing the object from non-Oracle tools like Crystal Reports is often 
more difficult.
Georg Bauhaus wrote:
> On Thu, 2007-04-12 at 21:59 -0500, Jason King wrote:
>>  Work with us pl/sql people and you 
>> might find large sets of database developers using Ada as a middleware 
>> or front-end tool.
> 
> Would Cobol style records be relevant in current database
> programming? I'm asking because of Annex F, Information Systems
> combined with the elaborate base types of Ada always seemed to be
> a good match for an RDBMS that uses more than INT, REAL,
> and CHARACTER VARYING. (Is anyone in the wild actually using
> a money type or a decimal type in table definitions?)
> 
> 

Re: What is wrong with Ada?

[Chad R. Meiners]

On Apr 11, 5:40 am, Jean-Pierre Rosen <r...@adalog.fr> wrote:
> Chad R. Meiners a écrit :> I disagree. Sometimes trace messages add line noise and maintaince
> > requirements to the code base,
>
> Huh?
> Trace messages are put just to check an hypothesis, and removed
> immediately afterwards. Certainly not kept in configuration, and limited
> to a couple of lines!

I always keep important hypothesis (trace statements) around during
development because a particular trace sequence for a particular bug
does not ensure full coverage of the the algorithm.  I have needed the
same trace statement more than once at different times in some
software life cycles.

> > and it is much easier to trace through
> > the algorithm step by step (using conditional breaks when necessary).
>
> My experience is that recompiling (generally a single body where you
> added the trace) is much faster than starting the debugger, setting
> breakpoints, skipping lots of unnecessary breaks, and so on.

And my experience is that starting a debugger is faster than inserting
some verbose trace statements, and then recompiling.  If you are
skipping a lot of unnecessary breaks, you are not using the debugger
properly.

> Moreover, a trace message gives you exactly the information you need,
> while interpreting a particular (complicated) structure from a debugger
> is generally quite difficult. Did you ever try to understand an ASIS
> "Element" ?

I completely agree.  For <b>some</b> cases, traces messages provide
the right information in the most efficient and effective way.
However, I do not accept that trace messages are <b>always</b> a
better way to find bugs than using a debugger.

Re: What is wrong with Ada?

[Chad R. Meiners]

On Apr 12, 2:47 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:

> There is no way to be sure the code is bug free!

This is only true in the same sense as "There is no way to be sure of
anything!".  Hopefully, this was the point of the rest of the
silliness that you posted afterwards. ;-)

Re: What is wrong with Ada?

[Chad R. Meiners]

On Apr 12, 3:54 pm, "Peter C. Chapin" <pcha...@sover.net> wrote:
> > But the number of program states is finite, or else the program is wrong
> > anyway?
>
> In a Turing complete programming language it is possible to write programs
> with unbounded amount of state. Indeed... this is the essence of Turing
> completeness.
>
> P.S. If I understand SPARK properly, the SPARK subset of Ada is not Turning
> complete because for any given program there is a bound on how much state
> information the program might use. As a result the halting problem is
> decidable for SPARK programs. This is a consequence of the lack of dynamic
> allocation and recursion.

And you are correct in this.

> Of course useful programs can still be written
> with SPARK despite its theoretical incompleteness. I imagine that making
> SPARK less powerful than a Turing machine is the whole point of the
> restrictions it imposes. Turing machines are hard to analyze.

Turing machines, <b>in general</b>, are hard to analyze; the point is
to try to find a subset of Turing machines that are <b>useful</b> and
<b>easy to analyze</b>.

Re: What is wrong with Ada?

[Robert A Duff]

"Harald Korneliussen" <vintermann@gmail.com> writes:

> On Apr 12, 8:47 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
> wrote:
>> There is no way to be sure the code is bug free!  Not in any language.
>> Not using testing, nor any other method (including so-called
>> proof of correctness).
>>
> In so-called dependently-typed languages, you can use the type system
> to ensure the correctness of a program, ...

OK, but if "correct" means "obeys a formal specification", then correct
programs can have bugs.  By "bug", I mean that reasonable users would
consider it wrong behavior.  In many cases, it's not even possible to
formally specify what's "right" or "wrong" behavior.  Proof: we've all
witnessed arguments where one person says "it's a bug", and the other
says "no, it's a feature".  ;-)

>...at least such a program as
> your primality checker. The type-theorists talk about this curry-
> howard isomorphism thing, which apparently is an isomorphism between
> programs and proof.
>
> I think the SPARK people would agree that there are indeed methods to
> assure that code is bug-free, at least to the extent that the
> specification is bug-free...

There's the rub.  I've read studies that claim about half of all bugs
are bugs in the specification.  And of course many programs have no
specification other than the program itself.

Note also that SPARK is a very simple language, intended for very simple
applications (i.e. safety is more important than fancy features).  If
you try to write, say, a windows operating system, or an Ada compiler,
in SPARK, I think you would have trouble.  That's fine -- it's not what
SPARK is for.

>... (and even that can to some degree be checked
> mechanically!). Not to say that it is easy, cheap, or even feasible in
> very many cases, but don't you underestimate a good type system.

Agreed.  SofCheck is makes a tool that can go far in this direction,
in a practical way.  But it's a dangerous mistake to think that
some method or other can completely eliminate bugs.

- Bob

Re: What is wrong with Ada?

[Robert A Duff]

Markus E Leypold
<development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> But the set of all inputs is not necessarily finite -- i.e. in the
> case that the user might enter one data item after the other and get
> some answer about that item until he enters a end-of-input symbol
> (stupid example: an interactive prime tester). Since it is nonsense to
> artificially restrict the length of the user interaction just to get a
> finite set of input sequences, we will have to live with a infinite
> number of potential inputs to the program. So the paths covered are
> also inifinite (program state is still finite since the machine has
> only finite state).

Yes.  But I want to know that my program will work properly on any
computer, including ones that don't exist yet.  I don't know how big or
fast computers will be in ten years.  That's why it's useful to reason
about computers that have unbounded amounts of memory (and time!) --
e.g. Turing machines -- even though we will never be able to build
such a thing.

- Bob

Re: What is wrong with Ada?

[Robert A Duff]

"Chad  R. Meiners" <chad.rmeiners@gmail.com> writes:

> On Apr 12, 2:47 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
> wrote:
>
>> There is no way to be sure the code is bug free!
>
> This is only true in the same sense as "There is no way to be sure of
> anything!".

True.  ;-)

>...Hopefully, this was the point of the rest of the
> silliness that you posted afterwards. ;-)

Partly.

I was also arguing against the specific idea that if you can test all
paths (which is practical for SOME programs) then you've got a proof.
I gave a simple counterexample -- what's so silly about that?  ;-)

- Bob

Re: What is wrong with Ada?

[Markus E Leypold]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> Markus E Leypold
> <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
>
>> But the set of all inputs is not necessarily finite -- i.e. in the
>> case that the user might enter one data item after the other and get
>> some answer about that item until he enters a end-of-input symbol
>> (stupid example: an interactive prime tester). Since it is nonsense to
>> artificially restrict the length of the user interaction just to get a
>> finite set of input sequences, we will have to live with a infinite
>> number of potential inputs to the program. So the paths covered are
>> also inifinite (program state is still finite since the machine has
>> only finite state).
>
> Yes.  But I want to know that my program will work properly on any
> computer, including ones that don't exist yet.  I don't know how big or
> fast computers will be in ten years.  That's why it's useful to reason
> about computers that have unbounded amounts of memory (and time!) --
> e.g. Turing machines -- even though we will never be able to build
> such a thing.

Of course. That's another aspect I left out, because first I wanted to
deal with Dmitry's misconception that real or correct programs can
only have finite sets of possible input, thus exhaustive testing would
always be possible, but "only" impractical. Instead of arguing about
(non existent) inifinite machines (and I agree with your view that
reasoning about them is useful, but I know how far I come when
discussing non-existent theoretical constructs with Dmitry :-( ), I
decided to topple this hous of cards by pointing out that even finite
machines can process inputs from infinite sets. 

So sorry, in a sense you're barking up the wrong tree, since it wasn't
me who called inifinite machines useless or only theoretical (that was
Dmitry).

:-)

Regards -- Markus

Re: What is wrong with Ada?

[Markus E Leypold]

"Harald Korneliussen" <vintermann@gmail.com> writes:

> On Apr 12, 3:04 pm, Markus E Leypold
>> laws. I.e. there is the whole issue of stabdardization and how to use
>> standards properly.
>
> That was a very interesting typo, actually.

I know. Seems my subconscious doesn't like standardization very much :-). 

Regards -- Markus

Re: What is wrong with Ada?

[Dmitry A. Kazakov]

On Sat, 14 Apr 2007 12:48:12 +0200, Markus E Leypold wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> What I meant is that we cannot write a correct program running on a finite
>> machine which would non-trivially processes an infinite input. [ <=>
>> uncountable sets cannot be enumerated. ]
> 
> That is, excuse me, wrong. I thought that you had fallen for that
> fallacy. Let me explain:
> 
> The machine itself might go only through a finite number of
> states. But the user input might be a sequence of key presses that
> might terminate arbitrarily late. The input is finite, but the
> "processing state space" and the output space are only finite. This is
> possible: Imagein a "machine" that only counts/indicates wether the
> number of keypresses entered in a sequence from power-on to the end of
> sequence mark are odd or even: Finite program, finite states (rather
> easy indeed). But the set of all "legal" input sequences is
> infinite. Nonetheless the program is correct.

Which is an example of trivial processing.

>> Consider a program P that counts the number of key presses. This program is
>> necessarily incorrect. Because a correct P would have an infinite number of
>> states.
> 
> In this case yes. But see above. Logically an example that shows an
> attempt to produce an artefact with property X (your program) that
> fails, does not prove its impossible.

Hmm, that counting infinite sequences is incomputable in DFA barely
requires a formal proof...

> I've shown that your proposition
> doesn't hold (except if you define "non-trivially" as requiring an
> infinete number of "processing states".

Yes I do. Trivial means that the set of all possible input states could be
broken into a finite set of classes of equivalent states. In your case into
just two sets of odd and even sequences of key presses. Trivial infiniies
are fake ones.

BTW, your example could be made non-trivial, see Thomson's lamp. Which
shows that even trivial inputs don't ensure that the number of
computational states can be finite. It is a necessary but insufficient
condition. Consider an input of decimal digits. The objective is to
determine whether it composes an irrational number. Obviously any sequence
is either rational or not.
 
-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: What is wrong with Ada?

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sat, 14 Apr 2007 12:48:12 +0200, Markus E Leypold wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> What I meant is that we cannot write a correct program running on a finite
>>> machine which would non-trivially processes an infinite input. [ <=>
>>> uncountable sets cannot be enumerated. ]
>> 
>> That is, excuse me, wrong. I thought that you had fallen for that
>> fallacy. Let me explain:
>> 
>> The machine itself might go only through a finite number of
>> states. But the user input might be a sequence of key presses that
>> might terminate arbitrarily late. The input is finite, but the
>> "processing state space" and the output space are only finite. This is
>> possible: Imagein a "machine" that only counts/indicates wether the
>> number of keypresses entered in a sequence from power-on to the end of
>> sequence mark are odd or even: Finite program, finite states (rather
>> easy indeed). But the set of all "legal" input sequences is
>> infinite. Nonetheless the program is correct.
>
> Which is an example of trivial processing.
>
>>> Consider a program P that counts the number of key presses. This program is
>>> necessarily incorrect. Because a correct P would have an infinite number of
>>> states.
>> 
>> In this case yes. But see above. Logically an example that shows an
>> attempt to produce an artefact with property X (your program) that
>> fails, does not prove its impossible.
>
> Hmm, that counting infinite sequences is incomputable in DFA barely
> requires a formal proof...

>
>> I've shown that your proposition
>> doesn't hold (except if you define "non-trivially" as requiring an
>> infinete number of "processing states".
>
> Yes I do. Trivial means that the set of all possible input states could be

Fine. You just messed your argument up completely. If you need
infinite processing states, no real machine (only finite amount of
internal state) can execute a nontrivial program.

> broken into a finite set of classes of equivalent states. In your case into
> just two sets of odd and even sequences of key presses. Trivial infiniies
> are fake ones.

> BTW, your example could be made non-trivial, see Thomson's lamp. Which

No, I don't want to see Thompson's lamp.

What I want, is that you prove your assertion. As a preparation, let
me give some definitions:

 a) The model: We have a machine M that reads a sequence of input
    symbols from the set S.  The machine is powered up and loaded with
    an initial state P (we call that program).  The we start
    inputting. We have a method to decide when the the input is
    complete (either by feedback from the machine, effectively saying
    "you have entered enough of this") or by something the input
    operator does (entering the end of input symbol). After entering
    the complete input the machine somehow indicates that processing
    is done (or fails to indicate, which is a failure). Then we read
    out the result R. R comes from a set OUT (the set of all possible
    outputs dependent on the machines output equipment).

 b) We are now talking about specifications. As specification SP
    somehow specifies 

    (i) an input set IN, which is the set of all sequences from seq[S]
        that should be considered "legal" in the context of SP.

        IN might be inifinite (at least as far as SP is concerned),
        e.g. the set of all sequences of arbitrary length that end
        with the end of input symbol).

    (b) for every input sequence s \in IN an output r \in OUT which is
        to be considered the "correct" output for this input.

        The (partial) function s -> r (which I now name F[SP]) might
        be called the definige function (or semantics) of the
        specfication.

 c) Observe that for every initial state P in the state of the
    machine, the machine performs a mapping from seq[S] to OUT as
    well. That is what the program computes. This function C[P]:
    seq[S] => OUT is the functionality of the program.

 d) A P conforms to a specification if, within the range of the
    specfication, i.e. for every input s from IN[SP], it produces the
    required output F[SP](s).

     P conforms to SP <=> \forall s \in IN[SP] : C[P](s) = F[SP](s)

    (A program P conform to a specfication SP, if for every input
     element that has to be considered legal in the context of SP, the
     computed output element C[P](s) is the required/specified output
     element).
 

The model can certainly be refined (i.e. modelling programs as
equivalence classes of state), but I think is captures the essence of
what we are talking about here.

The goal is now, to prove or refute your assertions within that
framework. You asserted that

  \forall SP with NON-TRIVIAL(SP) and I[SP] infinite :           
   
     \not \exists P : P conforms SP.

I have alread shown (by counterexample, which is a valid refutation
for \not\exists in this case), that your assertion would be not true
just for all SP (i.e. NON-TRIVIAL is constantly FALSE.

But "non trivial" is not yet defined (I don't think it makes sense as
a formal concept).

Now I'd like you to close this loophole for arbitrary hand waving and
define NON-TRIVIAL in a way suitable to you purposes (but keep it
convincing, still -- defining it to FALSE won't wash with me) and
perhaps try to prove the central assertion above.

Thank you -- Markus


    
    


    

Re: What is wrong with Ada?

[Dmitry A. Kazakov]

On Sun, 15 Apr 2007 18:01:10 +0200, Markus E Leypold wrote:

> Now I'd like you to close this loophole for arbitrary hand waving and
> define NON-TRIVIAL in a way suitable to you purposes (but keep it
> convincing, still -- defining it to FALSE won't wash with me) and
> perhaps try to prove the central assertion above.

OK, here is a formalization of "non-trivial." Let me use a more or less
standard notation:

IN is the set of input states (the language over a finite alphabet A)
S is the set of states
s1 is the initial state
T : S x A -> S is the transition function
OUT = the set of output states (a subset of S, which we don't care)

def: Closure of T
----------------------
Let a=(a' a'' a''' a'''' ... a*) be a finite input from IN.

   P(a)=T(a*, ... T(a''', T(a'', T(a', s1))))

Informally P(a) is the state to which a would bring the machine.

   P : IN -> S

def: Equivalent input states (strings)
---------------------------------------------
a, b of IN are called equivalent iff P(a)=P(b).

Let's denote non-equivalent states as a#b

(P was defined on finite strings of IN. Defining it in some reasonable way
for infinite cases would require efforts, which I don't want to run into.)

def: Non-trivial input (language)
--------------------------------------
IN is non-trivial iff for any finite subset {a1, a2, a3,..., aN} of IN
there exits an input string b in IN such that forall i=1..N b#ai.

From this definition immediately follows that any machine handling
non-trivial input will necessarily have infinite S.

A classical example

ab
aabb
aaabbb
aaaabbbb
...

can serve as one of non-trivial input.

Other three I have mentioned in my previous posts: counting integers,
recognizing irrational numbers, summation of infinite series 1-1+1-1+1...
(aka Tompson's lamp).

P.S. This does not apply to Robert's example, because he considered a set
of machines with individual machines parametrized by some number which
influences the number of states.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: What is wrong with Ada?

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 15 Apr 2007 18:01:10 +0200, Markus E Leypold wrote:
>
>> Now I'd like you to close this loophole for arbitrary hand waving and
>> define NON-TRIVIAL in a way suitable to you purposes (but keep it
>> convincing, still -- defining it to FALSE won't wash with me) and
>> perhaps try to prove the central assertion above.
>
> OK, here is a formalization of "non-trivial." Let me use a more or less
> standard notation:

It would have been nice, if you could not have confused the issue by
changing the notation. 

Regards -- Markus

Re: What is wrong with Ada?

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 15 Apr 2007 18:01:10 +0200, Markus E Leypold wrote:
>
>> Now I'd like you to close this loophole for arbitrary hand waving and
>> define NON-TRIVIAL in a way suitable to you purposes (but keep it
>> convincing, still -- defining it to FALSE won't wash with me) and
>> perhaps try to prove the central assertion above.
>
> OK, here is a formalization of "non-trivial." Let me use a more or less
> standard notation:
>
> IN is the set of input states (the language over a finite alphabet A)
> S is the set of states
> s1 is the initial state
> T : S x A -> S is the transition function
> OUT = the set of output states (a subset of S, which we don't care)
>
> def: Closure of T
> ----------------------
> Let a=(a' a'' a''' a'''' ... a*) be a finite input from IN.
>
>    P(a)=T(a*, ... T(a''', T(a'', T(a', s1))))
>
> Informally P(a) is the state to which a would bring the machine.
>
>    P : IN -> S
>
> def: Equivalent input states (strings)
> ---------------------------------------------
> a, b of IN are called equivalent iff P(a)=P(b).
>
> Let's denote non-equivalent states as a#b

> (P was defined on finite strings of IN. Defining it in some reasonable way
> for infinite cases would require efforts, which I don't want to run into.)

>
> def: Non-trivial input (language)
> --------------------------------------

> IN is non-trivial iff for any finite subset {a1, a2, a3,..., aN} of IN
> there exits an input string b in IN such that forall i=1..N b#ai.
>
> From this definition immediately follows that any machine handling
> non-trivial input will necessarily have infinite S.

I can't believe it, but you really succeeded to muddle the issue at
hand -- again.

Your assertion was, that "... programs, which <something about non
trivial processing> are wrong", aka cannot be implemented on a finite
machine. "Wrong" in my world means: Don't conform to specification.

But -- you're not talking about specifications at all in your
formalization: You talk about programs and only about programs.

Perhaps I've formulated an unsuitable model. But at least common
politeness would have required, to state so and propose another model
-- instead of hiding your slight of hand in the formulation " "Let me
use a more or less standard notation" and then, without definition go
off in a totally different direction.

My challenge still stands: Define a sutiable predicate NON-TRIVIAL on
_the specification_.

What you prove (at first glance) is something completely
different. You prove that programs that have a certain property (which
you explained and call "non trivial") cannot be _implemented_ on
finite machines. Since real machines are finite, every real program is
trivial. This obviously is bollocks or at least a rather unusual
definition of trivial.

This is the Kazakov-Strategy at it's best.

Regards -- Markus

Re: What is wrong with Ada?

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 15 Apr 2007 18:01:10 +0200, Markus E Leypold wrote:
>
>> Now I'd like you to close this loophole for arbitrary hand waving and
>> define NON-TRIVIAL in a way suitable to you purposes (but keep it
>> convincing, still -- defining it to FALSE won't wash with me) and
>> perhaps try to prove the central assertion above.
>
> OK, here is a formalization of "non-trivial." Let me use a more or less
> standard notation:
>
> IN is the set of input states (the language over a finite alphabet A)
> S is the set of states
> s1 is the initial state
> T : S x A -> S is the transition function
> OUT = the set of output states (a subset of S, which we don't care)
>
> def: Closure of T
> ----------------------
> Let a=(a' a'' a''' a'''' ... a*) be a finite input from IN.
>
>    P(a)=T(a*, ... T(a''', T(a'', T(a', s1))))
>
> Informally P(a) is the state to which a would bring the machine.
>
>    P : IN -> S
>
> def: Equivalent input states (strings)
> ---------------------------------------------
> a, b of IN are called equivalent iff P(a)=P(b).
>
> Let's denote non-equivalent states as a#b
>
> (P was defined on finite strings of IN. Defining it in some reasonable way
> for infinite cases would require efforts, which I don't want to run into.)
>
> def: Non-trivial input (language)
> --------------------------------------
> IN is non-trivial iff for any finite subset {a1, a2, a3,..., aN} of IN
> there exits an input string b in IN such that forall i=1..N b#ai.
>
> From this definition immediately follows that any machine handling
> non-trivial input will necessarily have infinite S.
>
> A classical example
>
> ab
> aabb
> aaabbb
> aaaabbbb
> ...
>
> can serve as one of non-trivial input.
>
> Other three I have mentioned in my previous posts: counting integers,
> recognizing irrational numbers, summation of infinite series 1-1+1-1+1...
> (aka Tompson's lamp).
>
> P.S. This does not apply to Robert's example, because he considered a set
> of machines with individual machines parametrized by some number which
> influences the number of states.

On second thought your "proof" is not so far of the mark. Indeed,
you've proven that one cannot implement a certain class of algorithms
on finite machines. You call those (and only those) non-trivial.

Your original statement

> What I meant is that we cannot write a correct program running on a finite
> machine which would non-trivially processes an infinite input. [ <=>
> uncountable sets cannot be enumerated. ]

though. suggests (to me) another meanning of non trivial than just
"requires inifinitely many states". I'd have expected something more
motivated from the everyday use of the word trivial.

But be that as it may be: I only have to ask from you the favor, that
you don't spread the results of your research further, probably
refrain from publishing. Yes I know, science must publish and all
that, but consider, what will happen when our customers find out, that
all we do or even CAN do for them, is to implement _trivial_ data
processing, since they still have finite machines. You'll destroy --
single handely -- a whole branch of industry. I know you never have
held much regard for computer science (Quote: 'And that is because CS
is not much science. It rather sways between applied mathematics and
"stamp collecting"'), so they probably had it coming, but consider the
repercussions (hungry children, so called programmers jumping from the
top floors of sky scrapers, hitting innocent by standers -- all the
tragedy. So - please - show some mercy and keep it silent.

;-)

Regards -- Markus







>
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Re: What is wrong with Ada?

[Dmitry A. Kazakov]

On Mon, 16 Apr 2007 00:00:11 +0200, Markus E Leypold wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Sun, 15 Apr 2007 18:01:10 +0200, Markus E Leypold wrote:
>>
>>> Now I'd like you to close this loophole for arbitrary hand waving and
>>> define NON-TRIVIAL in a way suitable to you purposes (but keep it
>>> convincing, still -- defining it to FALSE won't wash with me) and
>>> perhaps try to prove the central assertion above.
>>
>> OK, here is a formalization of "non-trivial." Let me use a more or less
>> standard notation:
>>
>> IN is the set of input states (the language over a finite alphabet A)
>> S is the set of states
>> s1 is the initial state
>> T : S x A -> S is the transition function
>> OUT = the set of output states (a subset of S, which we don't care)
>>
>> def: Closure of T
>> ----------------------
>> Let a=(a' a'' a''' a'''' ... a*) be a finite input from IN.
>>
>>    P(a)=T(a*, ... T(a''', T(a'', T(a', s1))))
>>
>> Informally P(a) is the state to which a would bring the machine.
>>
>>    P : IN -> S
>>
>> def: Equivalent input states (strings)
>> ---------------------------------------------
>> a, b of IN are called equivalent iff P(a)=P(b).
>>
>> Let's denote non-equivalent states as a#b
> 
>> (P was defined on finite strings of IN. Defining it in some reasonable way
>> for infinite cases would require efforts, which I don't want to run into.)
>
>> def: Non-trivial input (language)
>> --------------------------------------
> 
>> IN is non-trivial iff for any finite subset {a1, a2, a3,..., aN} of IN
>> there exits an input string b in IN such that forall i=1..N b#ai.
>>
>> From this definition immediately follows that any machine handling
>> non-trivial input will necessarily have infinite S.
> 
> I can't believe it, but you really succeeded to muddle the issue at
> hand -- again.
> 
> Your assertion was, that "... programs, which <something about non
> trivial processing> are wrong", aka cannot be implemented on a finite
> machine. "Wrong" in my world means: Don't conform to specification.

def, Specification
------------------------
Given the language IN (over a finite alphabet A) and OUT, the set of output
states.

1. P exists on IN

2. P(IN) in OUT (= forall s in IN, P(s) in OUT)

def. Program
------------------
A program is the triplet {s1, S, T} (the initial state, the set of states,
the transition function).

> But -- you're not talking about specifications at all in your
> formalization: You talk about programs and only about programs.

Because my initial statement was about processing and the states of. When
processing is impossible, then whatever specification it should fulfill, it
does not.

> My challenge still stands: Define a sutiable predicate NON-TRIVIAL on
> _the specification_.

I did. Consider OUT instead of whole S.

> What you prove (at first glance) is something completely
> different. You prove that programs that have a certain property (which
> you explained and call "non trivial") cannot be _implemented_ on
> finite machines. Since real machines are finite, every real program is
> trivial. This obviously is bollocks or at least a rather unusual
> definition of trivial.

I called it trivial because a valid program processing an infinite input
would not require *all* the input to finish. So the ratio
card(S)/card(IN)=0. We can use some other word instead of "trivial," if
that is reserved for "I can understand this code after three beers..." 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: What is wrong with Ada?

[Jean-Pierre Rosen]

Chad R. Meiners a �crit :
>> Trace messages are put just to check an hypothesis, and removed
>> immediately afterwards. Certainly not kept in configuration, and limited
>> to a couple of lines!
> 
> I always keep important hypothesis (trace statements) around during
> development because a particular trace sequence for a particular bug
> does not ensure full coverage of the the algorithm.  I have needed the
> same trace statement more than once at different times in some
> software life cycles.
Aren't you confusing traces with assertions? I certainly leave 
assertions in my programs (and they call a "failure" procedure if they 
fail, with useful information). But I remove traces as soon I know what 
I was looking for.

>>> and it is much easier to trace through
>>> the algorithm step by step (using conditional breaks when necessary).
>> My experience is that recompiling (generally a single body where you
>> added the trace) is much faster than starting the debugger, setting
>> breakpoints, skipping lots of unnecessary breaks, and so on.
> 
> And my experience is that starting a debugger is faster than inserting
> some verbose trace statements, and then recompiling.  If you are
> skipping a lot of unnecessary breaks, you are not using the debugger
> properly.
OK, take a typical example (of what I am doing, YMMV). In an ASIS 
program (AdaControl of course), I have a failure due to an 
"inappropriate element" to a given call, that I can easily identify from 
the stack trace. That place is called very often, just once in a while 
is the parameter incorrect. With a trace, I just have to read the last 
message befor the failure. But since I don't know beforehand how many 
times the sequence is called before failing, I would have to break on 
any occurrence - maybe hundreds. Not counting the fact that it is after 
I type "continue" that the program fails, and that I know that I just 
restarted from the point where I should have been investigating!


-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: What is wrong with Ada?

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Mon, 16 Apr 2007 00:00:11 +0200, Markus E Leypold wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> On Sun, 15 Apr 2007 18:01:10 +0200, Markus E Leypold wrote:
>>>
>>>> Now I'd like you to close this loophole for arbitrary hand waving and
>>>> define NON-TRIVIAL in a way suitable to you purposes (but keep it
>>>> convincing, still -- defining it to FALSE won't wash with me) and
>>>> perhaps try to prove the central assertion above.
>>>
>>> OK, here is a formalization of "non-trivial." Let me use a more or less
>>> standard notation:
>>>
>>> IN is the set of input states (the language over a finite alphabet A)
>>> S is the set of states
>>> s1 is the initial state
>>> T : S x A -> S is the transition function
>>> OUT = the set of output states (a subset of S, which we don't care)
>>>
>>> def: Closure of T
>>> ----------------------
>>> Let a=(a' a'' a''' a'''' ... a*) be a finite input from IN.
>>>
>>>    P(a)=T(a*, ... T(a''', T(a'', T(a', s1))))
>>>
>>> Informally P(a) is the state to which a would bring the machine.
>>>
>>>    P : IN -> S
>>>
>>> def: Equivalent input states (strings)
>>> ---------------------------------------------
>>> a, b of IN are called equivalent iff P(a)=P(b).
>>>
>>> Let's denote non-equivalent states as a#b
>> 
>>> (P was defined on finite strings of IN. Defining it in some reasonable way
>>> for infinite cases would require efforts, which I don't want to run into.)
>>
>>> def: Non-trivial input (language)
>>> --------------------------------------
>> 
>>> IN is non-trivial iff for any finite subset {a1, a2, a3,..., aN} of IN
>>> there exits an input string b in IN such that forall i=1..N b#ai.
>>>
>>> From this definition immediately follows that any machine handling
>>> non-trivial input will necessarily have infinite S.
>> 
>> I can't believe it, but you really succeeded to muddle the issue at
>> hand -- again.
>> 
>> Your assertion was, that "... programs, which <something about non
>> trivial processing> are wrong", aka cannot be implemented on a finite
>> machine. "Wrong" in my world means: Don't conform to specification.
>
> def, Specification
> ------------------------
> Given the language IN (over a finite alphabet A) and OUT, the set of output
> states.
>
> 1. P exists on IN
>
> 2. P(IN) in OUT (= forall s in IN, P(s) in OUT)
>
> def. Program
> ------------------
> A program is the triplet {s1, S, T} (the initial state, the set of states,
> the transition function).
>
>> But -- you're not talking about specifications at all in your
>> formalization: You talk about programs and only about programs.
>
> Because my initial statement was about processing and the states of. When
> processing is impossible, then whatever specification it should fulfill, it
> does not.

I already granted that point -- still, I don't like when people change
the rules implicitely.

>
>> My challenge still stands: Define a sutiable predicate NON-TRIVIAL on
>> _the specification_.
>
> I did. Consider OUT instead of whole S.


>> What you prove (at first glance) is something completely
>> different. You prove that programs that have a certain property (which
>> you explained and call "non trivial") cannot be _implemented_ on
>> finite machines. Since real machines are finite, every real program is
>> trivial. This obviously is bollocks or at least a rather unusual
>> definition of trivial.

> I called it trivial because a valid program processing an infinite input
> would not require *all* the input to finish. 

(Hm, what is "valid"? You keep introducing new predicates into the
discussion all the time which are undefined so far and only serve to
twist the rules later, I suspect.)

Sorry, that is nonsense. Take the program which just determines wether
the length of a finite sequence ending with EOI is even or odd. (1)
It's trivial by your definition, (2) it requires (obviously) the
complete input sequence to give the right answer, (3) it CAN be
implemented on a finite machine and (4) it has an infinite set of
possible inputs IN.

Of course it doesn't stop or give a useful answer on sequences that
are not in IN (don't end with the proper end-of-input symbol), but
this is exactly why I took the pain to distinguish between the spec SP
and the program P, which is not required to give any meaningful
results when fed with input outside the spec.

My suspicion is you're mixing up (a) "inifinite input sequences"
(i.e. input items consisting of an inifinite number of input symbols)
with (b) "inifinite set of possible inputs".  I'm sorry if I can't
formulate that more precisely in plain english: One of the reasons I
tried a methamatical notation, but you had to switch horses and
incompletely at that.

The latter case (b) would be card(IN) is infinite (countable in our
case, since S is countable, IN \subset seq[S] and seq(S), the set of
all finite sequences from symbols in S is countable), in my
notation. The first case (a) is not contained in IN ever (in my
model) since I'm not talking about infinite sequences one has to read
out the result some time (at the end of the input sequence).

> So the ratio
> card(S)/card(IN)=0. We can use some other word instead of "trivial," if
> that is reserved for "I can understand this code after three beers..." 

I repeat again: According to your definition all real programs on real
machines are "trivial". So you can understand them all after three
beers? I bow before your superiority, super human Dmitry A. Kazakov
(but if that mixture of bad science and bragging continues, won't be
able to take you serious for much longer).

Regards -- Markus

Re: What is wrong with Ada?

[Dmitry A. Kazakov]

On Mon, 16 Apr 2007 10:50:49 +0200, Jean-Pierre Rosen wrote:

> Chad R. Meiners a �crit :

>> And my experience is that starting a debugger is faster than inserting
>> some verbose trace statements, and then recompiling.  If you are
>> skipping a lot of unnecessary breaks, you are not using the debugger
>> properly.
> OK, take a typical example (of what I am doing, YMMV). In an ASIS 
> program (AdaControl of course), I have a failure due to an 
> "inappropriate element" to a given call, that I can easily identify from 
> the stack trace. That place is called very often, just once in a while 
> is the parameter incorrect. With a trace, I just have to read the last 
> message befor the failure.

That reminds me early days. That time there existed debuggers executing
(assembly) program backwards. That would be an equivalent to tracing.

(I think it is obvious that tracing is far more powerful but also much less
comfortable than conventional debuggers.)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: What is wrong with Ada?

[Markus E Leypold]

Jean-Pierre Rosen <rosen@adalog.fr> writes:

> Chad R. Meiners a �crit :
>>> Trace messages are put just to check an hypothesis, and removed
>>> immediately afterwards. Certainly not kept in configuration, and limited
>>> to a couple of lines!
>> I always keep important hypothesis (trace statements) around during
>> development because a particular trace sequence for a particular bug
>> does not ensure full coverage of the the algorithm.  I have needed the
>> same trace statement more than once at different times in some
>> software life cycles.
> Aren't you confusing traces with assertions? I certainly leave
> assertions in my programs (and they call a "failure" procedure if they
> fail, with useful information). But I remove traces as soon I know
> what I was looking for.
>
>>>> and it is much easier to trace through
>>>> the algorithm step by step (using conditional breaks when necessary).
>>> My experience is that recompiling (generally a single body where you
>>> added the trace) is much faster than starting the debugger, setting
>>> breakpoints, skipping lots of unnecessary breaks, and so on.
>> And my experience is that starting a debugger is faster than
>> inserting
>> some verbose trace statements, and then recompiling.  If you are
>> skipping a lot of unnecessary breaks, you are not using the debugger
>> properly.
> OK, take a typical example (of what I am doing, YMMV). In an ASIS
> program (AdaControl of course), I have a failure due to an
> "inappropriate element" to a given call, that I can easily identify
> from the stack trace. That place is called very often, just once in a
> while is the parameter incorrect. With a trace, I just have to read
> the last message befor the failure. But since I don't know beforehand
> how many times the sequence is called before failing, I would have to
> break on any occurrence - maybe hundreds. Not counting the fact that
> it is after I type "continue" that the program fails, and that I know
> that I just restarted from the point where I should have been
> investigating!

That is, why I talkes about "well integrated debuggers". A well
integrated debugger allows one to specify conditions on which the
breaks occur and "knows" enough about the source language to let the
user express conditions in terms of the source language. 

Regards -- Markus

Re: What is wrong with Ada?

[Bob Spooner]

"Markus E Leypold" 
<development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> wrote in 
message news:n3r6qpea4p.fsf@hod.lan.m-e-leypold.de...
>
> "kevin  cline" <kevin.cline@gmail.com> writes:
>
>> Are you claiming that use of Ada makes it safe to release code that
>> has never been tested?
>
> Actually -- why not? In my experience spuriously tested Ada code
> usually has the quality of extensively tested C code. Perhaps my cases
> where not really comparable, but it is astonishing how much Ada code
> is "just right" if it compiles.
>
> Of course we're not talking about embedded programs / control systems
> of whatever kind here. And those should probably better verified
> and/or extenseively formally reviewd instead of only tested.
>
> Remember: Formal review is a (proven) much better QA tool than
> testing.
>
This has been my experience as well. When I was first learning Ada, back 
around 1986 or so, I was astonished at the percentage of programs I wrote 
which, once I had a clean compile, did _exactly_ what I expected. It's borne 
out as well in the form those "stump the experts" sessions take. With C type 
languages, the question is: "What does this do?" With Ada, the question is: 
"Will this compile?"

Bob 

Re: What is wrong with Ada?

[Markus E Leypold]

"Bob Spooner" <rls19@psu.edu> writes:

> "Markus E Leypold" 
> <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> wrote in 
> message news:n3r6qpea4p.fsf@hod.lan.m-e-leypold.de...
>>
>> "kevin  cline" <kevin.cline@gmail.com> writes:
>>
>>> Are you claiming that use of Ada makes it safe to release code that
>>> has never been tested?
>>
>> Actually -- why not? In my experience spuriously tested Ada code
>> usually has the quality of extensively tested C code. Perhaps my cases
>> where not really comparable, but it is astonishing how much Ada code
>> is "just right" if it compiles.
>>
>> Of course we're not talking about embedded programs / control systems
>> of whatever kind here. And those should probably better verified
>> and/or extenseively formally reviewd instead of only tested.
>>
>> Remember: Formal review is a (proven) much better QA tool than
>> testing.
>>
> This has been my experience as well. When I was first learning Ada, back 

I'd like to add to my statement and your experience that there is some
IBM study about this: A certain level of quality could only be reached
by mixes of QA methods and all those had formal review in them,
whereas those levels could not be attained by any combination of the
other methods without formal review.

This is a sobering realization, considering that many code in most
companies I know is never seen by more than one pair of eyes.

I could look up the study, but the notes are currently out of my
reach.

> around 1986 or so, I was astonished at the percentage of programs I wrote 
> which, once I had a clean compile, did _exactly_ what I expected. It's borne 
> out as well in the form those "stump the experts" sessions take. With C type 
> languages, the question is: "What does this do?" With Ada, the question is: 
> "Will this compile?"

As with almost every other strongly and statically typed language
(I've made similar experience with Turbo Pascal (when I was young),
and with Ocaml). Still, the relationship between program and
specification and specfification and requirements and requirements and
what the customer wants/says her wants, must be checked (reviewed),
because the compiler won't do that for you.

The fact that static type systems are so effective in reducing the bug
rate in the development cycle, in my eyes indicates how many bugs (in
C, C++, Assembler) are simple omission (forget to set or increment a
variable) or typos (assign instead of compare, forget to dereference a
pointer or use the wrong pointer at some place).

Instead of review (if one isn't working in a larger team,
e.g. students or "garage developers): If one has the discipline one
very useful exercise is to write a module, let it lay around for a
week or 14 days and then write interface documentation for it. It
forces one to reconsider the code in question. Of course I'm talking
about empirically grown code here or code that has be factored out
from other code, not something that has gone through a NASA style
development process. Since this happens all the time in reality
anyway, the least one can do, is to look at it twice, instead of
insisting that this should never happen and stop at that, as some
people do.

Regards -- Markus

Re: What is wrong with Ada?

[Robert A Duff]

Jean-Pierre Rosen <rosen@adalog.fr> writes:

> OK, take a typical example (of what I am doing, YMMV). In an ASIS
> program (AdaControl of course), I have a failure due to an
> "inappropriate element" to a given call, that I can easily identify from
> the stack trace. That place is called very often, just once in a while
> is the parameter incorrect. With a trace, I just have to read the last
> message befor the failure. But since I don't know beforehand how many
> times the sequence is called before failing, I would have to break on
> any occurrence - maybe hundreds. Not counting the fact that it is after
> I type "continue" that the program fails, and that I know that I just
> restarted from the point where I should have been investigating!

I used a debugger for OCaml that can execute backwards.  So you stop at
the failing assertion/check, and back up to see how you got there.
You can execute backward to a breakpoint, or single step backward.
Very useful in this sort of case.

In more primitive debuggers, you could still do various things without
using trace statements in the code.  E.g. you could set a breakpoint
on the assertion, and another on the failure of the assertion.
Disable the former.  Run.  Tell the debugger to print out the
count for the former.  Start over, with former enabled,
telling it to stop after N-1 times.  Now single-step
toward the bug.  Of course, if it's flaky, you're out of luck.

Having said all that -- I do sometimes use trace statements in the code.
E.g. when I suspect the debugger is telling a fib.  Or when I want
to analyze the log using editor searching or the like, after the fact.

- Bob

Re: What is wrong with Ada?

[Georg Bauhaus]

On Sat, 2007-04-14 at 10:28 -0500, Jason King wrote:
>  e.g.
> create type address_t (   -- new object type
>     address1 varchar2(50),
>     address2 varchar2(50),
>     city     varchar2(30),
>     state    varchar2(3),
>     zip      varchar2(9),
>     country  varchar2(3)
>     -- we could define methods as well as members
> );
> create table contacts (
>     name varchar2(50),
>     address address_t
> );

Given all these possibilities (but even with only enough basic
data types), I think there might be an interesting
way to store (tagged) program objects in a DB and make use of the new
Ada.Tags.Generic_Dispatching_Constructor. The effect would be a
straightforward function that delivers objects of suitable type
based on (a) search results and (b) program need.

Re: What is wrong with Ada?

[Georg Bauhaus]

On Mon, 2007-04-16 at 11:04 +0200, Markus E Leypold wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> > I called it trivial because a valid program processing an infinite input
> > would not require *all* the input to finish. 

>  According to your definition all real programs on real
> machines are "trivial".

Wouldn't that depend on what "processing" means? Dmitry,
is your program a reactive system (reaching one of its "final"
states when a certain subsequence of input has been read,
reported, and forgotten? Like sensor data, or quadruples of 7
in the decimal expansion of π)?

Re: What is wrong with Ada?

[Jean-Pierre Rosen]

Robert A Duff a �crit :
> In more primitive debuggers, you could still do various things without
> using trace statements in the code.  E.g. you could set a breakpoint
> on the assertion, and another on the failure of the assertion.
> Disable the former.  Run.  Tell the debugger to print out the
> count for the former.  Start over, with former enabled,
> telling it to stop after N-1 times.  Now single-step
> toward the bug.
> 
And how long does it take? Adding a trace - recompiling - getting the 
answer is less than one minute (and I don't have an especially fast 
machine!). That's my whole point. I never said that debuggers were 
useless, and I certainly happen to use one every now and then. But most 
of the time, I find adding a trace faster, for the kind of program I'm 
writing.

Of course, a great help here is that if you modify a body in Ada, you 
just need to recompile that body...

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: What is wrong with Ada?

[Pascal Obry]

Markus,

> This is a sobering realization, considering that many code in most
> companies I know is never seen by more than one pair of eyes.

That's definitely my experience too. Really strange and I'm trying to
change that. 2 developers on 2 projects for one year... why not 2
developers on 1 project for 6 months, and then on the second project...

I bet that the total time will be inferior to one year as many errors
will probably be caught by this second pair of eyes on the project. Is
there some studies in this direction ? What are the conclusions ?

I also think that during the design period having somebody involved to
discuss about the possible options will avoid some mistakes...

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: What is wrong with Ada?

[Dmitry A. Kazakov]

On Tue, 17 Apr 2007 09:58:26 +0200, Georg Bauhaus wrote:

> On Mon, 2007-04-16 at 11:04 +0200, Markus E Leypold wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>>> I called it trivial because a valid program processing an infinite input
>>> would not require *all* the input to finish. 
> 
>> According to your definition all real programs on real
>> machines are "trivial".

Yes, provided they are correct.

(Incorrect programs can be very non-trivial, as everybody having once
debugged a program knows... (:-))

> Wouldn't that depend on what "processing" means? Dmitry,
> is your program a reactive system (reaching one of its "final"
> states when a certain subsequence of input has been read,
> reported, and forgotten? Like sensor data, or quadruples of 7
> in the decimal expansion of οΏ½)?

Sort of. That the input could be forgotten for future processing is a
"triviality" condition of processing, program, input language, whatever.

(Under certain conditions "processing", "program", "language" are all
equivalent.)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: What is wrong with Ada?

[Georg Bauhaus]

On Tue, 2007-04-17 at 11:17 +0200, Pascal Obry wrote:
>  2 developers on 2 projects for one year... why not 2
> developers on 1 project for 6 months, and then on the second project...
> 
> I bet that the total time will be inferior to one year as many errors
> will probably be caught by this second pair of eyes on the project. Is
> there some studies in this direction ? What are the conclusions ?

That would be pair programming,
http://en.wikipedia.org/wiki/Pair_programming

(Pair programming has better results when the pair differs
in views, I think.)

Re: What is wrong with Ada?

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Tue, 17 Apr 2007 09:58:26 +0200, Georg Bauhaus wrote:
>
>> On Mon, 2007-04-16 at 11:04 +0200, Markus E Leypold wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>>> I called it trivial because a valid program processing an infinite input
>>>> would not require *all* the input to finish. 
>> 
>>> According to your definition all real programs on real
>>> machines are "trivial".
>
> Yes, provided they are correct.

Well, that sentence doesn't parse in your world. You haven't defined
"correct" and can't yet, because you haven't specifications in your
world yet, only programs. Since you have programs/machines and defined
"trivial" as their property all real machines only do trivial data
processing. I don't see where "correct" comes in: You don't need it
since you didn't need it when defining trivial. I'm a bit surprised it
now turns up as a pre condition for applying the predicate trivial.

Would your answer "provided they are correct" to the statement "
According to your definition all real programs on real machines are
"trivial" perhaps mean I could do non-trivial data processing with
_incorrect_ programs? 

If so, I'd like to see an example of an incorrect program on a finite
machine that isn't trivial (i.e. has an infinite number of internal
states according to your definition).

Puzzled -- Markus

Re: What is wrong with Ada?

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> (Under certain conditions "processing", "program", "language" are all
> equivalent.)

I doubt that. One of the reasons why I tried a more formal approach
was to avoid that loophole of meandering terminology.

Regards -- Markus

Re: What is wrong with Ada?

[Robert A Duff]

Jean-Pierre Rosen <rosen@adalog.fr> writes:

> And how long does it take? Adding a trace - recompiling - getting the
> answer is less than one minute (and I don't have an especially fast
> machine!). That's my whole point. I never said that debuggers were
> useless, and I certainly happen to use one every now and then. But most
> of the time, I find adding a trace faster, for the kind of program I'm
> writing.

Sounds like we're in violent agreement.  ;-)

> Of course, a great help here is that if you modify a body in Ada, you
> just need to recompile that body...

That's true of many languages.  It's certainly true in C.
It's even true in Java, if you follow the common practise
where "Java interface" corresponds to "Ada spec", and "Java class"
corresponds to "Ada body".

And languages that commonly have incremental compilers
(Lisp, Smalltalk, ...) do even better in this regard.
Not that I'm a big fan of those languages overall...

- Bob

Re: What is wrong with Ada?

[Ed Falis]

Pascal Obry wrote:

> I bet that the total time will be inferior to one year as many errors
> will probably be caught by this second pair of eyes on the project. Is
> there some studies in this direction ? What are the conclusions ?

I don't know about studies, but the XP people have plenty of anecdotal
evidence about the effectiveness of "pair programming" as a lightweight
form of code review.

- Ed

Re: What is wrong with Ada?

[Pascal Obry]

Ed, Georg,

Thanks for your answers. But I was more thinking about being two people
on a project not necessary two behind the screen at the same time. Code
review can be done at any time with the right setup (sending mails for
each check-in for example) it is possible to make code review as
something "normal". Many developers seems to not like somebody looking
at their code, if every piece of code is sent to a dev mailing-list it
changes things, making code more visible by default.

I do think that a single developer on a project is bad for the overall
quality... I'm just looking for so data to backup this idea :)

Well this has nothing to do with Ada, so I'm completely off topic, fell
free to ignore :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: What is wrong with Ada?

[Ludovic Brenta]

Pascal Obry writes:
> Thanks for your answers. But I was more thinking about being two people
> on a project not necessary two behind the screen at the same time. Code
> review can be done at any time with the right setup (sending mails for
> each check-in for example) it is possible to make code review as
> something "normal". Many developers seems to not like somebody looking
> at their code, if every piece of code is sent to a dev mailing-list it
> changes things, making code more visible by default.
>
> I do think that a single developer on a project is bad for the overall
> quality... I'm just looking for so data to backup this idea :)
>
> Well this has nothing to do with Ada, so I'm completely off topic, fell
> free to ignore :)

I agree wholeheartedly.  A few years ago, I would start each day
reviewing my teammates' commits in the version control system, and I
also encouraged them to do likewise.  We caught many latent or actual
bugs even before testing that way.  Furthermore, it allowed us to know
the entire source base intimately, even on those parts we weren't
directly involved in.

Now I work in avionics and we have formal code reviews instead.  They
tend to take place after everything is written, and I miss the
closed-loop feedback I had with daily reviews.

-- 
Ludovic Brenta.

Re: What is wrong with Ada?

[Jeffrey R. Carter]

Pascal Obry wrote:
> 
> Many developers seems to not like somebody looking
> at their code

That's called investing one's ego in one's code. It's a bad sign. People 
who feel strongly that others should not look at their code should not 
be working on your projects.

-- 
Jeff Carter
"Sir Lancelot saves Sir Gallahad from almost certain temptation."
Monty Python & the Holy Grail
69

Re: What is wrong with Ada?

[Ludovic Brenta]

"Jeffrey R. Carter" <jrcarter@acm.org> writes:

> Pascal Obry wrote:
>>
>> Many developers seems to not like somebody looking
>> at their code
>
> That's called investing one's ego in one's code. It's a bad
> sign. People who feel strongly that others should not look at their
> code should not be working on your projects.

Strange; I invest a lot of ego in my code, and I insist that others
read it :)

-- 
Ludovic Brenta.

Re: What is wrong with Ada?

[adaworks]

"Markus E Leypold" <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> 
wrote in message news:awirc4gv13.fsf@hod.lan.m-e-leypold.de...
>
> I think I already answered that. Still, on c.l.a, the myth persists
> that "developers like unsafe languages". In actual reality it's the
> other way round:
>
Unsafe languages like developers?
>
> For one reason or other -- as I explained often
> enough, not related to technical merits of the languages in question
> -- people like other languages, they just happen to be "unsafe".
>
Sort of the way most people are addicted to junk food and would
rather eat something full of fat and sugar than eat their broccoli.

For example, C++ is like the peanut brittle of programming languages.
It might taste sweet, at first.  But then it gets stuck in your teeth.  Finally,
it begins to rot your code unless you brush away the residue.

> (And even that might be questioned, since the big contenders at large
> are (probably in that order) Excel, Php, Perl, Python and not only C
> ... -- Excel and the 3 Ps are not unsafe in the same sense as C/C++
> are).
>
I happen to like Python and I'm using more often now than Ada, for
non-critical code.  It is quick and easy.   However, I would never think
of using it for safety-critical software.    C is an important tool for some
kinds of problems, but it, along with its deformed cousin, is like a box
of "strike anywhere" matches, and needs to be used with great care.

Even Ada needs to be used with care.   Even SPARK needs to be used
with care.  There is no perfect programming language, at present.  While
Ada is better than most, when safety is a consideration, it too has its
weaknesses.   We should be striving for a language design that includes
the best of Ada's design, while avoiding the worst of C++, and moving
along toward the next generation of programming languages.   These
languages, by-the-way, are not Ruby and the like.   They might be
closer to Eiffel, but with a better compilation structure.
>
In any case, we should not be surprised when we use tools (languages)
that are inherently error-prone and get results that are error-dense.  When
someone remarks that the debugger is not necessary in Ada, they are
acknowledging that, well-designed Ada code will not have as many of
the idiotic kinds of errors one finds in C++ code.   However, none of us
is such a good programmer that we don't find it occasionally useful to
have a debugger to help locate the errors that result from our own stupidity.

Richard Riehle 

Re: What is wrong with Ada?

[adaworks]

"Jean-Pierre Rosen" <rosen@adalog.fr> wrote in message 
news:82dgve.spf.ln@hunter.axlog.fr...
>>
> Sorry, but I beg to disagree here. Conceptual bugs are found by reasonning on 
> the source, not with a debugger. Every now and then you may need to check the 
> value of a variable at some point in execution to validate or invalidate an 
> hypothesis, but even there, I find a proper trace message much faster and more 
> precise than using a debugger.
> -- 
I almost always agree with Jean-Pierre.  However, I do recall a project
in Ada written for a MIL-STD 1750A where the debugger was an
integral part of the verification (inspection) process.   Some may recall
the HP 65000 tool that was so useful in tracing, step by step, the execution
of a program while simultaneously presenting a human-readable version
of the underlying executable code.

This is an extreme example, and the criticality of the application was such
that this level of inspection was required for inspection.  It was certainly
tedious, would be unnecessary in most applications, but was probably
the correct decision in this situation.  And, "No"   I would not recommend
this approach to anyone for most software systems -- unless they are looking
for a guaranteed cure for insomnia.

Richard Riehle 

Re: What is wrong with Ada?

[Markus E Leypold]

<adaworks@sbcglobal.net> writes:

> "Markus E Leypold" <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> 
> wrote in message news:awirc4gv13.fsf@hod.lan.m-e-leypold.de...
>>
>> I think I already answered that. Still, on c.l.a, the myth persists
>> that "developers like unsafe languages". In actual reality it's the
>> other way round:
>>
> Unsafe languages like developers?
>>
>> For one reason or other -- as I explained often
>> enough, not related to technical merits of the languages in question
>> -- people like other languages, they just happen to be "unsafe".
>>
> Sort of the way most people are addicted to junk food and would
> rather eat something full of fat and sugar than eat their broccoli.

<...>

> I happen to like Python and I'm using more often now than Ada, for
> non-critical code.  It is quick and easy.   However, I would never think

So perhaps most of the people don't write safety-critical software?
And there is, consider, more than one kind of safety ...

Regards -- Markus

Re: What is wrong with Ada?

[adaworks]

"Pascal Obry" <pascal@obry.net> wrote in message 
news:461E6DD9.6010600@obry.net...
>
> "The only way" for interpreted languages, for compiled languages (as
> said in my previous message) the compiler will detect lot of mistakes.
> So it is not the only way in this case. I'm wondering if you are not
> moving to the troll side!
>
Every program needs to be evaluated in more than one way.  Those
who advocate test-only are off the mark.  Those who depend on a
properly compiled program are way off the mark.   Those who rely
on inspection alone, are certainly missing something.

Ideally, we design the software with the most appropriate methods and
tools to avoid defects.   For most circumstances, but not all, Ada is a
better tool to accomplish this than most other languages.   We can
certainly get better results in this regard from Ada than from an intepreted
language, but that is the old "mixing apples and oranges" issue.   When
comparing Ada, we must compare it to languages that are also compiled.
C++, a language inherently error-prone, is not usually as good as Ada
(with a few very rare exceptions), so we don't expect to be able to
depend on the compiler for as much help as we get from Ada.   This is
also true, to some extent, for Java.

Even so, with all the help we get from the compiler in a well-designed Ada
program, we must also apply some testing regimen and are well-advised to
add an inspection process.    However, it is well-known that neither testing
nor inspection are sufficient for evaluating the correctness of a program.  This
is why compiler errors are still important.   Once again, Ada excels in this
regard for most kinds of design problems.

Some of the examples given, so far, such as the double underbar indicate
a lack of understanding of just what a harsh mistress really is.  The 
fundamental
design goal of Ada is for a language where the maximum number of errors
can be detected by the compiler as early in the development process as
possible.  For the most part, in most circumstances, this actually happens.

Full-path, and total testing are simply out of the question for large software
systems.  Therefore, we need to find ways to priortize the testing process
so we focus on those errors with the greatest probability of occurrence as
well as those with the greatest serverity, should they occur.   A testing
strategy needs to be coupled with a risk management policy.   Risk
management, to be truly effective, needs to be based on recorded experience
of the kinds of defects typical of a domain, an organization, etc.  With some
knowledge of the frequency distribution of errors, we can then develop a
sensible testing strategy.   For example, if we know that a certain programmer
always makes mistakes of a certain kind, we can focus more testing on his
programs.  If we know that a certain category of mistakes occurs at a
given stage of projects of the kind we are developing, we can create a
strategy for evaluating software at that stage.

Strategies for testing are important since there is no way to test all the paths
of any program.   Design strategies that take advantage of the error reporting
from a compiler are important so we will not have to test those errors that
are reported.   Inspection strategies are essential for identifying the kind of
errors that are most easily spotted by a well-trained human.     All of these
are important, even when using Ada.

Richard Riehle

Re: What is wrong with Ada?

[adaworks]

"Ed Falis" <falis@verizon.net> wrote in message 
news:PM00042E503F06FEA3@tilopa.unknown.dom...
>
> I don't know about studies, but the XP people have plenty of anecdotal
> evidence about the effectiveness of "pair programming" as a lightweight
> form of code review.
>
I recall a real-time, non-stop, program that sometimes needed to be
fixed at odd hours of the night.   The rule was that no patch was allowed
to be entered into the program unless there were at least two programmers
working on it at the same time and both agreeing that it was OK.

Two, of course, is not a really good number.  We can learn some lessons
from the Byzantine General's Problem, I suppose.

Richard Riehle 

Re: What is wrong with Ada?

[adaworks]

"Markus E Leypold" <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> 
wrote in message
>
> So perhaps most of the people don't write safety-critical software?
> And there is, consider, more than one kind of safety ...
>
Granted.   I am not a one-language person.   It is always a matter
of choosing the right tool for the right job.

I was once asked by a three-star general whether he should be
converting all his Fortran code to Ada, as many on his staff wanted
to do.  I gave him my opinion as, "No."   Old code that has worked
a long time is almost always better than new code that has not yet
proven itself in the field, regardless of what language is used.

In his environment, there were a lot of programs that needed to be
written other than translating the Fortran.  It seemed to me that those
who wanted to translate Fortran were simply avoiding the new problems
that were waiting to be solved, and that could best be solved in Ada.

A large bank was persuaded to do a bunch of projects in Java.   It was
a stupid decision, and that soon became apparent.  All the other code
in the bank was in COBOL.  My advice.  Instead of using Java or
C++, or even Ada, train the programmers to use Object-oriented
COBOL.  Java is a terrible choice for business data processing where
there is a lot of accounting activity.  C++ is probably worse.   Ada
could work because of the built-in accounting-oriented data types,
but that would also a wrong choice for this environment.

We live in a multi-language world.  Perhaps it would be better if we
didn't.   However, there does not exist, at present, any single language
that is superior for every kind of programming problem in every context.
One thing I like about Ada that is not as well-formed in other languages
is the Annex C, Interfacing to Other Languages facility.   Ada is more
hospitable to other programming languages than most of the alternatives.

Richard Riehle

Re: What is wrong with Ada?

[Simon Wright]

<adaworks@sbcglobal.net> writes:

> For example, if we know that a certain programmer always makes
> mistakes of a certain kind, we can focus more testing on his
> programs.

Better perhaps to focus more review on the programs and more training
on the programmer!

Re: What is wrong with Ada?

[AJAskey]

Most has been hit in other's posts, but here is my take:

I've used Ada since 1993.  It is the best language for developing real-
time and simulation apps I've found.  Ada compilers have never been
freely available to the masses.  In the 90s, GNAT was available but
there was no internet to grab it and go.  It could have been
downloaded and was available in CD form.  But no one who didn't
already know about it would use it.  Today anyone can grab a free
version of Java or C++ and be developing in an hour.  There are many
other internet/scripting languages available for free.  There are free
tools everywhere.  There is free support available in groups (such as
this).

In 1998 the DoD decide to stop supporting Ada.  It is still alive (I
use it today) but finding and trying tools is a complete pain in the
butt.  Adacore and Aonix require forms to be filled out for a trial.
I needed to get approval/money/signatures within my company just to
try the software.  Then I needed to schedule time to try the software
(I still have not found the time to try Aonix with Eclipse).  Then I
need to provide evidence I uninstalled the software or my company will
be charged.  I think the Ada vendors underestimate the effort required
by companies to just evaluate their product.

>From a marketing perspective, Ada vendors make it nearly impossible
for a company to buy their product vs. Java and C++ vendors who
provide no barriers to entry.  Because of this, no significant
contracts I see coming out of the DoD even want to consider Ada.  The
reluctance for Ada at the corporate level (at least in DoD and other
similar agencies) has nothing to do with the quality of the products
or even the cost.  The reluctance is based on a repeated history
(anecdote after anecdote) of requests for time/money to evaluate an
Ada tool.  Every department/project that wants to use Ada must go
through this.  Most just ignore the Ada option the other options are
well understood and easy to evaluate.  Everyone in the product
development business can see this and ignores Ada as a long term
solution to big projects.  I would guess that the only buyers of Ada
compilers are those with legacy projects who are moving away for
Rational Ada because IBM does not support that well anymore.

Andy

Re: What is wrong with Ada?

[jimmaureenrogers]

On Apr 21, 6:56 am, AJAskey <Aske...@gmail.com> wrote:
> Most has been hit in other's posts, but here is my take:
>
> I've used Ada since 1993.  It is the best language for developing real-
> time and simulation apps I've found.  Ada compilers have never been
> freely available to the masses.  In the 90s, GNAT was available but
> there was no internet to grab it and go.  It could have been
> downloaded and was available in CD form.  But no one who didn't
> already know about it would use it.  Today anyone can grab a free
> version of Java or C++ and be developing in an hour.  There are many
> other internet/scripting languages available for free.  There are free
> tools everywhere.  There is free support available in groups (such as
> this).
>

I do not know which planet you live on. I started downloading GNAT
in 1994 and have been using it on my home machine since then.
The internet was available to large parts of the world in the 1990's.
For part of that time you needed to use a dial-up connection, but
availability did exist.

> In 1998 the DoD decide to stop supporting Ada.  It is still alive (I
> use it today) but finding and trying tools is a complete pain in the
> butt.  Adacore and Aonix require forms to be filled out for a trial.

What is the procedure for obtaining tools for other languages?
Can you obtain trial version of JUnit without filling out some form?
Can you obtain trial versions of any Microsoft product at all?

> I needed to get approval/money/signatures within my company just to
> try the software.  Then I needed to schedule time to try the software
> (I still have not found the time to try Aonix with Eclipse).  Then I
> need to provide evidence I uninstalled the software or my company will
> be charged.  I think the Ada vendors underestimate the effort required
> by companies to just evaluate their product.
>
> >From a marketing perspective, Ada vendors make it nearly impossible
>
> for a company to buy their product vs. Java and C++ vendors who
> provide no barriers to entry.  Because of this, no significant
> contracts I see coming out of the DoD even want to consider Ada.  The
> reluctance for Ada at the corporate level (at least in DoD and other
> similar agencies) has nothing to do with the quality of the products
> or even the cost.  The reluctance is based on a repeated history
> (anecdote after anecdote) of requests for time/money to evaluate an
> Ada tool.  Every department/project that wants to use Ada must go
> through this.  Most just ignore the Ada option the other options are
> well understood and easy to evaluate.  Everyone in the product
> development business can see this and ignores Ada as a long term
> solution to big projects.  I would guess that the only buyers of Ada
> compilers are those with legacy projects who are moving away for
> Rational Ada because IBM does not support that well anymore.

This is a rather strange posting. Most large companies I know of
have little reluctance buying additional licenses for a product
already
shown to be effective in a different project or department. A contract
for one project puts the vendor on the approved vendor list. It is not
difficult to buy products from approved vendors.

Jim Rogers

Re: What is wrong with Ada?

[Markus E Leypold]

Simon Wright <simon.j.wright@mac.com> writes:

> <adaworks@sbcglobal.net> writes:
>
>> For example, if we know that a certain programmer always makes
>> mistakes of a certain kind, we can focus more testing on his
>> programs.
>
> Better perhaps to focus more review on the programs and more training
> on the programmer!

Absolutely. I'd be cautious with singling out individual
programmers. Whereas it's perhaps a good idea to have some kind of
measures in place for people who always produce fatal mistakes
(e.g. "wouldn't you be hapier with ..."), I'd be wary to publish
programmer ratings or make it too well known that such a process
exists. Such things have a tendency to end in witch hunts and being
abused in infights. In another part of this thread someone mentioned
that programmers shouldn't put their "ego in their code". Actually
they have some stake in their code anyway and if ranking programmers
on code quality is too much emphasized the programmers will find their
career dependent on their code quality (or more realistic: on the way
their code is percieved in the group). That will give them a really
strong incentive to camouflage what really happens and make mistakes
look like other peoples mistake or argue that they are other peoples
mistakes. The organisation will get bogged down in a lot of "ass
covering" and infighting.

Not for nothing formal reviews are _formal_, not meaning they use
formal methods, but meaning that the whole review is strictly
ritualized in a way that makes it easy not to take personally any
finding in that review. It is, to a certain extend, important, to
protect your programmers egos (against the impact of your critique as
well as against their fellows: There are always people in a team which
engage in a game of one-up-manship and one shouldn't give that any
additional opportunities).

Regards -- Markus

Re: What is wrong with Ada?

[AJAskey]

On Apr 21, 9:50 am, "jimmaureenrog...@worldnet.att.net"
<jimmaureenrog...@worldnet.att.net> wrote:

> I do not know which planet you live on. I started downloading GNAT
> in 1994 and have been using it on my home machine since then.

Sure the geeks could download stuff in 1994.  The average person did
not have this opportunity until the late 1990s - after the DoD
shutdown the Ada funding.  Google ADA and see all the sites that have
not been updated since 1998.  Ada need to be marketed to program
managers, not developers.  In 2000, there were plenty of advocates in
the developer community.  As time goes on, PMs know less and less
about Ada.

>
> What is the procedure for obtaining tools for other languages?
> Can you obtain trial version of JUnit without filling out some form?
> Can you obtain trial versions of any Microsoft product at all?
>

We downloaded Java for free with free Netbeans and Eclipse.  If we
need a "tool" then we do need to go through the evaluation process.
But the problem is that Ada is the "base" and not a "tool".  No one is
going to pay for entry into a development language when others are
free.  People will pay to enhance the tool.  But paying to evaluate
something on a small scale for a year isn't going to happen on a
regular basis.


>
> This is a rather strange posting. Most large companies I know of
> have little reluctance buying additional licenses for a product
> already
> shown to be effective in a different project or department. A contract
> for one project puts the vendor on the approved vendor list. It is not
> difficult to buy products from approved vendors.
>
> Jim Rogers

I agree that follow license are easy to get. But few departments in my
company use AdaCore or Aonix at this point.  Some do elsewhere in the
country, I'm sure, but I have no access to them.  As I said, all new
projects are using Java/C++ and other new technologies.  The gov't is
constantly asking how much it will cost to go move from Ada on an
existing project to Java/C++.  IBM/Rational, AdaCore, Aonix tools are
user-friendly - but they have no friends with the people who count -
the people with the money.

Andy

Re: What is wrong with Ada?

[Markus E Leypold]

AJAskey <AskeyAJ@gmail.com> writes:

> On Apr 21, 9:50 am, "jimmaureenrog...@worldnet.att.net"
> <jimmaureenrog...@worldnet.att.net> wrote:
>
>> I do not know which planet you live on. I started downloading GNAT
>> in 1994 and have been using it on my home machine since then.
>
> Sure the geeks could download stuff in 1994.  The average person did
> not have this opportunity until the late 1990s - after the DoD
> shutdown the Ada funding.  Google ADA and see all the sites that have
> not been updated since 1998.  Ada need to be marketed to program

Absolutely. Just one more example

The FSF ftp site has README

   ftp://ftp.gnu.org/pub/gnu/gnat.README

referring one to cs.nyu.edu/pub/gnat -- a location which once carried
gnat 3.15p, but where all actual Gnat binaries have been removed some
years ago (AFAIK even before there was a GPL Gnat by AdaCore when
3.15p was the latest and only public release).

The FSF free software directory links to http://www.gnat.com/ and
ttps://libre2.adacore.com/ -- sites carrying the GPL-only version of
Gnat, without mentioning the that there is another version of Gnat
integrated in the Gcc source tree, the so called FSF-version of Gnat,
which has a linking exception for the run time.

Isn't that confusing? :-/

Regards -- Markus

Re: What is wrong with Ada?

[Markus E Leypold]

AJAskey <AskeyAJ@gmail.com> writes:

>> What is the procedure for obtaining tools for other languages?
>> Can you obtain trial version of JUnit without filling out some form?
>> Can you obtain trial versions of any Microsoft product at all?
>>
>
> We downloaded Java for free with free Netbeans and Eclipse.  If we
> need a "tool" then we do need to go through the evaluation process.
> But the problem is that Ada is the "base" and not a "tool".  No one is
> going to pay for entry into a development language when others are
> free.  

Oh, I would. Only not 5 developer seats where I need 1 for maintenance
in the long run. Using Ada under those licensing schemes is a all or
nothing proposition: Either you really go for it, do large or many
projects in Ada with maintenance and all and perhaps more than one
developer -- or you don't, because you pay the entry cost anyway. But
there is no way to start slowly (say 1 small project a time) and after
the technology is proven (in your business / corporation) expand it,

> People will pay to enhance the tool.  But paying to evaluate
> something on a small scale for a year isn't going to happen on a
> regular basis.

Well -- it's not done with evaluating for a year: If during this year
you produce anything useful you probably would have to maintain it for
the next years. Something you need a working compiler for.

Regards -- Markus

Re: What is wrong with Ada?

[adaworks]

"Simon Wright" <simon.j.wright@mac.com> wrote in message 
news:m2hcradpkt.fsf@mac.com...
> <adaworks@sbcglobal.net> writes:
>
>> For example, if we know that a certain programmer always makes
>> mistakes of a certain kind, we can focus more testing on his
>> programs.
>
> Better perhaps to focus more review on the programs and more training
> on the programmer!
>
Programmers are still people.   And people are not interchangeable
parts.  They come to us with a variety of skills, aptitudes, and
biases.   While training is an important part of any organization's
activities, we still have some people who are better at one kind of
thing than at another.

For example, we sometimes have programs that require a fair amount
of mathematics.  In an organization, we might have an excellent programming
technician, one who knows the ins and outs of a given language, operating
system, and all the tools.   That same person may not be quite as good in
mathematics as some of our less skilled programmers.

Is it easier to teach good programming to mathematicians or teach mathematics
to programmers?    No one is an expert in everything, and no one can be.  We,
as project managers need to manage people with insufficient skills in one area
or another.   In fact, one of the challenges of management is always the 
management
of ineffective people -- those who might be superior in one area, but not 
another.

With knowledge of the strengths and weaknesses of our team members, we can
make a pretty good guess at what kinds of mistakes might be made.

Sometimes, when a new person comes on the team, we know in advance what the
typical kinds of mistakes are made in our application domain by newcomers.  The
test plan can be focused using that knowledge.

A test plan that anticipates where errors are most likely to occur can go a long 
way
toward improving the testing process, as well as improving the development 
process.
However, for this to work, it is essential that we keep good records -- not just 
for
one project, but for all the projects in our application domain.

A key part of any conventional engineering process is failure prevention.   It 
is not
enough to simply make things (e.g., programs) work.   We must also design to
avoid failure, ensure that failure can be corrected, and to improve on failing 
designs
in future projects.   Failure occurs due to various kinds of stress over 
weakness.
Every design has its stress and its weakness.  Anticipating where there will be 
stress
and corresponding weakness (in people or systems) is one of our principal
responsibilities as engineers.

There are no perfect programmers.  There is no perfect language.  Knowing the
weaknesses helps us prevent stress from turning into failure.

Richard Riehle 

Re: What is wrong with Ada?

[adaworks]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:krrspgzz88g4$.15lzsnhxml4j.dlg@40tude.net...
>
> It is because SW engineering is not engineering. And that is because CS is
> not much science. It rather sways between applied mathematics and "stamp
> collecting."
>
Dmitry, you are one of the contributors to this forum for whom
I have great respect.   On this point I must, if not outright disagree,
then clarify.

The fact that most programmers are not engineers is certainly correct.
However, this does not mean that those involved in software practice
cannot apply engineering principles, methods, and ideas to the development
of software.

There are clearly some points in software practice where we fall short of
being able to apply engineering.   On the other hand, there are a lot of
opportunities to take advantage of what we know about engineering.

Engineering is the largely about achieving predictable results and avoiding
failure.   It requires that we leverage knowledge from science, mathematics,
and previous engineering experience.  It also requires that we are able to
reason about and reconcile the trade-offs between conflicting constraints:
physical world constraints, logical constraints, economic constraints, etc.

In the 1970's and later in the 1980's Kenneth Kolence published his works
on "software physics."  This work, while good in many ways, also helps us
to understand the limitations of software from the perspective of natural
forces.   Natural forces are inherent in most engineering disciplines.

Kolence's work also opens the door to understanding with regard to what
we need in the way of a physics of software, if such a physics is ever to make
sense.   Physics is about relationships in behavior between different things.
We have the same issues in software.  But there are none of the inherent
constraints that the natural world imposes.

As software engineers, we need to define, create, and impose our own
constraints.   That is part of the engineering responsibility for a software
engineer.  At the component level, we have Design by Contract (Bertrand
Meyer), and other attempts at doing this kind of thing.   We are a long
way off from achieving the level of capability we eventually will require.

Nevertheless, there is a lot of good engineering practice in place for software,
even though most of it is ignored by programmers.  One reason I like Ada is
that it is designed so we can introduce some engineering into our designs.  Ada
is not yet at the place where we can do engineering at the level we could in a
physical process, but it is a step in the right direction.

Future software development tools will extend on those we now have and make
engineeering of software even more feasible.   Meanwhile, we have many options
for the application of engineering in the creation of software.  The fact that
we do not use them is the sad thing.

Finally, the shortcomings of current engineering practice simply mean that we
need to work harder to develop improved approaches to engineeering software
solutions in the future.

Richard Riehle 

Re: What is wrong with Ada?

[Dmitry A. Kazakov]

On Sat, 21 Apr 2007 18:50:40 GMT, adaworks@sbcglobal.net wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:krrspgzz88g4$.15lzsnhxml4j.dlg@40tude.net...
>>
>> It is because SW engineering is not engineering. And that is because CS is
>> not much science. It rather sways between applied mathematics and "stamp
>> collecting."

[...]
> Engineering is the largely about achieving predictable results and avoiding
> failure.   It requires that we leverage knowledge from science, mathematics,
> and previous engineering experience.  It also requires that we are able to
> reason about and reconcile the trade-offs between conflicting constraints:
> physical world constraints, logical constraints, economic constraints, etc.
> 
> In the 1970's and later in the 1980's Kenneth Kolence published his works
> on "software physics."  This work, while good in many ways, also helps us
> to understand the limitations of software from the perspective of natural
> forces.   Natural forces are inherent in most engineering disciplines.
> 
> Kolence's work also opens the door to understanding with regard to what
> we need in the way of a physics of software, if such a physics is ever to make
> sense.   Physics is about relationships in behavior between different things.
> We have the same issues in software.  But there are none of the inherent
> constraints that the natural world imposes.

There are two layers in that. One is the physics of the computing substrate
(the machine and the languages of) another is the "physics" of the groups
of programmers using it. We have much more freedom in software developing
than in other disciplines because we can change the first.

> As software engineers, we need to define, create, and impose our own
> constraints.   That is part of the engineering responsibility for a software
> engineer.  At the component level, we have Design by Contract (Bertrand
> Meyer), and other attempts at doing this kind of thing.   We are a long
> way off from achieving the level of capability we eventually will require.

Yes, but I think this not special to engineering. It is rather a property
of art. In art where the substrate is a subject of permanent changes like
in software developing, a truly great art can arise only when the artists
impose some constraints on themselves which take form of a style, an
aesthetic movement. These constraints are artificial, while in engineering
the constraints are objective and imposed by the physics and economics. It
is a long way before us, to the point where things like DbC would become a
physical constraint. This time will definitely come as the complexity will
grow. That will be the day SW will become engineering.

[...]
> Finally, the shortcomings of current engineering practice simply mean that we
> need to work harder to develop improved approaches to engineeering software
> solutions in the future.

Sorry for spoiling the party (:-)), but unfortunately this is not a subject
of attitude. There exist scientific and economical reasons which prevent us
from that. As for scientific reasons, it is obvious that we cannot engineer
large and complex systems, we don't know how to, even in Ada. Costs,
schedules, quality, maintenance, everything becomes quite unpredictable too
quickly. What is more disturbing than this, is that there is no economical
understanding of this problem. It seems that poor software sells better, in
fact, much better. The bad news is that this will not change until average
complexity will reach certain level, to make most of the projects
unmanageable. Some major disasters will happen forcing the government and
courts to intervene. Not before.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: What is wrong with Ada?

[jimmaureenrogers]

On Apr 21, 8:46 am, AJAskey <Aske...@gmail.com> wrote:
> On Apr 21, 9:50 am, "jimmaureenrog...@worldnet.att.net"
>
> <jimmaureenrog...@worldnet.att.net> wrote:
> > I do not know which planet you live on. I started downloading GNAT
> > in 1994 and have been using it on my home machine since then.
>
> Sure the geeks could download stuff in 1994.  The average person did
> not have this opportunity until the late 1990s - after the DoD
> shutdown the Ada funding.  Google ADA and see all the sites that have
> not been updated since 1998.  Ada need to be marketed to program
> managers, not developers.  In 2000, there were plenty of advocates in
> the developer community.  As time goes on, PMs know less and less
> about Ada.
>
>

The average person never learned programming. I do not know who you
are referring to when you refer to "the average person".

There were never plenty of Ada advocates. Ada was never a fad
language.
Several years ago I taught Java to an investment firm. All their
legacy
code was written in COBOL. The Vice President in charge of information
systems announced, without consulting any developers, that the company
was moving all its programming to Java. During the class one of the
students asked me what kind of performance improvement they should
expect from Java over COBOL. I told them, if they were lucky they
would
see a -30% increase. Yes, that is a negative increase. Java was not
cheaper than COBOL for this organization. They currently had all the
tools and training needed to support COBOL. According to the students
the Vice President made the change after talking with some of his
friends at his country club. Everybody else was using Java. He felt
embarrassed that his organization still used COBOL.

Programming language choices are seldom made based upon either
economics or technical merit. Managers choose programming
languages because it is safe to run with the herd.

> We downloaded Java for free with free Netbeans and Eclipse.  If we
> need a "tool" then we do need to go through the evaluation process.
> But the problem is that Ada is the "base" and not a "tool".  No one is
> going to pay for entry into a development language when others are
> free.  People will pay to enhance the tool.  But paying to evaluate
> something on a small scale for a year isn't going to happen on a
> regular basis.

Try downloading C++ for free with the equivalent of Netbeans. Eclipse
is a wash for all its supported languages. Did your application need
to do anything Java cannot do by itself? For instance, did it need to
interface with any existing libraries written in another language?
If so, you needed another language such as C or C++, as well as
somebody who understands how to write a Java Native Interface
for the foreign code. This means acquiring tools and training in
at least two languages.

What is the cost of tools and training for any specific language?
How does that cost compare to the development and testing costs
for production code? The tools and training costs are typically less
than 1% of the development costs for a project producing over
1,000,000 SLOC.

One might well ask what are the different testing costs for
different languages. Many people would be surprised by the
question. As mentioned in another thread, I am the software
safety engineer on an extremely safety critical software
project. The management chose C++ as the primary
language for development of new code for this project.
The decision was made before I was hired. For C++ to
be as safe as Ada, you need to specify a very strict
subset of C++. One example of such a subset is the
JSF C++ Avionics Coding Standard. It contains 221
rules. Approximately 200 of those rules are specification
of a C++ subset. The cost of verifying 221 rules against
2,000,000 lines of code is extremely high. Some of the
rules checking can be automated. Some cannot. None
of those costs (manual checking and creation of
automated checkers) would have been encountered if
management had chosen Ada. None of those costs
were considered when the decision was made.

Jim Rogers

Re: What is wrong with Ada?

[Markus E Leypold]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

> On 21 Apr 2007 14:42:32 -0700, "jimmaureenrogers@worldnet.att.net"
> <jimmaureenrogers@worldnet.att.net> declaimed the following in
> comp.lang.ada:
>
>> 
>> The average person never learned programming. I do not know who you
>> are referring to when you refer to "the average person".
>>
> 	Aye... and the "geeks" had FTP, Gopher, and Archie in the mid-80s
> for downloads...

Complete nonsense. I think I qualified for a geek: But being young,
living in a village hand having not so well todo parents at that
moment, the only thing I could afford at the time was a C64 (expensive
enough) and later a 286 AT. Online connection was well out of question
(too expensive) and still rather well controlled when I went to
university (well, in the first years). So sorry ...

Regards -- Markus

Re: What is wrong with Ada?

[adaworks]

"Markus E Leypold" <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> 
wrote in message news:r14pn9g6fo.fsf@hod.lan.m-e-leypold.de...
>
> Simon Wright <simon.j.wright@mac.com> writes:
>
>> <adaworks@sbcglobal.net> writes:
>>
>>> For example, if we know that a certain programmer always makes
>>> mistakes of a certain kind, we can focus more testing on his
>>> programs.
>>
>> Better perhaps to focus more review on the programs and more training
>> on the programmer!
>
> Absolutely. I'd be cautious with singling out individual
> programmers.
>
Not really.   We need to do exactly that so there is
an increased level of accountability.   We do that for
every other kind of job, including other engineers.

>Whereas it's perhaps a good idea to have some kind of
> measures in place for people who always produce fatal mistakes
> (e.g. "wouldn't you be hapier with ..."), I'd be wary to publish
> programmer ratings or make it too well known that such a process
> exists.
Rating systems are not a bad thing.  Also, it is not just about those
who always produce fatal mistakes.   Rather, it is recognition that
different members of the team have different levels of skill, not only
with regard to programming, but in other things as well.

The best of programmers are not necessarily the best in everything
else.  And laying down code is only a small part of the software development
process.

> Such things have a tendency to end in witch hunts and being
> abused in infights. In another part of this thread someone mentioned
> that programmers shouldn't put their "ego in their code". Actually
> they have some stake in their code anyway and if ranking programmers
> on code quality is too much emphasized the programmers will find their
> career dependent on their code quality
>
And that is a bad thing because ... ?

> That will give them a really
> strong incentive to camouflage what really happens and make mistakes
> look like other peoples mistake or argue that they are other peoples
> mistakes. The organisation will get bogged down in a lot of "ass
> covering" and infighting.
>
Any programmer who resorts to this kind of deception needs to be
fired, and quickly.   We all make mistakes.  We need to own up to
those mistakes.   I am more inclined to fire a programmer who tries
to blame others than one who acknowledges a mistake and works
on correcting it.
>
We all know how hard it is to get programs right.   We need to work
together to make that happen.   When some member of the team gets
sneaky about this, we want him/her gone as soon as possible.
>
When we discover a weakness in one of the team members, we can make
an effort to correct it.   The reality is that every team member has some
weaknesses.  The trick is to identify the weaknesses and strengths and
assign work accordingly.   But accountability is an essential part of any
team project.   Without it, no one is safe.   Without it, no project can
be assured of the desired quality.

Richard Riehle

Re: What is wrong with Ada?

[adaworks]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcctzvfxddx.fsf@shell01.TheWorld.com...
>
> That's true of many languages.  It's certainly true in C.
> It's even true in Java, if you follow the common practise
> where "Java interface" corresponds to "Ada spec", and "Java class"
> corresponds to "Ada body".
>
The correspondence, with C and Java, is rather weak compared to
the equivalent constructs in Ada.

Richard Riehle 

Re: What is wrong with Ada?

[adaworks]

"kevin cline" <kevin.cline@gmail.com> wrote in message 
news:1176332730.826176.286450@y5g2000hsa.googlegroups.com...
On Apr 10, 11:31 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Tue, 10 Apr 2007 15:59:27 GMT, Jeffrey R. Carter wrote:
>
> It is because SW engineering is not engineering.

kc>>You are right about that.  Other engineering disciplines apply
kc>>physical laws to the construction of human artifacts.  There are no
kc>>physical laws governing software.  Were it not for the limitations of
kc>>human intellect, we could instantaneously produce correct, optimal
kc>>machine code to meet any need.  Software engineering attempts to
kc>>define practices for developing reliable software given our limited
kc>>abilities.  It is a social science.

This is an outdated view of engineering.   It is certainly an outdated view
of software engineeering.    It is true that ordinary programming is usually
absent any engineering,    But there are many engineering practices can,
be applied in the design and construction of software.

Engineering was once restricted to the natural world governed by physical
laws.   For many engineers, this is still their parochial view of the field. 
But
engineering continues to evolve, and the meaning of engineering evolves too.

I have posted other comments in this thread about engineering software.  I
will not repeat them here.  But anyone who thinks that software and engineering
are incompatible is simply not keeping up with the progress in the field or
either software or in the field of engineering.

Richard Riehle 

Re: What is wrong with Ada?

[Dmitry A. Kazakov]

On Sun, 22 Apr 2007 00:25:29 -0800, adaworks@sbcglobal.net wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:4154m07w8547.w6599n4zv086.dlg@40tude.net...
>> On Sat, 21 Apr 2007 18:50:40 GMT, adaworks@sbcglobal.net wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:krrspgzz88g4$.15lzsnhxml4j.dlg@40tude.net...
>>>>
>>>> It is because SW engineering is not engineering. And that is because CS is
>>>> not much science. It rather sways between applied mathematics and "stamp
>>>> collecting."
>>
> The "groups of programmers" is not a factor when
> we think of engineering. The freedom programmers have is one of the
> things that needs to be constrained first.

Absolutely.

> We need to give the programmers
> less freedom, not more. This requires an entirely new model for constraints
> than we have now.

Yup, replaceable parts, an outsourcing dream, take five today, three
tomorrow... (:-)) This model is not new, it is centuries old. If it does
not work now, it will later.

The evolution cycle of a human related to the given kind of occupation is:

artist/artisan/mage -> scientist -> engineer -> conveyor -> lumpen

> The constraints of physics are always with us. The fact that we ignore them
> in designing software is not to our credit.

Certainly, but we have to fight against other "physical" constraints which
override the former. It is, because it has to be this way under the
conditions we have. The point is that we can do very little with that,
because the society is unaware of the physics you are talking about.
Otherwise, to give just one example, no-liability licenses were long
illegal.

> What we fail to do in software is benefit from experience. Each project seems to be
> a greenfield effort, perhaps benefitting from the experience of the individual
> programmer, but not benefitting from the collected experience of past 
> engineering efforts.

Because benefiting can happen only as a cognitive process in the society.
The result of that would be a science and then a technology. As long as
this reflection stops at the level of individuals it is not engineering,
but art/artisanship.

> We can agree that programming, as currently practiced, is not an engineering
> effort.   Most programmers have no knowledge and little training in any 
> engineering discipline. And those with engineerign education have somehow been corrupted 
> by the very learning of a programming language.  Somehow, as soon as they learn 
> to write computer programs, in any language, they forget everything they knew about
> engineering.

Exactly, because there is no engineering independent on the science it
applies. They didn't forget anything, because there was nothing to forget.
What they had learnt had nothing to do with SW engineering, except than
common interdisciplinary hand-waving.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: What is wrong with Ada?

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 15 Apr 2007 18:01:10 +0200, Markus E Leypold wrote:
>
>> Now I'd like you to close this loophole for arbitrary hand waving and
>> define NON-TRIVIAL in a way suitable to you purposes (but keep it
>> convincing, still -- defining it to FALSE won't wash with me) and
>> perhaps try to prove the central assertion above.
>
> OK, here is a formalization of "non-trivial." Let me use a more or less
> standard notation:
>
> IN is the set of input states (the language over a finite alphabet A)
> S is the set of states
> s1 is the initial state
> T : S x A -> S is the transition function
> OUT = the set of output states (a subset of S, which we don't care)
>
> def: Closure of T
> ----------------------
> Let a=(a' a'' a''' a'''' ... a*) be a finite input from IN.
>
>    P(a)=T(a*, ... T(a''', T(a'', T(a', s1))))
>
> Informally P(a) is the state to which a would bring the machine.
>
>    P : IN -> S
>
> def: Equivalent input states (strings)
> ---------------------------------------------
> a, b of IN are called equivalent iff P(a)=P(b).
>
> Let's denote non-equivalent states as a#b
>
> (P was defined on finite strings of IN. Defining it in some reasonable way
> for infinite cases would require efforts, which I don't want to run into.)
>
> def: Non-trivial input (language)
> --------------------------------------
> IN is non-trivial iff for any finite subset {a1, a2, a3,..., aN} of IN
> there exits an input string b in IN such that forall i=1..N b#ai.
>
> From this definition immediately follows that any machine handling
> non-trivial input will necessarily have infinite S.
>
> A classical example
>
> ab
> aabb
> aaabbb
> aaaabbbb
> ...
>
> can serve as one of non-trivial input.
>
> Other three I have mentioned in my previous posts: counting integers,
> recognizing irrational numbers, summation of infinite series 1-1+1-1+1...
> (aka Tompson's lamp).
>
> P.S. This does not apply to Robert's example, because he considered a set
> of machines with individual machines parametrized by some number which
> influences the number of states.

You don't feel the need to justify the use of "trivial" for any
actually existing program?

Regards -- Markus

Re: What is wrong with Ada?

[Brian May]

>>>>> "adaworks" == adaworks  <adaworks@sbcglobal.net> writes:

    >> That will give them a really strong incentive to camouflage
    >> what really happens and make mistakes look like other peoples
    >> mistake or argue that they are other peoples mistakes. The
    >> organisation will get bogged down in a lot of "ass covering"
    >> and infighting.
    >> 
    adaworks> Any programmer who resorts to this kind of deception
    adaworks> needs to be fired, and quickly.  We all make mistakes.
    adaworks> We need to own up to those mistakes.  I am more inclined
    adaworks> to fire a programmer who tries to blame others than one
    adaworks> who acknowledges a mistake and works on correcting it.

This only works if management understands the problem. If your
relationship with management is strained, pointing out problems with
other programmers (whether deliberate or accidental issues that
regularly occur) can make you look like the bad programmer who is
blaming others. In this case in might be best just to leave the job.

In previous job I frequently had my commits reverted. One such
occasion, I asked the offender who initially argued he hadn't reverted
anything. I suggested "maybe you did an update with the file still
loaded in the editor". "No I didn't! Besides Subversion would take
care of that!". I reverted the previous revert after extracting the
changes that had been reverted from other changes that were also
committed in the same revision.

This was eventually followed by "your change broke my code so I
reverted it again". Finally! We come to the real reason. Another piece
of code was using the a function in a way that I never intended, so my
change broke it.

Whether these issues are minor issues or major show stoppers depends
on the culture of the company. Unfortunately, in this case, management
didn't care for quality code, they just wanted results. Documenting
code was seen as wasting time. Management was of the view that bugs
where going to occur anyway, and there was no point trying to do
anything about it.

As a result other programmers started adding code to my well defined
functions and classes to handle cases that these functions and classes
were never intended to handle. Eventually even I gradually forgot what
my original intentions were, so started doing the same thing myself. I
couldn't just look at my code to find out either as I wasn't sure
which parts of the code I originally wrote and which parts where
hacked in latter (and exploring subversion would have taken too long).

Not that my original design for these functions and classes were that
good anyway, they were based on existing concepts at the time which
had accumulated over the years.

It was pointless trying to argue that the code would be a lot cleaner
and more maintainable if we did a complete redesign followed by a
complete rewrite - we were too busy adding more features - so I left.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: What is wrong with Ada?

[Brian May]

>>>>> "Markus" == Markus E Leypold <Markus> writes:

    Markus> The FSF ftp site has README

    Markus>    ftp://ftp.gnu.org/pub/gnu/gnat.README

A feature of the Internet is out-of-date information ;-).

We almost lost a client once because of an obscure out-of-date webpage
on our website - unfortunately the client assumed the details were
accurate and up-to-date without talking to us. We only found out about
the problem by accident when casually talking to the client.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: What is wrong with Ada?

[Justin Gombos]

On 2007-04-10, Pascal Obry <pascal@obry.net> wrote:
> Jeffrey R. Carter a �crit :
>
> Agreed 100%. Another way to put it, let me ask : What's wrong with
> developers ? Why do they like unsafe languages ? Why do they like
> fighting a language all the time ? Why do they like unreadable code
> ?  Why do they like to play with a debugger ? Why do they like to
> play Sherlock Holmes during hours to look for a bug ? Here are the
> real questions to me, again nothing wrong with Ada to me !

It fits the personality profile of C.S. folk.  The enjoyment of
solving technical puzzles is what brings so many of them to this
career.  The discipline that Ada requires is at odds with the
immediate gratification that coders get when they skip the careful
planning part of the task to get right to the "fun stuff."

Adaists are more stimulated by the deferred gratification of
overseeing the careful construction of their gold-plated masterpiece,
and they're driven by the absense of bug reports, maintainability, and
the reduced impact of late requirements changes.

I also think Adaists are an evolutionary step beyond those who program
dangerously.  Immediate gratification developers have the potential to
become Adaists after they get worn out by all the negative side
effects of dangerous languages and haphazard techniques.  And then
there are some who never have an urge to migrate toward sane
development.  

Then there are the Adaists who are only in it for the illusion of
quality work or cool projects, and avoid the strong typing, and
circumvent language features that make Ada code robust.  These are the
singularly most dangerous developers, because they get in on safety
critical projects only knowing Ada syntax (not Ada principles).  Their
dangerous impact is then strengthened by short-sighted bean counters
who believe they're saving the project money with shortcuts (like
avoiding private types).

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: What is wrong with Ada?

[Dmitry A. Kazakov]

On Sun, 22 Apr 2007 23:50:52 +0200, Markus E Leypold wrote:

> You don't feel the need to justify the use of "trivial" for any
> actually existing program?

Any actually existing program can be expressed with single natural number. 

Moreover, all programs which were ever written, as well as all ones which
*actually* will ever be, all together, again could be characterized by
another natural number.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: What is wrong with Ada?

[Ray Blaak]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> On Sun, 22 Apr 2007 23:50:52 +0200, Markus E Leypold wrote:
> 
> > You don't feel the need to justify the use of "trivial" for any
> > actually existing program?
> 
> Any actually existing program can be expressed with single natural number. 
> 
> Moreover, all programs which were ever written, as well as all ones which
> *actually* will ever be, all together, again could be characterized by
> another natural number.

While technically true, that characterization is not really useful in terms of
actually using such numbers, and does not really say anything at all about how
trivial such numbers/programs are.

In fact, the art of finding such numbers that do useful work for humans is
hard. People who know how to do that are called programmers.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: What is wrong with Ada?

[Larry Kilgallen]

In article <uk5w2kepu.fsf@STRIPCAPStelus.net>, Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

>> Any actually existing program can be expressed with single natural number. 

> While technically true, that characterization is not really useful in terms of
> actually using such numbers, and does not really say anything at all about how
> trivial such numbers/programs are.
> 
> In fact, the art of finding such numbers that do useful work for humans is
> hard. People who know how to do that are called programmers.

The traditional encounter is for construction of a Fortran compiler.
I propose to write the top element, and you write the lower one:

+-----------+
| Increment |<-----|
|  Memory   |      |
+-----------+      |
      |            |
      |            |
     / \           |
    /   \          |
   / Is  \         |
  / this  \        |
 /a Fortran\_______|
 \Compiler?/  No
  \       /
   \     /
    \   /
     \ /
      | Yes
      |
      |
    Done
 

Re: What is wrong with Ada?

[Ray Blaak]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> In article <uk5w2kepu.fsf@STRIPCAPStelus.net>, Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
> >> Any actually existing program can be expressed with single natural
> >> number. 
> The traditional encounter is for construction of a Fortran compiler.
> I propose to write the top element, and you write the lower one:
[clever search omitted]

You can do it that way if you like. I have a much better secret way of finding
fortran compilers. It took me 4 years of university to learn how.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: What is wrong with Ada?

[Markus E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 22 Apr 2007 23:50:52 +0200, Markus E Leypold wrote:
>
>> You don't feel the need to justify the use of "trivial" for any
>> actually existing program?
>
> Any actually existing program can be expressed with single natural number. 

How really non-surprising -- and absolutely unrelated to the topic.

> Moreover, all programs which were ever written, as well as all ones which
> *actually* will ever be, all together, again could be characterized by
> another natural number.

So can all buggy programs and all programs that don't do anything
useful.  I fail to see how the fact that there are countably inifinite
programs programs justifies the use of "trivial" for the property you
defined.

If this oracle means what I suspect (i.e. that you maintain the
position that all real existing programs are trivial) your choice of
words ("trivial") is somewhat strange. It seems to be far removed from
the ordinary use of the word "trivial".

That means, I suspect you made up that definition just to justify your
original blunder about programs on finite machines only being able to
process a finite set of inputs.

But perhaps you can still somehow alter course and make a suggestion
how your definition of trivial relates to the common use of the word?

Regards -- Markus

Re: What is wrong with Ada?

[Markus E Leypold]

Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:

> Kilgallen@SpamCop.net (Larry Kilgallen) writes:
>> In article <uk5w2kepu.fsf@STRIPCAPStelus.net>, Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:
>> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>> >> Any actually existing program can be expressed with single natural
>> >> number. 
>> The traditional encounter is for construction of a Fortran compiler.
>> I propose to write the top element, and you write the lower one:
> [clever search omitted]
>
> You can do it that way if you like. 

> I have a much better secret way of finding
> fortran compilers. 

So do I. I just google for a compiler vendor.

> It took me 4 years of university to learn how.

Didn't need 4 years for that. Be free to use my now not so secret
method of finding a Fortran compiler: It's not patented.

Regards -- Markus

Re: What is wrong with Ada?

[Dmitry A. Kazakov]

On Mon, 23 Apr 2007 20:39:28 GMT, Ray Blaak wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

>> Any actually existing program can be expressed with single natural number. 
>> 
>> Moreover, all programs which were ever written, as well as all ones which
>> *actually* will ever be, all together, again could be characterized by
>> another natural number.
> 
> While technically true, that characterization is not really useful in terms of
> actually using such numbers, and does not really say anything at all about how
> trivial such numbers/programs are.

> In fact, the art of finding such numbers that do useful work for humans is
> hard. People who know how to do that are called programmers.

The context in which I used the word "trivial" was processing of infinite
inputs. Infinity was the scale of triviality here, not human's ability to
write, sell or use programs, whatever they might be.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: What is wrong with Ada?

[Ray Blaak]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> The context in which I used the word "trivial" was processing of infinite
> inputs. Infinity was the scale of triviality here, not human's ability to
> write, sell or use programs, whatever they might be.

Yes, I know. I disagree with this use of trivial in a fundamental way, mainly
because it makes all possible programs that humans can use trivial. Finite
inputs are all we can work with in practical terms. 

We cannot ever use a program with infinite inputs simply because we cannot
wait long enough to see if the inputs are really infinite. If nothing else,
the death of the universe puts an upper bound on things.

Finite is plenty big enough to get work done, evolve life, etc. Quick: what's
the biggest finite number you can think of?

It is also a pet peeve of mine to play games with infinite numbers of
programs, mapping them to natural numbers, etc. Such games are also not useful
in practical terms, and do not give humans access to a larger class of
programs, or make programs any easier to "find". They really only aid in the
classification of computability theories.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: What is wrong with Ada?

[Chad R. Meiners]

On Apr 20, 12:25 pm, <adawo...@sbcglobal.net> wrote:

> I happen to like Python and I'm using more often now than Ada, for
> non-critical code.  It is quick and easy.   However, I would never think
> of using it for safety-critical software.

Wow!  Me too!  Even though I enjoy using Ada (and its numerous
benefits) for important stuff.  Python is way too useful for small
little projects that seem to pop up needing to be solved ;-)

Re: What is wrong with Ada?

[Chad R. Meiners]

On Apr 21, 9:50 am, "jimmaureenrog...@worldnet.att.net"
<jimmaureenrog...@worldnet.att.net> wrote:

> Can you obtain trial versions of any Microsoft product at all?

Actually most computer science students can obtain free and complete
versions of most Microsoft products.


-CRM

Re: What is wrong with Ada?

[Markus E Leypold]

"Chad  R. Meiners" <chad.rmeiners@gmail.com> writes:

> On Apr 21, 9:50 am, "jimmaureenrog...@worldnet.att.net"
> <jimmaureenrog...@worldnet.att.net> wrote:
>
>> Can you obtain trial versions of any Microsoft product at all?
>
> Actually most computer science students can obtain free and complete
> versions of most Microsoft products.

I hate to make advertisement for them, but even a non-student you can
get trial versions of a lot (most?) of things, e.g. Exchange (brr --
who'd want that?), most of the operating systems (perhaps only at
certain times?). They are mostly restricted to 120 days of use.

Since we have been talking about Ada vendors: MS understands marketing
very well, something the Ada vendors never groked. E.g. You always get
an answer to requests. it might be wrong, but it's always friendly and
the stay composed, even if you refuse their offer of X by pointing to
some free (as in freedom) product and tell them that you and/or your
customers prefer the free solution. On the other side, if I compare
that to (big) Ada vendors (Randy excepted!): On two requests for a
price list only one vendor bothered to answer and he didn't send a
list but wanted to know more about me/us (obviously they don't have a
standard package, but take what you can afford, a particularly
unsympathetic approach). And about surreal answers on requests about
licensing state and history from the "acting director, Europe" of a
certain vendor, I've already written enough in the past.

There is one similarity, though: Libre (well, that's only one Ada
vendor) and download.microsoft.com share a similar degree of amnesia
as far as the past state of things are concerned.

Regards -- Markus

Re: What is wrong with Ada?

[Georg Bauhaus]

On Wed, 2007-04-25 at 11:57 +0200, Markus E Leypold wrote:
>  On two requests for a
> price list only one vendor bothered to answer and he didn't send a
> list but wanted to know more about me/us (obviously they don't have a
> standard package, but take what you can afford, a particularly
> unsympathetic approach). 

Maybe they don't publicly announce prices to make sure
they can provide affordable solutions? Who knows? Once
the price list is out, the rich and/or big profit customers
might start arguing that they do no longer see a reason to pay
the larger sum adequate to large scale use of the tools. "We
heard from this developer that he got ... Then why should
we ...?"

So customer investment in the tools might need more arguing
given a comparatively small customer base;
when MS was smaller they charged $$$$ for MS Word alone.
Suppose they would have tried to prevent copying...

MS now has a huge market share, they do not seem to abhor a
monopoly, and they can easily afford making developers and
their customers depend on MS offerings. Lamps and oil,
printers and ink, Developers and office solutions.

Of course, I'm just guessing.

Re: What is wrong with Ada?

[Markus E Leypold]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> On Wed, 2007-04-25 at 11:57 +0200, Markus E Leypold wrote:
>>  On two requests for a
>> price list only one vendor bothered to answer and he didn't send a
>> list but wanted to know more about me/us (obviously they don't have a
>> standard package, but take what you can afford, a particularly
>> unsympathetic approach). 
>
> Maybe they don't publicly announce prices to make sure
> they can provide affordable solutions? 

The mirror side is: Charge what you can get. That is something
people^Wcustomers don't like.

  http://www.joelonsoftware.com/items/2006/07/31.html
  http://www.joelonsoftware.com/articles/CamelsandRubberDuckies.html

And as far as affordable goes: I think I don't need to go into that (again) :-).

> Who knows? 

Yes, who knows. That's why my car vendor doesn't have a price list
... not. Also why Microsoft doesn't have a price list etc. I think one
can well see there my argument what is going wrong with some Ada
vendors -- no need to elaborate.

> Once the price list is out, the rich and/or big profit customers
> might start arguing that they do no longer see a reason to pay the
> larger sum adequate to large scale use of the tools.

Hardly. Just differentiate service contracts and license to use and
structure the service into different levels.

 - Level 0: Only right to use.
 - Level 1: Right to access a ticket system.
 - Level 2: Right to browse a bug database / knowledge base about
   fixed and open bugs.
 - Level 3: Guarantee response times and quality.

This is one option and I think others will turn up. Or if you really
think that the cheap licenses are actually under price and not worth
the time and effort, then don't offer them. But if the cheap license
is still something you earn money with -- don't you think the "big
customer" will be somewhat pissed off to discover he pays more than
_you_ need, just because he can afford to.


> "We heard from this developer that he got ... Then why should we
> ...?"

I wonder: Do they actually write in the contract that you aren't
allowed to disclose you price? Since it is the current setup that
incurs the risk that somebody who got a special deal will be blabbing
and it will haunt you in your relationship to another customer.

> So customer investment in the tools might need more arguing
> given a comparatively small customer base;

> when MS was smaller they charged $$$$ for MS Word alone.
> Suppose they would have tried to prevent copying...

If you mean they didn't charge for DOS -- you're wrong.

> MS now has a huge market share, they do not seem to abhor a
> monopoly, and they can easily afford making developers and
> their customers depend on MS offerings. Lamps and oil,
> printers and ink, Developers and office solutions.

> Of course, I'm just guessing.

Well -- you can go on guessing. I'm almost sure that your thoughts to
a certain extend agree with those of certain Ada vendors and the spin
-- "to make sure they can provide affordable solutions" -- is
certainly identical.

But that proves in my eyes exactly that they are absolutely clueless
about marketing and customer psychology -- if they really think like
that.

Regards -- Markus

Re: What is wrong with Ada?

[Georg Bauhaus]

On Wed, 2007-04-25 at 13:54 +0200, Markus E Leypold wrote:
> Georg Bauhaus <bauhaus@futureapps.de> writes:

> > Maybe they don't publicly announce prices to make sure
> > they can provide affordable solutions? 
> 
> The mirror side is: Charge what you can get. That is something
> people^Wcustomers don't like.

Or pay as little as possible, there are always two parties
in a bargain.

>   http://www.joelonsoftware.com/items/2006/07/31.html

(Another argument: Dell is a free loader because they don't invest in
researching and developing the products they sell cheaply (computer
tech), unlike other computer makers. Good or bad?)

>   http://www.joelonsoftware.com/articles/CamelsandRubberDuckies.html

Some interesting speculations starting from Say's theorem
and some non-empiricism. So what? Wouldn't it be more informative
to observe what appears to be working, and how, in the Ada
market?
  Unlike the C#/VB market, the Ada market has some
potential of being competitive: there is more than
one tool vendor, and the free-beer edition of GNAT
is gone.



> Just differentiate service contracts and license to use and
> structure the service into different levels.

I see just this happening.



> If you mean they didn't charge for DOS -- you're wrong.

Huh? MS software was both expensive and copyable.


>  I'm almost sure that your thoughts to
> a certain extend agree with those of certain Ada vendors and the spin
> -- "to make sure they can provide affordable solutions" -- is
> certainly identical.
> 
> But that proves in my eyes exactly that they are absolutely clueless
> about marketing and customer psychology 

You mean, RR Software's compiler and tools, publicly priced
slightly above MSVSStandard, only doesn't sell in the millions
because it is more expensive than commercial entry VS?

And you think that once Aonix offers a 249 € compiler,
the will start selling so many copies 

Re: What is wrong with Ada?

[adaworks]

"Markus E Leypold" <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> 
wrote in message >
> The mirror side is: Charge what you can get. That is something
> people^Wcustomers don't like.
>
One of the practices that almost killed Ada was that of
gouging the Department of Defense because of the mandate.

By charging the highest prices they could get away with, the
compiler publishers also guaranteed that commercial prospects
for Ada would be slim to none.   Had the pricing policies been
more in-line with the rest of the market, the story of Ada might
be quite different today.

Richard Riehle 

Re: What is wrong with Ada?

[jimmaureenrogers]

On Apr 24, 6:20 pm, "Chad  R. Meiners" <chad.rmein...@gmail.com>
wrote:
> On Apr 21, 9:50 am, "jimmaureenrog...@worldnet.att.net"
>
> <jimmaureenrog...@worldnet.att.net> wrote:
> > Can you obtain trial versions of any Microsoft product at all?
>
> Actually most computer science students can obtain free and complete
> versions of most Microsoft products.

That fact is irrelevant to the conversation. The question was in
relation to
the difficulty of commercial projects obtaining trial versions of Ada
tools.

Jim Rogers

Re: What is wrong with Ada?

[Adrian Hoe]

On Apr 10, 5:02 pm, Pascal Obry <pas...@obry.net> wrote:
>
> Agreed 100%. Another way to put it, let me ask : What's wrong with
> developers ? Why do they like unsafe languages ? Why do they like
> fighting a language all the time ? Why do they like unreadable code ?
> Why do they like to play with a debugger ? Why do they like to play
> Sherlock Holmes during hours to look for a bug ? Here are the real
> questions to me, again nothing wrong with Ada to me !

It has been a long time I left CLA.

Perhaps I can answer these questions:

Developers like unsafe languages and they like debugging because:

1.) That will help securing their jobs because there are always bugs
to find.

2.) They can go to their bosses and say "We have to postpone because
there is a bug in the codes which we are having hard time to trace and
kill. We need more time and budget to clean this beast up!"

3.) They can get commission when they proposed to purchase XXX
debugger.

Hope these 3 answer the questions. :) Cheers!
--
Adrian Hoe
http://adrianhoe.net