No call for it
Carroll-Tech
----- Original Message -----
> Message: 10
> Date: Fri, 06 Feb 2004 16:23:38 GMT
> From: Les Cargill <lcar...@worldnet.att.net>
> Subject: Re: Announcing new scripting/prototyping language
> To: comp.l...@ada-france.org
> Message-ID: <4023C090...@worldnet.att.net>
> Content-Type: text/plain; charset=us-ascii
>
[snip]
> I've seen some fair sized 'C' and C++ projects. They are readable -
> to 'C'/C++ programmers.
>
> I'd have loved to have used Ada, but there never was much call for
> it.
I've been reading posts to this newsgroup for some time now, as well as
reading other information and I don't get the "never was much call for it"
ideal about Ada.
I'm not saying that anyone is wrong or right for saying or feeling that
there "never was much call for it"; maybe there wasn't. I'm leaning more
toward saying "it's a conscious choice".
I tell the students that I tutor that learning some Pascal or Ada would help
them and they get scared. I mention doing a project in Ada and everyone
looks at me like I'm out to punish myself. To me it isn't any easier to use
C/C++, Java, Perl, Lisp or Prolog than it is to use Ada. How is it that Ada
has this "super powerful", "super difficult", "there's not much call for it
because it's too advanced and powerful" air about it when it's just another
language? It's like saying that the machine code spit out of an Ada
compiler has some mystical, magical properties that makes the Ada language
more difficult to use.
To me, with Ada0Y coming out, the "not much call for it" attitude is the
cliché to dismiss. Or at least one of the things to overcome.
Just my opinion as a reader of comp.lang.ada.
Ludovic Brenta
> I tell the students that I tutor that learning some Pascal or Ada
> would help them and they get scared. I mention doing a project in
> Ada and everyone looks at me like I'm out to punish myself. To me
> it isn't any easier to use C/C++, Java, Perl, Lisp or Prolog than it
> is to use Ada. How is it that Ada has this "super powerful", "super
> difficult", "there's not much call for it because it's too advanced
> and powerful" air about it when it's just another language? It's
> like saying that the machine code spit out of an Ada compiler has
> some mystical, magical properties that makes the Ada language more
> difficult to use.
I was thinking along the same lines last evening, and I came up with a
small theory that explains why so few pople can be bothered to learn
Ada. It goes like this: There are 3 types of languages.
The first type of language says "we're going to make programming
easy". Of course, this is a lie, because programming is inherently
difficult and no language can make it easy. These languages fake it
by being simplistic. Java is the most prominent member of this family
of languages; most scripting languages also fall in this category.
Beginners tend to flock to these "easy" languages and never learn
proper programming skills (like e.g. memory management. If some Java
"guru" reads this, ask yourself this one question: how many threads
does your program have, and please justify the existence of each
thread).
The second type says "we will let you do anything, absolutely anything
you want, and the power is in the hands of the True Programmers".
Languages in this category include, among others, C and C++. Many
people take a foolish pride in being called a True Programmer, and
therefore like these languages. I myself once was in this category: I
would show off my skills by writing a single-line program that nobody
else could read. But humans write bugs, and these languages don't
lend a hand finding these. Hence the famous buffer overflows.
The third type is what I would call the "zen master" type of
languages. They treat you like an apprentice, slapping you on the
hand each time you make a small mistake, and they scorn at you for
choosing the quick and easy path -- which leads to the Dark Side. If
you accept their teachings, you quickly become a Master yourself. If
you rebel against them, you will never achieve Enlightenment and will
always produce bugs. The "zen master" languages are Pascal, Modula,
Oberon, and, master of masters, Ada. The beauty of these languages is
that, once you are Enlightened, you can apply your wisdom to other
languages as well -- but often would prefer not to.
--
Ludovic Brenta.
David Rasmussen
> "Carroll-Tech" <and...@carroll-tech.net> writes:
>
>
>>I tell the students that I tutor that learning some Pascal or Ada
>>would help them and they get scared. I mention doing a project in
>>Ada and everyone looks at me like I'm out to punish myself. To me
>>it isn't any easier to use C/C++, Java, Perl, Lisp or Prolog than it
>>is to use Ada. How is it that Ada has this "super powerful", "super
>>difficult", "there's not much call for it because it's too advanced
>>and powerful" air about it when it's just another language? It's
>>like saying that the machine code spit out of an Ada compiler has
>>some mystical, magical properties that makes the Ada language more
>>difficult to use.
>
I don't know. Ada rocks.
/David
David Harmon
<ludovic...@insalien.org> was alleged to have written:
>Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.java
You damned crossposting troll, there is _no_ subject on-topic in all
those newsgroups.
See the welcome message posted twice per week in comp.lang.c++ or
available at http://www.slack.net/~shiva/welcome.txt
Robert I. Eachus
> The third type is what I would call the "zen master" type of
> languages. They treat you like an apprentice, slapping you on the
> hand each time you make a small mistake, and they scorn at you for
> choosing the quick and easy path -- which leads to the Dark Side. If
> you accept their teachings, you quickly become a Master yourself. If
> you rebel against them, you will never achieve Enlightenment and will
> always produce bugs. The "zen master" languages are Pascal, Modula,
> Oberon, and, master of masters, Ada. The beauty of these languages is
> that, once you are Enlightened, you can apply your wisdom to other
> languages as well -- but often would prefer not to.
I think you are on the right track. When I am programming in Ada, I
often spend most of a day coding. If I am exhausted at the end of it, I
will put off compiling until the next day. Otherwise, I hand all the
code to the compiler, and I am not surprised to be handed back dozens of
error messages. Fix the syntax bugs, and now I get twices as many
semantic errors. Kill all those and I am surprised if the test
programs--often written between the package interface and the package
bodies--don't run correctly.
For example, I recently finished writing a library of matrix operations
which works with "views" that may be a submatrix of an existing matrix,
and supports operations like Add(A,B) where the result is written in A.
That's a bit tricky, but the real complex one is Mult(A,B) where the
amount of temporary storage space for two N by N matricies is N. (A
buffer that stores one row.)
Why am I mentioning this? After all the coding I had a bug in the Mult
routine that the compiler didn't catch. A wrong subscript inside a
loop. (Why am I doing this? To submit as a new benchmark for SPECfp.
All that stuff is just scaffolding for implementing Strassen's algorithm
efficiently.)
Since I don't take what the compiler tells me personally, I love the
ratio of a hundred to one or so between compile errors and run-time
bugs. Some people though look at a list of compiler error messages as
if each one was a major failing on their part. Me? I could proofread
the code carefully, but it is easier to let the compiler find out where
I typed a comma for a period, and so on. And IMHO it would be nice if
the compiler found all the typos, not just most of them. ;-)
Could I write the same code in C, C++, or Java? Sure. It is just much
easier to let the Ada compiler do the heavy lifting part of the
debugging, so I would still write in Ada, then modify the code to match
the C, C++, or Java syntax. So to me, all that frequent hand-slapping
is a major benefit.
--
Robert I. Eachus
"The war on terror is a different kind of war, waged capture by capture,
cell by cell, and victory by victory. Our security is assured by our
perseverance and by our sure belief in the success of liberty." --
George W. Bush
Jano
> I tell the students that I tutor that learning some Pascal or Ada would help
> them and they get scared. I mention doing a project in Ada and everyone
> looks at me like I'm out to punish myself. To me it isn't any easier to use
> C/C++, Java, Perl, Lisp or Prolog than it is to use Ada. How is it that Ada
> has this "super powerful", "super difficult", "there's not much call for it
> because it's too advanced and powerful" air about it when it's just another
> language? It's like saying that the machine code spit out of an Ada
> compiler has some mystical, magical properties that makes the Ada language
> more difficult to use.
I can tell you my personal experience. My first tries at Ada where
painful: For a start, it was hard (comparatively to other languages
anyway) to get your program compiled... these damn compiler complaining
about anything. Then, I was always getting "constraint_error" and such.
Mind you, in C these errors could go unnoticed for quite some time.
In the end, when you get used to the Ada way, you realize how productive
it makes you, but at first it was exactly as you depict it.
I've always said: Ada doesn't catch with the general populace because
isn't a language for everyone: it requires extra-discipline and other
qualities from the programmer. It's like fast-food and sane food:
everyone knows the later is better, but not everyone has the will to
renounce to the first. In the 20/80 rule, Ada is for the better 20% of
the programmers... or so I like to think ;)
Ed Falis
> Ada is for the better 20% of
> the programmers... or so I like to think ;)
I wouldn't be so self-congratulatory. I really don't think there's much
correlation here between programming skills and language choice.
What I do find is that the strength of the Ada compiler lessens my need
for certain kinds of self-discipline to some extent, and works much like
doing unit tests (or pair programming from XP) and having a facility for
design-by-contract do. It provides an additional automated safety net to
complement whatever the state of my self-discipline might be at a given
time. SPARK, I'm sure, does the same at a more "brisk" level.
But don't think that Ada is alone in providing such safety nets - there
are other languages and other techniques that can do as much or more,
depending on the emphasis on different issues in a given development
effort.
disclosure: I've been involved in implementing Ada since 1980-1.
- Ed
MSG
[...]
> The "zen master" languages are Pascal, Modula,
> Oberon, and, master of masters, Ada. The beauty of these languages is
> that, once you are Enlightened, you can apply your wisdom to other
> languages as well -- but often would prefer not to.
Can you do the following in Ada:
1. Write *one* bubble-sort function that will work on different
types given an appropriate comparison function
2. If B is a subtype of A, can you pass it to any function that
takes A as an argument? (covariance)
3. If B is a subtype of A, and FA and FB are functions accepting A
and B as arguments, can you use FA wherever FB could be used?
(contravariance)
4. If B is a subtype of A, is list/array/vector/set/etc. of Bs a
subtype of list/array/vector/set/etc of As? (covariance)
Unless you can show us how to do this in a way that will keep Ada a
"safe" (third category) language you say it is, I will not believe
that it's a "master of of the masters", I'm afraid.
If you answer "yes" to any of the questions, post *compilable*
snippets: we don't want to learn Ada just to verify your claims,
we simply won't believe you.
BTW, the esteemed Mr. E. Robert Tisdale (ER for short) isn't
letting on about why Ada isn't used much at NASA any more.
Perhaps *you* have an explanation?
MSG
David Rasmussen
>
> Unless you can show us how to do this in a way that will keep Ada a
> "safe" (third category) language you say it is, I will not believe
> that it's a "master of of the masters", I'm afraid.
>
> If you answer "yes" to any of the questions, post *compilable*
> snippets: we don't want to learn Ada just to verify your claims,
> we simply won't believe you.
>
> BTW, the esteemed Mr. E. Robert Tisdale (ER for short) isn't
> letting on about why Ada isn't used much at NASA any more.
> Perhaps *you* have an explanation?
>
So you have theories about Ada, but you don't really know it? That's
credible...
Just for the record: I am posting from comp.lang.c++.
/David
Alexandre E. Kopilovitch
> The third type is what I would call the "zen master" type of
> languages. They treat you like an apprentice, slapping you on the
> hand each time you make a small mistake, and they scorn at you for
> choosing the quick and easy path -- which leads to the Dark Side. If
> you accept their teachings, you quickly become a Master yourself.
No, this way you have a little chance for that. Following this way you'll
most probably become more or less respectable member of the guild, a master,
but not Master. Just because you are deprived from Dark Side, and every Master
must know it from good personal experience (some manage to get it from their
own imagination, but this is very rare case, as it requires exceptionally
strong imagination abilities... and exceptional abilities for keeping mental
balance as well).
> If you rebel against them,
Actually you must rebel against something if you want to achieve anything
significantly above average. Surely, it isn't necessary to rebel against your
master personally, but a rebellion against some widespread and respectable
opinion is almost inevitable for such a "graduation".
> you will never achieve Enlightenment and will always produce bugs.
You will produce bugs anyway, with or without Enlightenment -;) . And I'm
afraid that in this your description Enlightenment doesn't seem different
from Doctrine -;) .
> The "zen master" languages are Pascal, Modula,
> Oberon, and, master of masters, Ada.
I don't think so - there is vast amount of various "zens" and "zen masters"
for C++, Java... Smalltalk, Lisp, etc (even COBOL had at least one "zen", and
I remember that it was a good one). And all those "zen masters" feel themselves
quite comfortable with their accustomed languages.
Alexander Kopilovitch a...@vib.usr.pu.ru
Saint-Petersburg
Russia
Keith Thompson
> If you answer "yes" to any of the questions, post *compilable*
> snippets: we don't want to learn Ada just to verify your claims,
> we simply won't believe you.
Feel free to post compilable Ada snippets in comp.lang.ada, but please
don't cross-post to comp.lang.c, comp.lang.c++, or comp.lang.java.
The last thing any of these newsgroups needs is yet another language
flame war. (I'm posting from comp.lang.c.)
I've redirected followups to comp.lang.ada.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
tmo...@acm.org
> subtype of list/array/vector/set/etc of As? (covariance)
David Starner
> Of course, this is a lie, because programming is inherently
> difficult and no language can make it easy.
That's exactly what the assembly language programmers said about the
first Fortran compiler, and it's equally wrong now. Sure, there are cases
where you need to run DSP code and coordinate with the home base thirty
million miles away using one space-hardened 386, and that's hard. Then
there's the cases where you need two lines of shell to simplify moving
files around, and that's something assembly or Fortran or Ada or Java
would make much more complex then it is.
> (like e.g. memory management. If some Java
> "guru" reads this, ask yourself this one question: how many threads
> does your program have, and please justify the existence of each
> thread).
In the Jargon file, there's a story of a man who bummed every cycle out of
a poker program, even the initialization code, who spurned assembly
language because it was too inefficient. How would you explain your choice
of programming language to him? Who cares if there's a couple extra
threads running? You make a big deal about languages that protect you
against buffer overflows, why not use a language that protects you against
memory leaks?
> The "zen master" languages are Pascal, Modula,
> Oberon, and, master of masters, Ada.
Pascal is hardly usable, unless you use one of a dozen proprietary
extensions. That's hardly "zen master".
Ludovic Brenta
> On Sat, 07 Feb 2004 14:00:35 +0100, Ludovic Brenta wrote:
>
> > Of course, this is a lie, because programming is inherently
> > difficult and no language can make it easy.
>
> That's exactly what the assembly language programmers said about the
> first Fortran compiler, and it's equally wrong now. Sure, there are cases
> where you need to run DSP code and coordinate with the home base thirty
> million miles away using one space-hardened 386, and that's hard. Then
> there's the cases where you need two lines of shell to simplify moving
> files around, and that's something assembly or Fortran or Ada or Java
> would make much more complex then it is.
If you call this programming, then you're right. Scripting languages
do have a place and purpose. I was more concerned with large-scale,
real-world programming, where Ada shines but is being ignored by too
many people. I was only trying to explain to myself why. I stand by
my claim that no language can make programming easy. But a language
help you find, or avoid, bugs.
> > (like e.g. memory management. If some Java
> > "guru" reads this, ask yourself this one question: how many threads
> > does your program have, and please justify the existence of each
> > thread).
>
> In the Jargon file, there's a story of a man who bummed every cycle out of
> a poker program, even the initialization code, who spurned assembly
> language because it was too inefficient. How would you explain your choice
> of programming language to him?
I would ask him, "would you trust your own life to your program"?
> Who cares if there's a couple extra threads running? You make a big
> deal about languages that protect you against buffer overflows, why
> not use a language that protects you against memory leaks?
Because I want to control exactly how much memory my program uses, and
I want to know exactly how many "a couple" means, and why these
"couple" threads are necessary. You referred to embedded software for
space-bound devices, this is one area where these questions are really
important. I am willing to accept run-time inefficiency and "a couple
extra threads" if justified. There are some languages that force
these upon you and won't justify this cost.
> > The "zen master" languages are Pascal, Modula,
> > Oberon, and, master of masters, Ada.
>
> Pascal is hardly usable, unless you use one of a dozen proprietary
> extensions. That's hardly "zen master".
That is true, but I meant "master" in the sense of "teacher". Pascal
was quite good at teaching, and as a "master" it had quite a lot of
apprentices.
--
Ludovic Brenta.
David Starner
> I was more concerned with large-scale,
> real-world programming, where Ada shines but is being ignored by too
> many people.
Ah, so that wasn't in the real world. Thanks for clarifying that.
> I was only trying to explain to myself why. I stand by
> my claim that no language can make programming easy. But a language
> help you find, or avoid, bugs.
But that's not the goal of programming. The goal of programming is to
produce programs that get the job done. There are certainly languages that
remove the concern about memory usage, and allow you to easily handle
strings and databases and GUIs, and these languages certainly do make it
easier to solve certain classes of programs. If they're slower and take
more memory, no one cares. If they have a few bugs, well, they get worked
around.
> I would ask him, "would you trust your own life to your program"?
He would tell you of course, and ask you how you could trust your life to
a program automatically produced by a compiler you know to be buggy.
I might point out that his program doesn't require that you trust your
life to it. Not everything is life and death, and a lot of things require
writing the program quickly or having the program run quickly over
absolute correctness.
> Because I want to control exactly how much memory my program uses,
So you're anal. There are very few programs that push my computer, with
300 MB of RAM to swap. Worrying about 10% memory usage on the rest in
exchange for occasional crashes is not a good tradeoff.
> You referred to embedded software for
> space-bound devices, this is one area where these questions are really
> important.
Yes, but you missed the point. That's one class of software, and
there's probably not a million lines of code written a year for that
class; probably not one percent of the code written for PCs with 1 GB of
memory that won't use over a few MB in practice.
> There are some languages that force these
> upon you and won't justify this cost.
But you aren't the one being asked to justify it; you are telling other
programmers that it's unjustified. Perhaps the inefficiency is justified
to them.
> Pascal
> was quite good at teaching, and as a "master" it had quite a lot of
> apprentices.
Java has a lot of apprentices, too. Pascal has something to do with the
number of people who refused to look at Ada, in the way that it forced
everyone into this tiny box, without modules or generics or bit twiddling
and all in one file.
Nick Landsberg
David Starner wrote:
> On Sat, 07 Feb 2004 14:00:35 +0100, Ludovic Brenta wrote:
>
>
>>Of course, this is a lie, because programming is inherently
>>difficult and no language can make it easy.
>
>
> That's exactly what the assembly language programmers said about the
> first Fortran compiler, and it's equally wrong now. Sure, there are cases
> where you need to run DSP code and coordinate with the home base thirty
> million miles away using one space-hardened 386, and that's hard. Then
> there's the cases where you need two lines of shell to simplify moving
> files around, and that's something assembly or Fortran or Ada or Java
> would make much more complex then it is.
>
>
>>(like e.g. memory management. If some Java
>>"guru" reads this, ask yourself this one question: how many threads
>>does your program have, and please justify the existence of each
>>thread).
>
>
> In the Jargon file, there's a story of a man who bummed every cycle out of
> a poker program, even the initialization code, who spurned assembly
> language because it was too inefficient. How would you explain your choice
> of programming language to him? Who cares if there's a couple extra
> threads running? You make a big deal about languages that protect you
> against buffer overflows, why not use a language that protects you against
> memory leaks?
"Who cares it there's an extra couple of threads running?" you ask.
I do! I work on systems which are required to process thousands
of requests per second. Unnecessary threads (just because the language
makes it easy to create them), waste precious CPU cycles. (But that's
OT in c.l.c, I think).
If your last statement refers to Java protecting you against memory
leaks, then you have a surprise in store for you.
If it protects you against memory leaks why is there a need for
a garbage collector in the first place?
I have found many situations where the garbage collector did
not clear unused memory. The garbage collector is just as
buggy as any other code. (This is also OT in the c.l.c group.
and I don't want to subsribe to c.l.java :)
>
>
>>The "zen master" languages are Pascal, Modula,
>>Oberon, and, master of masters, Ada.
>
>
> Pascal is hardly usable, unless you use one of a dozen proprietary
> extensions. That's hardly "zen master".
>
--
Ñ
"It is impossible to make anything foolproof because fools are so
ingenious" - A. Bloch
Ludovic Brenta
Dear "MSG", I do not normally respond to people who won't tell me
their name. Nevertheless, I found your questions interesting, so here
goes.
msg...@yahoo.com (MSG) writes:
> Ludovic Brenta <ludovic...@insalien.org> wrote...
>
> [...]
>
> > The "zen master" languages are Pascal, Modula,
> > Oberon, and, master of masters, Ada. The beauty of these languages is
> > that, once you are Enlightened, you can apply your wisdom to other
> > languages as well -- but often would prefer not to.
>
>
> Can you do the following in Ada:
>
> 1. Write *one* bubble-sort function that will work on different
> types given an appropriate comparison function
Yes you can, using generics. This is actually part of the library
that comes with the GNAT compiler.
See the spec for the package at http://savannah.gnu.org/cgi-bin/viewcvs/gcc/gcc/gcc/ada/g-busorg.ads?rev=HEAD&content-type=text/vnd.viewcvs-markup
And the body at http://savannah.gnu.org/cgi-bin/viewcvs/gcc/gcc/gcc/ada/g-busorg.adb?rev=HEAD&content-type=text/vnd.viewcvs-markup.
> 2. If B is a subtype of A, can you pass it to any function that
> takes A as an argument? (covariance)
Yes, as illustrated below. Covariance, as far as I understand, is the
capability to override the function using B as a type for both the
parameter and the return type. Ada has this capability. Note that
Ada has no hidden "this" parameter; everything is explicit.
with Ada.Text_IO; use Ada.Text_IO;
procedure Covariance is
package P is
type A is tagged null record;
function Operation (This : A) return A;
procedure Some_Primitive_Operation (Parameter : in out A);
type B is new A with null record;
function Operation (This : B) return B;
-- is a covariant function: the types of the parameter and the return
-- type vary together
end P;
package body P is
function Operation (This : A) return A is
begin
Put_Line ("Operation on A");
return This;
end Operation;
procedure Some_Primitive_Operation (Parameter : in out A) is
begin
Put_Line ("This accepts A or any derived type thereof");
end Some_Primitive_Operation;
function Operation (This : B) return B is
begin
Put_Line ("Operation on B");
return This;
end Operation;
end P;
use P;
My_First_A, My_Second_A : A;
My_First_B, My_Second_B : B;
begin
My_Second_A := Operation (This => My_First_A);
My_Second_B := Operation (This => My_First_B);
Some_Primitive_Operation (Parameter => My_Second_B);
end Covariance;
> 3. If B is a subtype of A, and FA and FB are functions accepting A
> and B as arguments, can you use FA wherever FB could be used?
> (contravariance)
I'm not sure I understand what you mean. Does the following code
answer your question? If it doesn't, please post a compilable code
snippet in your preferred language.
with Ada.Text_IO; use Ada.Text_IO;
procedure Contravariance is
package P is
type A is tagged null record;
function Func (This : in A) return A'Class; -- this would be FA
type B is new A with null record;
function Func (This : in B) return A'Class; -- this would be FB
end P;
package body P is
function Func (This : in A) return A'Class is
begin
Put_Line ("Func on A");
return This;
end Func;
function Func (This : in B) return A'Class is
begin
Put_Line ("Func on B");
return This;
end Func;
end P;
use P;
My_First_A, My_Second_A : A;
My_First_B, My_Second_B : B;
begin
My_First_A := A (Func (My_First_A)); -- explicit conversion to type A
My_Second_A := A (Func (My_First_B)); -- explicit conversion to type A
end Contravariance;
> 4. If B is a subtype of A, is list/array/vector/set/etc. of Bs a
> subtype of list/array/vector/set/etc of As? (covariance)
Not automatically. You would define new containers explicitly for A
and B, using generics; see for example the Booch components[1] or the
Charles library[2], which is modelled after the C++ STL. If you want
polymorphic containers, you store pointers in them.
[1] http://www.pogner.demon.co.uk/components/bc/case-study.html
[2] http://home.earthlink.net/~matthewjheaney/charles/
> Unless you can show us how to do this in a way that will keep Ada a
> "safe" (third category) language you say it is, I will not believe
> that it's a "master of of the masters", I'm afraid.
I cannot show you something you refuse to see (you say you won't learn
Ada). But if you are curious and intellectually honest, you will see
that Ada is indeed safer almost all other languages.
If Ada is not safe enough for you (even though it is for Boeing and
Airbus and the French TGV), then look into SPARK[3]. SPARK is a
subset of Ada where dynamic memory allocation and several other
potentially dangerous constructs are forbidden. When I say "subset",
I mean that any Ada compiler can compile any SPARK program. It also
adds design by contract à la Eiffel, using a tool called the
"Examiner" that complements the compiler.
> If you answer "yes" to any of the questions, post *compilable*
> snippets: we don't want to learn Ada just to verify your claims,
> we simply won't believe you.
You would be well advised to learn Ada. If you don't do it just to
verify my claims, do it to better your understanding of safety,
maintainability and large-scale programming in general. As I said, if
you accept to be given lessons, you can then reapply this insight to
your language of choice.
> BTW, the esteemed Mr. E. Robert Tisdale (ER for short) isn't
> letting on about why Ada isn't used much at NASA any more.
> Perhaps *you* have an explanation?
My earlier post was an attempt at an explanation. To rephrase it
shortly, few people are willing to be slapped on the hand by the
compiler every time they make a mistake; they'd rather ship buggy
software to customers ("True Programmers"), or use a language that
makes critical decisions unbeknownst to them ("Programming made
easy"). This explanation, of course, is just a theory of mine and is
a caricature more than an accurate description of reality.
--
Ludovic Brenta.
Simon Wright
> I think you are on the right track. When I am programming in Ada, I
> often spend most of a day coding. If I am exhausted at the end of it,
> I will put off compiling until the next day. Otherwise, I hand all
> the code to the compiler, and I am not surprised to be handed back
> dozens of error messages. Fix the syntax bugs, and now I get twices
> as many semantic errors.
I don't know if I'm just too impatient, but I much prefer to implement
each subprogram body and then compile it (they are usually separates,
so GNAT is quite happy do do this from within Glide).
If nothing else, it means that any problems with specs or
inter-package relationships appear earlier.
> Kill all those and I am surprised if the
> test programs--often written between the package interface and the
> package bodies--don't run correctly.
--
Simon Wright 100% Ada, no bugs.
Martin Krischik
> Not automatically. You would define new containers explicitly for A
> and B, using generics; see for example the Booch components[1] or the
> Charles library[2], which is modelled after the C++ STL. If you want
> polymorphic containers, you store pointers in them.
> [1] http://www.pogner.demon.co.uk/components/bc/case-study.html
> [2] http://home.earthlink.net/~matthewjheaney/charles/
AdaCL (adacl.sf.net) has polymorphic containers whichout (exposed) pointers
- that is somthing C++ can't do ;-) because C++'s RTTI is only a cheap
excuse compared with Ada's tags.
For the C++ programmes: If you copy contruct a class in Ada then Ada will
use the tag of the class to determine the actual child class and copy that
instead of the currently visible prarent view of the class.
With Regards
Martin
--
mailto://kris...@users.sourceforge.net
http://www.ada.krischik.com
Martin Krischik
> Ludovic Brenta <ludovic...@insalien.org> wrote in message
> news:<m3isij11...@insalien.org>...
>
> [...]
>
>> The "zen master" languages are Pascal, Modula,
>> Oberon, and, master of masters, Ada. The beauty of these languages is
>> that, once you are Enlightened, you can apply your wisdom to other
>> languages as well -- but often would prefer not to.
>
>
> Can you do the following in Ada:
>
> 1. Write *one* bubble-sort function that will work on different
> types given an appropriate comparison function
Shure you can. Ada invented templates long bevore C++ was even though of.
Ada templates are far more powerfull then C++.
> 2. If B is a subtype of A, can you pass it to any function that
> takes A as an argument? (covariance)
subtype as in object orientation:
type Parent is tagged null record;
type Child is new Parent with null record;
or subtype as in simple types:
type Day_of_Month is range 1 .. 31;
subtype Day_of_Febuary is Day_of_Month range 1 .. 29;
Well, the answer is yes in both cases.
> 3. If B is a subtype of A, and FA and FB are functions accepting A
> and B as arguments, can you use FA wherever FB could be used?
> (contravariance)
Of corse.
> If you answer "yes" to any of the questions, post *compilable*
> snippets: we don't want to learn Ada just to verify your claims,
> we simply won't believe you.
Others did that allready. Besides, you would need an installed Ada compiler
to verify anyway.
> BTW, the esteemed Mr. E. Robert Tisdale (ER for short) isn't
> letting on about why Ada isn't used much at NASA any more.
He also won't tell you why Spirit died.
Alexandre E. Kopilovitch
> The goal of programming is to produce programs that get the job done.
Your employer must be satisfied with that statement -:) , but as you put it
here instead of your resume, I must tell you that this statement is severely
flawed. Programming is not covered by compilation and scripting. Generally,
major part of programming is to define precisely and formally, *what* is the
job, and what does it mean that this job *is done*. For a compilation-like job
both definitions are prerequisites, and for scripting some imprecise and
informal understanding of them very often is enough, but for other flavours
of programming this is major part of the goal.
(As an exercise you may try to define that - what is the job and what means
that this job is done - for a "good text editor"... better to do that exercise
within a group of your fellow programmers -:) .
Josh Sebastian
> MSG wrote:
>
>> Can you do the following in Ada:
>>
>> 1. Write *one* bubble-sort function that will work on different
>> types given an appropriate comparison function
>
> Shure you can. Ada invented templates long bevore C++ was even though of.
Factoid: Alex Stepanov started off his research that led to the STL in Ada.
> Ada templates are far more powerfull then C++.
Why do you say that? I haven't used Ada terribly much, but from what I
remember, I don't think Ada generics are Turing-complete, which C++
templates are.
Josh
Martin Krischik
> On Sun, 08 Feb 2004 14:05:53 +0100, Martin Krischik wrote:
>
>> MSG wrote:
>>
>>> Can you do the following in Ada:
>>>
>>> 1. Write *one* bubble-sort function that will work on different
>>> types given an appropriate comparison function
>>
>> Shure you can. Ada invented templates long bevore C++ was even though of.
>
> Factoid: Alex Stepanov started off his research that led to the STL in
> Ada.
I am not quite shure what you want to say. As far as I know generics had
been part of Ada 83. But of course without some STL.
>> Ada templates are far more powerfull then C++.
>
> Why do you say that? I haven't used Ada terribly much, but from what I
> remember, I don't think Ada generics are Turing-complete, which C++
> templates are.
Well I have used C++ for 10 years and Ada for just 1 year - I can express my
will better with Ada generics then with C++ templates.
Josh Sebastian
> Josh Sebastian wrote:
>
>> On Sun, 08 Feb 2004 14:05:53 +0100, Martin Krischik wrote:
>>
>> Factoid: Alex Stepanov started off his research that led to the STL in
>> Ada.
>
> I am not quite shure what you want to say.
I was saying that the STL started off in Ada before it was moved to (and
completed in) C++. I wasn't disagreeing with you (yet :).
>>> Ada templates are far more powerfull then C++.
>>
>> Why do you say that? I haven't used Ada terribly much, but from what I
>> remember, I don't think Ada generics are Turing-complete, which C++
>> templates are.
>
> Well I have used C++ for 10 years and Ada for just 1 year - I can express my
> will better with Ada generics then with C++ templates.
Maybe you just weren't very good at C++ templates. I don't mean to be
insulting, but personal preferences do play a huge roll here. Unless
someone can prove Ada's generics are Turing-complete, though (a quick
google doesn't turn up anything), I'd say that we'll have to call C++
templates more powerful.
Josh
Martin Ambuhl
advocacy.
Perhaps comp.lang.ada cares about the preference of one for Ada;
perhaps comp.lang.c++. Who knows what the people in comp.lang.java care
about? I know for damn sure that comp.lang.c is not the place for your
silly discussion of Ada vs. C++.
I have set follow-ups to comp.lang.ada and comp.lang.c++. Even that might
be too much. In any event, take comp.lang.c off any future exchanges you
idiots have. Even better: take it to e-mail.
--
Martin Ambuhl
David Starner
> David Starner wrote:
>
>> The goal of programming is to produce programs that get the job done.
>
> [...] I must tell you that this statement is severely
> flawed. Programming is not covered by compilation and scripting. Generally,
> major part of programming is to define precisely and formally, *what* is the
> job, and what does it mean that this job *is done*.
And once you have the program at a state where it needs no more
programming, all that goes into a drawer and disappears. That is part of
what needs to be done to get a program that gets the job done, but that's
not part of the goal; that's part of the process.
MSG
> Others did that allready. Besides, you would need an installed Ada compiler
> to verify anyway.
time apt-get install gnat
=> 15 seconds
> >
> > Can you do the following in Ada:
> >
> > 1. Write *one* bubble-sort function that will work on different
> > types given an appropriate comparison function
>
> Shure you can. Ada invented templates long bevore C++ was even though of.
> Ada templates are far more powerfull then C++.
Example?
> > 2. If B is a subtype of A, can you pass it to any function that
> > takes A as an argument? (covariance)
>
> subtype as in object orientation:
>
> type Parent is tagged null record;
> type Child is new Parent with null record;
"null record" ? How about non-null ones? Is a 3D point (x, y, z) a
subtype of a 2D one (x, y) ?
BTW, does Ada have discriminated unions? (if you don't know what they
are, probably none of the language you used had them)
Also, is it possible to corrupt memory in Ada?
Is it possible to leak memory in Ada?
> or subtype as in simple types:
>
> type Day_of_Month is range 1 .. 31;
> subtype Day_of_Febuary is Day_of_Month range 1 .. 29;
That's neat.
> > BTW, the esteemed Mr. E. Robert Tisdale (ER for short) isn't
> > letting on about why Ada isn't used much at NASA any more.
>
> He also won't tell you why Spirit died.
It's not dead, it's sleeping!
Cheers,
MSG
James Rogers
cross-posted news-groups I would like to carry on this conversation
with you via email. My return email is valid.
Jim Rogers
Ludovic Brenta
> Martin Krischik <kris...@users.sourceforge.net> wrote:
>
> > Others did that allready. Besides, you would need an installed Ada compiler
> > to verify anyway.
>
> time apt-get install gnat
> => 15 seconds
Thanks, I made that package :)
> > >
> > > Can you do the following in Ada:
> > >
> > > 1. Write *one* bubble-sort function that will work on different
> > > types given an appropriate comparison function
> >
> > Shure you can. Ada invented templates long bevore C++ was even though of.
> > Ada templates are far more powerfull then C++.
>
> Example?
I gave one earlier on c.l.ada. I did not cross-post it to the other
newsgroups.
Ada templates are superior to C++ templates in several respects. For
one thing, you can pass procedures and functions as generic
parameters, and the generic formal parameters specify the signature
for them. Another thing is that the generic formal parameters can
specify several kinds of restrictions to types that are acceptable.
> > > 2. If B is a subtype of A, can you pass it to any function that
> > > takes A as an argument? (covariance)
> >
> > subtype as in object orientation:
> >
> > type Parent is tagged null record;
> > type Child is new Parent with null record;
>
> "null record" ? How about non-null ones? Is a 3D point (x, y, z) a
> subtype of a 2D one (x, y) ?
type Point_2D is tagged record
X, Y : Float;
end record;
type Point_3D is new Point_2D with record
Z : Float;
end record;
> BTW, does Ada have discriminated unions? (if you don't know what they
> are, probably none of the language you used had them)
Yes, they are called variant records.
> Also, is it possible to corrupt memory in Ada?
Yes, if you try hard enough and use Unchecked_Conversion and
System.Address instead of the more usual stuff. Very hard in
practice. I once tried to do a buffer overflow in Ada, and managed
it, but the code to achieve this is rather ugly. Basically, you have
to go the extra mile to corrupt memory in Ada.
> Is it possible to leak memory in Ada?
Yes, just like in C. However, since Ada programmers do much less
dynamic memory allocation, this happens much less often than it does
in C. Note that there also exists a garbage collector in Ada, as part
of AdaCL.
> > or subtype as in simple types:
> >
> > type Day_of_Month is range 1 .. 31;
> > subtype Day_of_Febuary is Day_of_Month range 1 .. 29;
>
> That's neat.
If this is neat then dig this:
for J in Day_Of_Month loop
exit when Month = February and then J >= Day_Of_February'Last;
Put_Line (Day_Of_Month'Image (J));
end loop;
And think about the implications of these ranges on subprograms that
accept only a small set of integer constants as a parameter:
type Assessment is (Yes, No, Maybe, Maybe_Not);
procedure P (A : Assessment);
which is not possible in C:
typedef enum { YES, NO, MAYBE, MAYBE_NOT } assessment_t;
void P (assessment_t A) { }
int main () {
P (42); // no compiler check!
return 0;
}
I just tried the above with gcc -Wall and got no warning. This means
that only a human carefully reviewing this program will see the
mistake (you may also try lint, but this is a tool external to the
language and based on heuristics, not language rules). By contrast,
the Ada compiler catches the mistake automatically in seconds and
leaves you with the confidence that 100% of your code has been
screened for such stupid mistakes.
--
Ludovic Brenta.
Robert I. Eachus
> I don't know if I'm just too impatient, but I much prefer to implement
> each subprogram body and then compile it (they are usually separates,
> so GNAT is quite happy do do this from within Glide).
>
> If nothing else, it means that any problems with specs or
> inter-package relationships appear earlier.
We all have our different styles. I find when I have a design worked
out I am better off "slinging" code while it is all in my head, then
starting fresh when debugging. However, I usually do the specs in a
batch, compile them cleanly, then do the bodies. Even though there are
much fewer lines of code in the specs, they take about as much time to
write as the package bodies.
(Incidently, I cut the distribution on this to comp.lang.ada only.)
Preben Randhol
> Also, is it possible to corrupt memory in Ada?
"... in Ada, you can never have a buffer overflow error. Unless of
course you go very far out of your way to specifically program one
[...] most Ada programmers would consider going out of your way to
construct an Ada program that had a potential buffer overflow not
as a challenge, but as a kind of pornography."
- Robert I. Eachus
> Is it possible to leak memory in Ada?
Sure, if that is what you want to do... I wouldn't advice it though.
Preben
--
«For me, Ada95 puts back the joy in programming.»
Thomas Stegen CES2000
> Maybe you just weren't very good at C++ templates. I don't mean to be
> insulting, but personal preferences do play a huge roll here. Unless
> someone can prove Ada's generics are Turing-complete, though (a quick
> google doesn't turn up anything), I'd say that we'll have to call C++
> templates more powerful.
Turing completeness is only one measure of power. And not a very
good one for measuring different systems of templates. If you use
templates for any sort of computational programming beyond some
very simple things you are stretching the rubber band beyond its
limit.
--
Thomas.
Alexandre E. Kopilovitch
> >> The goal of programming is to produce programs that get the job done.
> >
> > [...] I must tell you that this statement is severely
> > flawed. Programming is not covered by compilation and scripting. Generally,
> > major part of programming is to define precisely and formally, *what* is the
> > job, and what does it mean that this job *is done*.
>
> And once you have the program at a state where it needs no more
> programming, all that goes into a drawer and disappears.
That may be true for programs with short lifecycles and no (or very little)
maintenance anticipated (but even for those kind of programs that isn't always
true). But here in comp.lang.ada newsgroup we speak primarily about Ada language,
which was designed specifically for applications with long lifecycles and
substantial amount of maintenance. In such circumstances permanent tracking
of the meaning of "job" and "is done" for the application is necessary.
> That is part of
> what needs to be done to get a program that gets the job done, but that's
> not part of the goal; that's part of the process.
When you expect long lifecycle and much maintenance, the relations between
the goal and the process aren't so simple and straitforward. In fact, providing
good support for a long process is a major part of the goal.
MSG
more closely at Ada. It looks like it is indeed one of the safest
languages among the ones that aren't garbage collected, which probably
makes it suitable for programming things like airplanes, etc.:
1. hard real-time
2. bug-averse
3. not very performance demanding (don't know about other compilers,
but they say GNAT produces slow executables)
However, it does not look like it's a good match for me, since my
needs are the exact opposite:
1. no real time
2. bugs welcome (but not wrong results) - lusers will not come near my
programs
3. performance is highly important
James Rogers <jimmaure...@att.net> wrote in message news:<Xns9489AEC0F8702...@204.127.36.1>...
Ed Falis
> 3. not very performance demanding (don't know about other compilers,
> but they say GNAT produces slow executables)
"... but they say ..."
Great research!
;-)
James Rogers
news:54759e7e.0402...@posting.google.com:
> Thanks very much to everyone for the interesting info. It made me look
> more closely at Ada. It looks like it is indeed one of the safest
> languages among the ones that aren't garbage collected, which probably
> makes it suitable for programming things like airplanes, etc.:
>
> 1. hard real-time
> 2. bug-averse
> 3. not very performance demanding (don't know about other compilers,
> but they say GNAT produces slow executables)
>
> However, it does not look like it's a good match for me, since my
> needs are the exact opposite:
>
> 1. no real time
> 2. bugs welcome (but not wrong results) - lusers will not come near my
> programs
> 3. performance is highly important
I find your list of needs interesting.
How do you distinguish between bugs and wrong results? My experience
is that bugs are detected because they produce incorrect results.
If nothing goes wrong we do not declare the presence of a bug.
I think you will find, if you look into hard real-time systems,
that performance is critical. While it is true that GNAT has
produced relatively slow executables in the past, those same
executables are often 3 to 5 times faster than early Java
programs. I know that current JVMs have improved performance
significantly. I speak of JVMs from around the year 2000. Other
Ada compilers produce faster code than GNAT. Sometimes you get
what you pay for. (GNAT is a free compiler in the GNU compiler
chain).
What kind of performance measures do you use in your problem
domain? C programmers are fond of fast code execution and fast
compilation. C++ programmers have similar performance priorities,
but are willing to sacrifice some compiler speed for the
flexibility of templates. Java programmers frequently prize
speed of coding, with the clever use of the large set of API
libraries available to them. Ada programmers are fond of fast
code and early detection of coding defects.
Jim Rogers
Richard Riehle
evening,
but even the most ardent enthusiasts for one language or another will
eventually
admit that languages are nothing more than tools for composing computer
programs. The good craftsperson selects the appropriate tool for the job
at hand.
During my forty-plus year career I have had to use a variety of different
programming languages. In some cases I have had to construct fairly
large programs. Other times, my programs were small parts of much
larger systems.
During the past four years (actually longer if I count preparation time), I
have
had to put to use, engage, and confront several newer language offerings. Of
these new offerings, I rather like some aspects of Ruby, some ideas in C#,
and have gained a new level of respect for certain functional languages.
Still, each of these new languages is a tool. My responsibility, as a
computer
software practitioner, is to understand when to pick the right tool for the
right
job. On a large-scale project, I must realize that several different
languages
might be required. Also, some people will be more skilled with one
language
than another or some pre-existing code might be better suited to the
solution
than brand-new code in the latest whiz-bang language.
Under some circumstances, C++ is a perfectly appropriate choice. It is no
better than Ada for these circumstances, but it is acceptable. In some
other
set of circumstances, Ada is a perfectly good choice. Again, it is no
better
than C++, but works out just fine.
There are still other problems where language choice does matter. For
programming
an small microcomputer (e.g. I-8051) C is almost always a better choice than
either Ada or C++. For large, mainframe data processing systems, modern
COBOL
(Yes, COBOL has been modernized) is probably a better choice. The worst
possible choice for those mainframe systems is probably C++, but lots of
irresponsible
software managers are allowing such code to disrupt their development cycle.
For windows (MS) programming, C++ still has some edge over Ada simply
because it is
more closely associated with the MS programming libraries. However, I have
been involved
in a least one significant project where Ada proved more portable across
more kinds of
windows environments than C++.
We select Ada when dependability is an issue. A clear requirement of safe
software is
that of predictability. C++ is well-known to be the source of much that is
unpredictable.
We certainly do not want to use tools with inherent unpredicatbility in the
creation of
predictable, deterministic software solutions. In such cases, Ada is the
correct tool.
Some might suggest that Eiffel also fits that description. The language
definition for
Eiffel probably does. One needs to examine implementations to determine
whether
the result will involve complete predictability.
Meanwhile, SQL remains useful. Visual Basic is a good tool for those
applications
that lend themselves to such solutions. Java is good for a limited range
of things, but
is used for more things than it is good for. C++ continues to have much to
recommend it.
People do not select their programming tools as wisely as they select their
carpentry
tools. Usually, someone learns a language and sticks with it they way some
people
stick with the same religion into which they were born, or the same
political party
into which they were born.
The religiofication of language arguments leads nowhere. Reasonable people
must understand
that languages are designed by people, and every language is flawed in one
way or another. We
must admit the flaws in our preferred language before the other fellow will
admit the flaws in
his/her preferred language. As we do so, we might just come up with some
ideas for the next
improved language rather than remain paralyzed with the our current
favorite.
Richard Riehle
Robert I. Eachus
> Language advocacy can be an entertaining activity on a cold winter's
> evening, but even the most ardent enthusiasts for one language or another
> will eventually admit that languages are nothing more than tools for
> composing computer programs. The good craftsperson selects the
> appropriate tool for the job at hand.
Not really. Programming languages are also tools for thinking. And
different languages favor different ways of thinking. This effect can
also be seen in spoken languages you can't understand the French and the
people of Quebec unless you can think in French. (I am the first to
admit I can't. I can try, but I find the exercise very strenuous. I
need to literally accept a foreign viewpoint to do it well and I am
unwilling to do so. The cultural baggage with Arabic and Chinese is
larger that that which comes with French, but it isn't as imperialistic.
Japanese on the other hand, is much more demanding than French, but in
another sense it is not as hard. Japanese requires you to act in
certain ways, but it doesn't try as hard to impose its worldview on you.
However, the worldview that comes with Japanese is pretty nasty.
Note, this does not say that Japanese are nasty. However, I have found
that there is a huge difference in world view between those Japanese who
speak English and those who don't, I don't know if this holds true for
those who speak only another Asian as opposed to European language. I
haven't studied Russian in decades, but I remember it as being like the
Germanic langauges. They do fit your discription above. They are tools
and can be used in many different ways.
> ...The religiofication of language arguments leads nowhere. Reasonable
> people must understand that languages are designed by people, and every
> language is flawed in one way or another. We must admit the flaws in our
> preferred language before the other fellow will admit the flaws in
> his/her preferred language. As we do so, we might just come up with some
> ideas for the next improved language rather than remain paralyzed with
> the our current favorite.
I don't disagree, but I am going to draw a very different parallel with
religion. In the sermon this Sunday, our minister who worked in
marketing for decades before going to seminary, drew an interesting
comparison between "the church" and corporations. He was talking about
how corporate structures were designed to be conservative, in the sense
that they are designed to preserve and enhance the corporation.
Products and customers, while important, are secondary. I corporation
can switch products or switch products, if necessary for the survival of
the company.
The church is different. We can't walk away from the message and we
really are failing if we chose to target a particular market. It may be
a good strategy for the short term survival of the organization, but at
the same time we can't tailor the message to a particular market. (We
can package the message differently--but that is starting to get away
from the point I would like to make.)
So on one hand we have the church organization, and there is a strong
tendancy to make it as comfortable as possible for "our kind of
Christian." As I said above, nothing wrong with that if it is confined
to packaging--the way the building is decorated, which hymns we sing,
even the scheduled time for the Sunday service. But we can't lose sight
of the important fundamentals that can't be changed if we still want to
be Christians. (And again the doctrinal differences between various
denominations are way off topic here. But the parallels in programming
languages are on topic in the next paragraph. ;-)
So we have three levels of competing priorities, and it is the job of
the Elders to insure that we get those priorities straight. The rest of
the sermon was about the fundamental conservative nature of any
organization such as a church, and the revolutionary nature to religion
as such.
We have similar levels in programming languages and a similar problem
with organizational conservatism. Notice that there is a need for
conservatism that can't be ignored. Fixing the roof may not be the
primary mission of the church. On the other hand having the building
collapse and kill half the congregation is not acceptable.
In the programming language arena, there are three groups of
"stakeholders." There are those whose responsibility is to keep the
language consistant and usable. There are also current users who don't
want to be forced to learn new features. Finally there are the language
evangelists, who want to use the language in new market segments, and
think that the language would be perfect if the langauge maintainers
would only add a few dozen small changes. ;-)
In programming languages the ultra-conservative role of church doctrine
is the job of the language lawyers. Any major programming language has
a maintenance organization which is by nature very conservative, and
with good reason. If (in the case of Ada) the ARG doesn't do its job
right, the result is not just a loss of users. Languages can be made
unsuitable for their current role, and the result is usually something
similar to a religous schism.
A perfect example of this was Algol 68. It was a huge change from Algol
60, and the net result was a schism. Wirth put his alternate proposal
"on the table" Algol-W, and a large portion of the current Algol 60
users switched to Algol-W and then to Pascal. Algol 68 was a nice
language once decent documentation existed, and several good compilers
were eventually available. But the programmers who wanted to use Algol
68 included very few Algol 60 programmers.
On the other hand if the ARG doesn't keep the language "relevant,"
eventually the user community will wither away to nothing. The Ada
community is currently growing, but not nearly as fast as the overall
demand for programmers. (I should say as fast as the overall demand for
software engineers, but let's keep to one religious war at a time.)
I think that the ARG is maintaining the correct balance. Those who
don't want change are not screaming about the proposed changes in Ada
0Y, and the evangelists are not satisified, but it is their nature to be
unsatisfied.
There will always be those who are unwilling or unable to tolerate the
almost glacial pace of change. Fine. For those people there are
boutique languages and languages du joir. And I am not denigrating that
need. There have been several projects I worked on where we developed
project specific languages. But the toolset we used were based on an
existing major production language, with a set of translation tools for
the modified language.
One good example of a language that started out that way was C++.
Another was Object Ada which added object oriented features to Ada 83.
Object Ada was made obsolete by Ada 95, but C++ is now a separate
language development tree from C. (And it will stay that way. The
market for C is now different enough from the market for C++ as to be
almost disjoint.) Of course for every seed that finds nourishing soil
and grows, hundreds of others fall on barren ground.
But the language evangilists want someone else to do the job of
developing their concept of a perfect language for them. It can never
happen. If they learn how to use the tools, they can develop your own
language and do all the maintenance themselves. Or if they win the
Powerball lottery, they may be able to hire someone to do it for them.
But otherwise it is just a huge job. My guess is that just the Ada 0Y
changes including proposals and reviews will be on the order of a man
century of work. If you want to argue that it is only a couple of man
decades, I hear you and don't. You have to count the effort by current
langauge users to learn the changes, the compiler developers who have to
modify their compilers, the textbook authors who have to update their
texts, and so on. Yes, at the core of all this, between the ARG and
WG9, there are several dozen people who average less than three months a
year working on standards related issues.
However, we can't forget that any changes we agree to will eventually
have a much larger effect on the Ada community as a whole. That is in
part what makes the organizational parts of the Ada community so
conservative. Of course, if there is a bug in the current standard, and
different compilers do different things, then we don't need to be
conservative, and we aren't. We might as well choose whatever is best
in the long run for the Ada community, because the "extra" effort to
understand the problems and the fix is going to have to be spent in any
case.
So if you want Ada to change, be patient. However, if you want any
changes which make the language unacceptable to its current users,
forget it. If you identify a new need that can't be satisifed by any
version of Ada which satisfies current users, go off and do your own
thing. (Or for that matter a new version of C++, C, Pascal or COBOL.)
It won't be the first time. Some such efforts have been drawn back into
the fold, like Object Ada. Others such as VHDL and SPARK identified a
market that was sufficiently different so that the right solution was to
develop separate tool chains. (SPARCK is a "pure" Ada subset, so it can
be compiled by normal Ada compilers. But you also have to run the
source through the SPARK Examiner to have correct SPARK code.)
And I am not trying to "blow off" reasonable extension proposals. I am
just trying to describe the sort of thinking we go through before making
ANY language change. If you just make a three paragraph recommendation
of an idea that looks identical to one that was worked out in minute
detail by the ARG and rejected by WG9, don't be surprised when we say it
won't fly, and don't want to go into details. The details may involve
dozens to hundreds of hours (and pages) of discussions. (You can
usually find them at www.ada-auth.org and if you aren't willing to read
what is there, thoroughly, you can see why I and other ARG members
sometimes get frustrated.
Dmitry A. Kazakov
>Thanks very much to everyone for the interesting info. It made me look
>more closely at Ada. It looks like it is indeed one of the safest
>languages among the ones that aren't garbage collected, which probably
>makes it suitable for programming things like airplanes, etc.:
>
>1. hard real-time
>2. bug-averse
>3. not very performance demanding (don't know about other compilers,
>but they say GNAT produces slow executables)
>
>However, it does not look like it's a good match for me, since my
>needs are the exact opposite:
>
>1. no real time
This is easy in Ada:
loop
null;
end loop;
-- The rest won't meet any deadline!
>2. bugs welcome (but not wrong results) - lusers will not come near my
>programs
It is easy to write a virus program scanning your source codes and
randomly sowing them with bugs, if you so enjoy them...
>3. performance is highly important
GNAT is a front end of GNU C...
--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de
David Rasmussen
> 3. not very performance demanding (don't know about other compilers,
> but they say GNAT produces slow executables)
>
Who says that? Ada can be at least as fast as C++.
/David, writing from comp.lang.c++
Martin Dowie
news:vjah20tahj48fftkp...@4ax.com...
> >3. performance is highly important
>
> GNAT is a front end of GNU C...
Not quite...
...they share a back-end - GNAT does NOT translate Ada source into C as an
intermediate.
Martin Dowie
news:c0aa3o$i3t$1...@news.net.uni-c.dk...
> MSG wrote:
> > 3. not very performance demanding (don't know about other compilers,
> > but they say GNAT produces slow executables)
> >
>
> Who says that? Ada can be at least as fast as C++.
Different implementations of any language will produce
different results. Also, where one compiler may do a
good job with float point arithmetic, it may be lousy at
optimising.
The important thing is that there is nothing in the language
definition that _requires_ it to produce 'slow' code. One
of the design aims for Ada95 was to actually introduce
new language constructs that would actually allow faster
code to be produced, while retaining the reliability, ease
of maintenance, etc.
christo...@eurocopter.com
> but they say GNAT produces slow executables)
Where do you get this nonsense from? Who is "they". They say a lot of nonsense
out there, not only about languages, about everything :-(
Ask Robert Dewar (the "father" of Gnat). He'll tell you that Ada and C will
produce the same target code when you take care to switch off all (Ada)
compiler-generated checks (and the source code is "comparable" of course).
The part in parentheses is to make sure you do not compare apples and oranges.
How could it be otherwise, because Ada is used for hard real-time (I've been
using it in this realm for nearly two decades now).
From: "Dmitry A.Kazakov" <mai...@dmitry-kazakov.de>
> >3. performance is highly important
>
> GNAT is a front end of GNU C...
That's not true. GCC means Gnu Compiler Collection and Gnat directly compiles to
intermediate format as does C, and not to C.
Gnat stands for Gnu Ada Translator, and Translator stands for Compiler, because
they felt Gnac does not sound nice.
So Translator does _not_ mean: Translate first to C.
Marin David Condic
> 3. not very performance demanding (don't know about other compilers,
> but they say GNAT produces slow executables)
>
and found its performance to be as good as most other languages compiled
for PCs or workstations. It is, after all, just a different front end to
the gcc compiler and so the code generation is as good as for Gnu C and
the other languages it supports. (As always, you need to know how to use
the compiler to get optimal results. That's true no matter what language
you're talking about.)
BTW: I use Ada all the time for hard real time systems and its
performance is as good or better than other languages routinely used to
do similar jobs. I have very demanding timing requirements and very old,
slow processors. If you get a good quality embedded Ada compiler, it
works just fine. The "language" can't be slow if good quality
implementations exist to prove the opposite.
So before you go reacting to rumors, I'd suggest you actually look at
some facts about Ada. You might even get yourself some benchmark
algorithms and test it out. That would be the scientific thing to do.
Believing in unsubstantiated rumors is a little like believing in
fairies & pixies because you heard someone tell a story about them.
MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm
Send Replies To: m o d c @ a m o g
c n i c . r
"Face it ladies, its not the dress that makes you look fat.
Its the FAT that makes you look fat."
-- Al Bundy
======================================================================