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
======================================================================
Marin David Condic
>>
>>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.
>
the portion of the compiler that parses the source language into some
intermediate form. I didn't get the impression that anyone was implying
that Gnat translated Ada into C then invoked the gcc compiler on it. If
that was the claim - its probably a troll. ("Hey, let's go see if we can
get those Ada guys screaming about how Gnat doesn't translate into C
again!" :-)
Dmitry A. Kazakov
Yes of course, GNU C is just a name of a set of compilers. Important
is that the back-end is same, so it is unlikely for GNAT to be slower
than GNU C. Theoretically Ada as a language should allow better
optimization than C.
Martin Dowie
> >Not quite...
> >...they share a back-end - GNAT does NOT translate Ada source into C as
an
> >intermediate.
>
> Yes of course, GNU C is just a name of a set of compilers. Important
> is that the back-end is same, so it is unlikely for GNAT to be slower
> than GNU C. Theoretically Ada as a language should allow better
> optimization than C.
For total pedantry, GCC is the name for the set of compilers, GNU C is
one element in this set.
Robert I. Eachus
> 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.
Not quite true. There was an infamous feature in Ada 83 that seemed to
require "extra" copies of vectors on certain vector processing CPUs
without precise error checking.
I remember one time when a compiler developer for a manufacturer of such
vector processing supercomputers called with a complex question about
what was required and what wasn't. We had a long discussion and she
concluded that she could use the current Fortran back-end rules except
for one case.
After she hung up, what she had said percolated through my head, and I
e-mailed a short Fortran example. Sure enough it produced garbage. So
yes, Ada 83 required that you not produce garbage output. The Ada 95
rules may be somewhat different, but they still require that you make
temporary copies when the alternative is junk results. In fact, where
the Ada 83 and Ada 95 rules are different is that, in Ada 83, programs
that discarded their results were still required to get the right answer
in some cases. In Ada 95, you can compute wrong answers if the
externally visible behavior of the program doesn't change. ;-)
Ed Falis
wrote:
> People do not select their programming tools as wisely as they select
> their
> carpentry
> tools.
While I don't disagree with the thrust of your comments, this one is off.
In woodworking and carpentry, there are many ways to get a specific task
done, and the choice of tool is often personal preference, just as it is
for programming language.
- Ed
Mark McIntyre
<martin...@btopenworld.com> wrote:
stuff.
Can you take comp.lang.c off the crossposts. this has wandered miles away
from topicality, even if it were near in the first place....
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Alexandre E. Kopilovitch
> > ... 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.
Yes. And they provide a multitude of convenient patterns for those favored
ways.
> 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.
Actually you need not *accept* that foreign viewpoint as a "proper" or "true"
one for you, but you should become aware of its essense and its relationships
with various facts, events, doctrines etc. And yes, you need to admit that
that viewpoint is viable and somehow appropriate for its native environment
and circumstances. No more than that. That should not be destructive for your
own worldview... if you don't think that the latter is definitely better than
all others and therefore should be propagated everywhere and dominate over all
those inferior others.
By the way, nowadays the English language is very interesting in this
aspect - because there is a clear choice between two possible viewpoints for
this language: American and British (in alphabetical order -:) . These are
certainly different viewpoints, and a learner has to choose between them.
> The cultural baggage with Arabic and Chinese is
> larger that that which comes with French, but it isn't as imperialistic.
This sentence seems quite strange... well, not exactly. I can't believe that
you know so much about Arabic or Chinese culture that you can estimate whether
or not it is imperialistic. After all, most of their cultural baggages (which
are large, as you said) were created during their corresponding Imperial ages.
Not knowing French (as you said) you certainly can't judge French cultural
baggade in this aspect as well. But you did that, and there is a clear cause
for that - you see French as the most important center of resistance against
worldwide propagation of American viewpoint. Well, I think that this feeling
is quite correct, and this is why recently I gradually become interested in
learning French (there are, and always were other reasons of course, but this
new additional one has a chance to be decisive).
> 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, I have found
> that there is a huge difference in world view between those Japanese who
> speak English and those who don't,
This passage about Japanese vividly reminds me the following anecdote:
----------
A Pan Am 727 flight engineer waiting for start clearance in Munich overheard
the following:
Lufthansa (in German): Ground, what is our start clearance time?"
Ground (in English): "If you want an answer you must speak English."
Lufthansa (in English): "I am a German, flying a German airplane, in Germany.
Why must I speak English?"
Unknown voice (in a beautiful British accent): "Because you lost the bloody
war!"
----------
> 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.
I can't speak for Germanic languages, but for Russian I tend to agree. Yes,
I don't think that Russian, as a language, is substantially associated with
any specific viewpoint. (But its Soviet flavour certainly was... I hope it is
obvious.)
But just one external observation about Germanic languages: although it may
be true that the whole family of Germanic languages isn't substantially
associated with any particular viewpoint, this seems to be false for one
particular area, and the corresponding language flavour: Austria. It seems
that there, in Austria, some coherent viewpoint was present (I don't know
whether it is still alive).
August Derleth
GNU C is also used to refer to a nonstandard (extended and modified)
version of C compiled by the GNU Project's C compilers in a
non-conformant mode. A notable extension provided by GNU C over standard
C is the existence of functions that are private to another function,
and are defined within the function they are private to.
An example:
int foo(int x)
{
int bar(int y)
{
return y % 2;
}
int z = bar(x);
return z + 2;
}
That is a compilable GNU C program, and it behaves such that bar() is
not visible outside foo(). It is not conformant to any relevant standard
(as far as I know).
--
My address is yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
Note: Rot13 and convert spelled-out numbers to numerical equivalents.
MSG
[...]
> >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...
What I meant was of course that I don't place as much emphasis on
these as, say, Boeing does, and so all other factors in language
choice become relatively more important to me.
> >3. performance is highly important
>
> GNAT is a front end of GNU C...
Can you write (*) a matrix multiplication routine in Ada, compile it
with GNAT and measure the number CPU cycles per FLOP, compare to a
similar routine in C?
The shootout seems to put GNAT closer to Perl and Java than to C/C++.
Cheers,
MSG
(*) Only if you think the one on the shootout page is inadequate.
James Rogers
> Can you write (*) a matrix multiplication routine in Ada, compile it
> with GNAT and measure the number CPU cycles per FLOP, compare to a
> similar routine in C?
> The shootout seems to put GNAT closer to Perl and Java than to C/C++.
The shootout numbers I saw put vc at .07, gcc at 0.10 and GNAT at .20.
Java was 0.73 and Perl was 34.31.
I do not see how .2 is closer to .7 or 34 than it is to .1.
Your mathematics seems seriously flawed.
Please explain your reasoning.
Jim Rogers
Dmitry A. Kazakov
>Dmitry A. Kazakov <mai...@dmitry-kazakov.de> wrote in message news:<vjah20tahj48fftkp...@4ax.com>...
>> On 9 Feb 2004 18:26:33 -0800, msg...@yahoo.com (MSG) wrote:
>> >
>> >3. performance is highly important
>>
>> GNAT is a front end of GNU C...
>
>Can you write (*) a matrix multiplication routine in Ada, compile it
>with GNAT and measure the number CPU cycles per FLOP, compare to a
>similar routine in C?
There is a problem with that. C does not have arrays. Yet matrices,
you know, are two-dimensional ones. So any comparison here would be
suspicious. A program in C, supposed to multiply matrices would lack
ADT abstraction layer. It is well possible to write something similar
in Ada, using pointers instead of arrays etc. (After all true
programmer can write a FORTRAN program in Pascal, if I correctly quote
the famous sentence) Such a program with all checks surpressed will
take the same number of CPU cycles. But who might be interested in
such comparison?
Note that presence of an abstraction per se does not mean performance
penalty. The effect could be quite opposite. The difference between C
and Ada is that in C you almost cannot express intention. It is too
low-level language. You just order the compiler to do something and it
obeys. This may result in slower code, because the compiler should
deduce that:
char * t;
char * s;
while (*t++ = *s++);
is in fact to copy a string. If it would, it could then apply a
corresponding target CISC machine instruction. In Ada it is easier for
the compiler:
T : String (...);
S : String (...);
T := S;
Even if you work at the array abstraction level:
for I in S'Range loop
T (I) := S (I);
end loop;
there is a lot of useful information for the compiler here, much more
than in pointer increments and dereferencings. Note also, that by
using pointers you commit yourself to only the objects which can be
referenced by a pointer. This might be a heavy burden on some
machines. Compare this with Ada, where you have to *explicitly*
specify that an object is aliased (a subject of referencing). If you
don't, the compiler is free to move such objects to registers, cache,
an external matrix processing unit etc.
Even if GNAT might not use all that, it is at best a GNAT problem, not
one of Ada.
Jerry Coffin
kris...@users.sourceforge.net says...
[ ... ]
> Shure you can. Ada invented templates long bevore C++ was even though of.
It's clearly true that Ada had generics before C++ did, but not (it
would appear) before Bjarne had started to come up with the ideas for
what eventually came to be known as C++. In point of fact, Bjarne seems
to have started working toward C++ around the time of the Ironman
document, which clearly predates the final Ada design.
Ada didn't invent generic programming either -- just for example, Lisp
has supported generic programming (to some degree or other) since about
1959 or so. Many have argued over how sanitary all its facilities are,
but the fact remains that the basic idea clearly predates Ada by quite a
wide margin.
> Ada templates are far more powerfull then C++.
Experience tends to indicate otherwise. In point of fact, Alexander
Stepanov had a great deal of input into the design of templates in C++,
largely because Ada generics didn't support what he wanted.
Other large projects have reflected the same difference. Just for
example, the Booch components started out in Ada 83, got ported to C++,
and then ported back to Ada (95). The original Ada version was ~125,000
lines of code. The C++ version was about 12,000 lines of code.
It's easy to find estimates that the Ada 95 version should be about
10,000 lines of code. For better or worse, these seem to be incorrect:
the current version of BC for Ada 95 seems to some out somewhere between
15,000 and 18,000 non-comment, non-blank lines of code. I haven't had
the time to go through in detail, but it _appears_ that even so, there
are still some missing pieces. I think it's also worth noting that C++
templates have changed (and understanding of them has improved)
considerably since the Booch components were ported to C++. If the same
job were being done today, line counts and such would undoubtedly be
somewhat different.
I AM reasonably convinced, however, that Ada generics are more
_accessible_, so they provide more power to a typical programmer. Using
more than a fraction of the capabilities of C++ templates requires
substantially more study.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Jerry Coffin
says...
[ ... ]
> 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.
Since you're cross-posting to c.l.c++, perhaps you'd have the kindness
to also check this as a C++ program. If you do so, you'll find that
either the program is rejected, or else your C++ compiler is drastically
broken.
If you insist on only compiling it as C, at least use a good compiler.
Comeau C (for one example) produces the following in C mode:
"enum.c", line 6: warning: enumerated type mixed with another type
P (42); // no compiler check!
^
> This means that only a human carefully reviewing this program will see
> the mistake
A fundamental mistake: assuming that one compiler's inferiority means
something about the language itself, or even about other compilers.
> (you may also try lint, but this is a tool external to the
> language and based on heuristics, not language rules).
I'd use a C++ compiler, and know that it was simply enforcing a
requirement of the language. As you can see above, even if I compiled
it as C, it would be found.
> 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.
...and there's the complacency typical of all too many Ada programmers!
A properly functioning Ada compiler will catch _this_ stupid mistake
just as well as a C++ compiler will -- but assuming that means it will
catch all such stupid mistakes is taking a leap well beyond reality.
Jerry Coffin
jimmaure...@att.net says...
[ ... ]
> I think you will find, if you look into hard real-time systems,
> that performance is critical.
I've looked. It's usually not. For real-time systems, the primary
requirement is usually for absolute predictability, NOT for maximum
performance.
> 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.
Using Java as a standard of comparison is a tacit admission of a major
problem.
> 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).
The last time I checked, GNAT uses the same back-end as the other GNU
compilers, so if it doesn't produce as good of code, it's a strong
indication of a performance problem in the language proper.
> 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.
Any statement that attempts to characterize all C++ (or Java or Ada)
programmers as having the same priorities as each other is bound to be
false.
Worse, there's a tendency to overcompensate for perceived weaknesses at
the expense of perceived strengths. Thinking of error reporting as a
weakness, many C++ programmers frequently put tremendous work into it.
Conversely, many C++ programmers take execution speed so much for
granted that they write horribly inefficient code on the assumption that
the compiler can (and will) make up for whatever they do.
Though I don't work with as many Ada programmers on as regular a basis,
it appears to me that many do more or less the opposite: it's so widely
assumed that the compiler will catch almost all errors, that many
blithely assume that almost anything that compiles MUST be correct. At
the same time, execution speed has been perceived as a problem often
enough that many knowingly and intentionally subvert type-checking and
such, on the assumption that it's necessary to get the speed they think
they need to be competitive.
Without trying to take this too far, the result is that in _many_ cases,
what are widely perceived as strengths or weaknesses of particular
languages often end up being almost exactly the opposite of what's
really the case. In the end, nearly all the factors being discussed
depend far more on the programmer than the language, so complacency is
common but rarely justified.
Chad R. Meiners
"Jerry Coffin" <jco...@taeus.com> wrote in message
news:MPG.1a93b6629...@news.clspco.adelphia.net...
> In article <Xns948AC8C8E553E...@204.127.36.1>,
> jimmaure...@att.net says...
>
> [ ... ]
>
> > I think you will find, if you look into hard real-time systems,
> > that performance is critical.
>
> I've looked. It's usually not. For real-time systems, the primary
> requirement is usually for absolute predictability, NOT for maximum
> performance.
Performance can be critical while not being the primary requirement.
> > 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.
>
> Using Java as a standard of comparison is a tacit admission of a major
> problem.
He was talking about the GNAT of the past gone by (most likely predating
1996), when the compiler was still young and produced relatively slow code.
> > 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).
>
> The last time I checked, GNAT uses the same back-end as the other GNU
> compilers, so if it doesn't produce as good of code, it's a strong
> indication of a performance problem in the language proper.
You should make sure that you are comparing the same back end version for
each compiler. For instance GNAT 3.15p uses the gcc 2.8.1 backend for
stability reasons.
> Though I don't work with as many Ada programmers on as regular a basis,
> it appears to me that many do more or less the opposite: it's so widely
> assumed that the compiler will catch almost all errors, that many
> blithely assume that almost anything that compiles MUST be correct. At
> the same time, execution speed has been perceived as a problem often
> enough that many knowingly and intentionally subvert type-checking and
> such, on the assumption that it's necessary to get the speed they think
> they need to be competitive.
However, from my personal experience it appears to me that MOST Ada
programmers don't suffer from such unwise beliefs. (Many Ada programmers
could be as little as one; Most Ada programmers implies the majority)
> Without trying to take this too far, the result is that in _many_ cases,
> what are widely perceived as strengths or weaknesses of particular
> languages often end up being almost exactly the opposite of what's
> really the case. In the end, nearly all the factors being discussed
> depend far more on the programmer than the language, so complacency is
> common but rarely justified.
Of course you need a competent and vigilant programmer; however, language
design does affect the effectiveness of this programmer so it does not just
boil down to finding good programmers.
-CRM
Marin David Condic
>
> I've looked. It's usually not. For real-time systems, the primary
> requirement is usually for absolute predictability, NOT for maximum
> performance.
>
Yes, *predictability* is essential and that's more an algorithmic issue
rather than a language issue. However, don't believe for a moment that
we don't sweat bullets over *speed* as well. When you have things that
*must* finish in a millisecond and leave something to spare you worry
about compiler efficiency quite a lot. Embedded, avionics quality
compilers are typically stressing efficiency over other attributes (like
related support tools). I've used and do use Ada compilers that are as
good or better than those for other languages.
>
> The last time I checked, GNAT uses the same back-end as the other GNU
> compilers, so if it doesn't produce as good of code, it's a strong
> indication of a performance problem in the language proper.
>
Having used Gnat quite a bit, I'd like to know what you think it does
that is slow. I'd be interested in some benchmark code that Gnat does
inefficiently in comparison to similar code in C passed through gcc.
Given that I regularly use high quality Ada compilers for hard realtime
work and have been more than satisfied with the resultant efficiency of
the code, I'd have to say that your "strong indication of a performance
problem in the language proper" is essentially disproven by example. Its
an old cannard that gets regularly dragged out because people have this
tendancy to believe unicorn stories. "My brother knows this guy who had
a friend wo worked with this guy who used to use Ada 20 years ago and he
said that Ada is slow, so it *must* be true..."
>
> Though I don't work with as many Ada programmers on as regular a basis,
> it appears to me that many do more or less the opposite: it's so widely
> assumed that the compiler will catch almost all errors, that many
> blithely assume that almost anything that compiles MUST be correct. At
I work with lots of Ada programmers in a place where failure is not an
option. We *never* blithely assume that if it compiles, its correct. We
spend lots of time and money testing. However, in studies I've done of
errors in Ada code versus that in other languages, you typically get a)
fewer of them and b) of a different class. We used to get all sorts of
errors relating to scalings on numeric values and similar sorts of
problems that relate closely to type checking. Now, those errors all but
disappear.
We still have errors - but they tend to be more along the lines of
*logic* errors. No language can save you from that. The net result is
that we save lots of money in not having to rework code and regression
test it all because of relatively small problems that the compiler can
catch for us. Everyone who studies "process" knows that the sooner you
catch a problem in the production chain, the cheaper it is to fix.
> the same time, execution speed has been perceived as a problem often
> enough that many knowingly and intentionally subvert type-checking and
> such, on the assumption that it's necessary to get the speed they think
> they need to be competitive.
>
There's no way that runtime checks aren't going to cost *something*.
However, in most apps, the cost isn't so high as to be prohibitive. When
I build PC based apps in Ada, all the checks are left on and though
there must be a performance hit in there somewhere, its really hard to
see these days given the speed of your garden variety microprocessor.
For 90% of apps it should fall below the noise floor and not matter. For
the relatively *small* number of apps (and usually only in some critical
places within those apps) that have a performance issue, sure - go ahead
and turn off checks. You still get the static checks and that covers a
lot of ground. It seems to be a non-issue to me.
Marin David Condic
nothing but assembly language instructions, I'd be confident that one
could build Ada code that is just as fast as anything produced by any
compiler anywhere. So if one wants to get into high-speed shootouts
between languages, a ground rule has to be that you're comparing similar
code.
If an Ada example uses a high level abstraction of a matrix and C can't
do that sort of abstraction, then C can't play in that game. If the C
example uses some raw chunk of memory and address arithmetic, then the
Ada example would need to be coded up in that style as well (and yes,
that can be done - but nobody who uses Ada typically *wants* to. :-)
Only if you have similarly coded examples can you possibly hope to
determine if one compiler is more efficient than another.
MDC
Dmitry A. Kazakov wrote:
>
> There is a problem with that. C does not have arrays. Yet matrices,
> you know, are two-dimensional ones. So any comparison here would be
> suspicious. A program in C, supposed to multiply matrices would lack
--
Ole-Hjalmar Kristensen
> Given that it is 100% legal Ada to build a procedure that contains
> nothing but assembly language instructions, I'd be confident that one
> could build Ada code that is just as fast as anything produced by any
> compiler anywhere. So if one wants to get into high-speed shootouts
> between languages, a ground rule has to be that you're comparing
> similar code.
>
> If an Ada example uses a high level abstraction of a matrix and C
> can't do that sort of abstraction, then C can't play in that game. If
> the C example uses some raw chunk of memory and address arithmetic,
> then the Ada example would need to be coded up in that style as well
> (and yes, that can be done - but nobody who uses Ada typically *wants*
> to. :-)
> Only if you have similarly coded examples can you possibly hope to
> determine if one compiler is more efficient than another.
>
> MDC
Yes, but there are some caveats. Ada insists on getting floating point
arithmetic "right", so it will typically do it differently than C,
even though the Ada and C programs superficially look the same. For
floating-point intensive programs, this may result in quite a
performance hit. I recently ported a small ray-tracing kind of
application from C to Ada, keeping largely to the structure of the
original program, but using sensible Ada constructs where appropriate.
First I verified that it indeed worked the same as the original, then
turned off all checks and compiled both versions with -O3 and
-funroll-all loops. The Ada version was slower by a factor of
2.
Profiling showed that much of the time was spent in sqrt() and other
math functions. Next, I imported the necessary functions from the C
library and used those instead. This resulted in Ada and C versions
which ran at the same speed. Some slight algorithmic optimizations
later, the Ada version was approximately 20% faster than the C
version. Profiling again, I found that about 10 seconds of a total of
40 seconds runtime was consumed in the truncate function. An inlined
assmbler version of this reduced the time spent in truncate to 1-2
seconds, which was more reasonable.
Note that neither the C version nor the Ada version are anywhere close
to the limit in terms of speed, using the short vector instructions of
the processor, I could probably get an overall speedup by a factor of
2-3 for this particular application if coded in assembler.
>
> Dmitry A. Kazakov wrote:
> > There is a problem with that. C does not have arrays. Yet matrices,
> > you know, are two-dimensional ones. So any comparison here would be
> > suspicious. A program in C, supposed to multiply matrices would lack
>
> --
> ======================================================================
> 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
>
> ======================================================================
>
--
C++: The power, elegance and simplicity of a hand grenade.
Pat Rogers
[snip]
> Other large projects have reflected the same difference. Just for
> example, the Booch components started out in Ada 83, got ported to
> C++, and then ported back to Ada (95). The original Ada version was
> ~125,000 lines of code. The C++ version was about 12,000 lines of
> code.
Neither the design of the C++ version of the Ada 83 BCs, nor that of
the Ada 95 version, corresponded to the design of the Ada 83 version.
It is useless to compare the numbers of different designs.
Xenos
> On 10 Feb 2004 18:19:13 -0800, msg...@yahoo.com (MSG) wrote:
>
> is in fact to copy a string. If it would, it could then apply a
> corresponding target CISC machine instruction. In Ada it is easier for
> the compiler:
>
> T : String (...);
> S : String (...);
>
> T := S;
>
> Even if you work at the array abstraction level:
>
> for I in S'Range loop
> T (I) := S (I);
> end loop;
>
T'Length or it will raise a constraint_error. The second will only work if
T'Length is greater than or equal to S'Length.
DrX
Preben Randhol
> But of course, the first example will only work if S'Length is equal to
> T'Length or it will raise a constraint_error. The second will only work if
> T'Length is greater than or equal to S'Length.
Yes, you won't get a buffer overflow.
Preben
--
"When Roman engineers built a bridge, they had to stand under it while
the first legion marched across. If programmers today worked under
similar ground rules, they might well find themselves getting much
more interested in Ada!" -- Robert Dewar
Xenos
"Preben Randhol" <randhol+valid_fo...@pvv.org> wrote in
message
news:slrnc2kn4d.aav.randhol+v...@k-083152.nt.ntnu.no...
>
> Yes, you won't get a buffer overflow.
>
constraint_error.
DrX
Preben Randhol
Not in C.
But you cut that example out.
--
"Saving keystrokes is the job of the text editor, not the programming
language."
Robert I. Eachus
I said:
>>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.
>
> This sentence seems quite strange... well, not exactly. I can't believe that
> you know so much about Arabic or Chinese culture that you can estimate whether
> or not it is imperialistic. After all, most of their cultural baggages (which
> are large, as you said) were created during their corresponding Imperial ages.
> Not knowing French (as you said) you certainly can't judge French cultural
> baggade in this aspect as well. But you did that, and there is a clear cause
> for that - you see French as the most important center of resistance against
> worldwide propagation of American viewpoint. Well, I think that this feeling
> is quite correct, and this is why recently I gradually become interested in
> learning French (there are, and always were other reasons of course, but this
> new additional one has a chance to be decisive).
I think you misunderstood. I speak French well enough to get along, in
both Paris and Quebec--although my accent is hardly Parisian. But I
can't fit my thoughts inside the language imposed worldview. So when I
am speaking French I am thinking in English then translating. (I don't
have to go through that step when listening.) It has been awhile since
I studied Chinese, long enough that the new transliterations still seem
strange. And I suspect I would feel more at home in Taiwan than
mainland China.
>>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, I have found
>>that there is a huge difference in world view between those Japanese who
>>speak English and those who don't,
>
> This passage about Japanese vividly reminds me the following anecdote:
>
> ----------
> A Pan Am 727 flight engineer waiting for start clearance in Munich overheard
> the following:
>
> Lufthansa (in German): Ground, what is our start clearance time?"
>
> Ground (in English): "If you want an answer you must speak English."
>
> Lufthansa (in English): "I am a German, flying a German airplane, in Germany.
> Why must I speak English?"
>
> Unknown voice (in a beautiful British accent): "Because you lost the bloody
> war!"
And the French pretend they were on the winning side, rather than losing
early, being occupied for years, and then liberated by the Allies. ;-)
In fact in French, it is hard to think of French military history as
other than glorious.
> I can't speak for Germanic languages, but for Russian I tend to agree. Yes,
> I don't think that Russian, as a language, is substantially associated with
> any specific viewpoint. (But its Soviet flavour certainly was... I hope it is
> obvious.)
>
> But just one external observation about Germanic languages: although it may
> be true that the whole family of Germanic languages isn't substantially
> associated with any particular viewpoint, this seems to be false for one
> particular area, and the corresponding language flavour: Austria. It seems
> that there, in Austria, some coherent viewpoint was present (I don't know
> whether it is still alive).
Sure in Austria there is a consistent world view: Austrian beer is
better than any other beer, including German. ;-) Seriously the
Austrian culture is very relaxed compared to northern Germany. But I
spent a couple years in Bavaria, and the culture there seemed very
similar to Austria. (In fact, I think that southern German is still
more religious and fun loving than Austria, but compared to northern
Germany, the difference is relatively minor.)
All this is sort of very off topic for this newsgroup, with one
exception. The languages that we discussed as not imposing world views
seem to be required learning at a young age (usually as a "milk tongue")
to be any good at building compilers and designing programming
languages. (There are some excellent language designers in France, but
they all seem to speak fluent English. So it may be that if French is
your milk tongue you can learn another language later, and still commit
language design.) I have often felt that this was due to some spoken
languages being easily extensible, and others forcing you into another
language if you want to add a new concept. The two extremes seem to be
English and Japanese.
All popular programming languages seem to have an English heritage. In
fact it is almost surprising that there are a few languages with more of
a British background than American. (Algol, especially Algol 68, and
Coral 66 come to mind.) There have been a few German and Russian
programming languages, but none has made it into the mainstream. There
have been a few languages from non-English speaking areas. SIMSCRIPT
has a Scandinavian heritage. However, it is hard to contend that
English is not the primary language in some areas of Scandinavia. Wirth
who designed Pascal and Algol-W among other languages, was Dutch. But
all those languages have a clear English heritage (and documentation).
Rob Thorpe
...
> 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;
> }
In C enums are interchangable with ints so there is no error, though
there maybe the compiler should give a warning.
A C++ compiler should check
I got:
bash-2.05b$ g++ -Wall fiddle.cpp
fiddle.cpp: In function `int main()':
fiddle.cpp:6: error: invalid conversion from `int' to `assessment_t'
Georg Bauhaus
: Seriously the
: Austrian culture is very relaxed compared to northern Germany.
Interesting that you see it this way. There are many
who say it is the other way.
: (In fact, I think that southern German is still
: more religious and fun loving than Austria, but compared to northern
: Germany, the difference is relatively minor.)
Just a different sort of humor (and religious history).
: All this is sort of very off topic for this newsgroup,
as is probably the assumption that "The Protestant Ethic and the
Spirit of Capitalism" (articulately present in Bill Gates and
co-workers) might have to do with inventing computer languages
and tools, directly or indirectly :-)
: Wirth
: who designed Pascal and Algol-W among other languages, was Dutch.
(Uhm, he seems to be from Winterthur in Switzerland. Though Dijkstra was
from the Netherlands.)
Xenos
> Not in C.
>
> But you cut that example out.
>
DrX
Martin Dowie
> compilers, so if it doesn't produce as good of code, it's a strong
> indication of a performance problem in the language proper.
No, it could be an indication of a problem in the front-end - but any such
inefficiency need not be *required* by the language standard.
[snip]
> Though I don't work with as many Ada programmers on as regular a basis,
> it appears to me that many do more or less the opposite: it's so widely
> assumed that the compiler will catch almost all errors, that many
> blithely assume that almost anything that compiles MUST be correct.
I do and I'm not sure that's true but YMMV.
> Without trying to take this too far, the result is that in _many_ cases,
> what are widely perceived as strengths or weaknesses of particular
> languages often end up being almost exactly the opposite of what's
> really the case. In the end, nearly all the factors being discussed
> depend far more on the programmer than the language, so complacency is
> common but rarely justified.
I agree with this. For example, I know lots of engineers who worry about
context switch times and function call overheads, but on today's processors,
these are unlikely to be a major problem - cache paging on the other hand...
-- Martin
Ludovic Brenta
> And the French pretend they were on the winning side, rather than
> losing early, being occupied for years, and then liberated by the
> Allies. ;-)
> In fact in French, it is hard to think of French military history as
> other than glorious.
Aye. This was a myth invented by Winston Churchill so that Great
Britain wouldn't be the only dwarf between the US, Soviet and Chinese
giants. De Gaulle encouraged this myth because he wanted to avoid a
civil war between former Resistants and former Collaborators. Both
good reasons, IMHO, and it actually worked for the intended purposes,
but still a myth, and there are those who recognise it as such. (and
before anyone asks: I am French).
> Sure in Austria there is a consistent world view: Austrian beer is
> better than any other beer, including German. ;-)
Surely you haven't tasted Belgian beer. Next time you're in Brussels,
give me a call and I'll treat you to some :)
> All this is sort of very off topic for this newsgroup, with one
> exception. The languages that we discussed as not imposing world
> views seem to be required learning at a young age (usually as a "milk
> tongue") to be any good at building compilers and designing
> programming languages. (There are some excellent language designers
> in France, but they all seem to speak fluent English. So it may be
> that if French is your milk tongue you can learn another language
> later, and still commit language design.)
French grammar is horrendously complex; you need a very Cartesian mind
to master it. At the same time, it and the vocabulary allow all kinds
of nuances (you can convey different ideas by just swapping words, for
example). Latin is also very good for forming such minds.
> All popular programming languages seem to have an English heritage.
> In fact it is almost surprising that there are a few languages with
> more of a British background than American. (Algol, especially Algol
> 68, and Coral 66 come to mind.) There have been a few German and
> Russian programming languages, but none has made it into the
> mainstream. There have been a few languages from non-English speaking
> areas. SIMSCRIPT has a Scandinavian heritage. However, it is hard to
> contend that English is not the primary language in some areas of
> Scandinavia. Wirth who designed Pascal and Algol-W among other
> languages, was Dutch. But all those languages have a clear English
> heritage (and documentation).
All this is, I think, not so much "Because [we] lost the bloody war"
as because "the US won the war" :)
BTW, Jean Ichbiah is French and he led the origigal Green (then Ada)
design team. Quite a good ilustration of your point.
--
Ludovic Brenta.
Martin Dowie
> If you insist on only compiling it as C, at least use a good compiler.
> Comeau C (for one example) produces the following in C mode:
>
> "enum.c", line 6: warning: enumerated type mixed with another type
> P (42); // no compiler check!
> ^
> > This means that only a human carefully reviewing this program will see
> > the mistake
>
> A fundamental mistake: assuming that one compiler's inferiority means
> something about the language itself, or even about other compilers.
That's all well and good but where in the C standard is it required to
produce a warning?.. That's the bottom line - what one language throws
out as an error, another may say nothing and then the user is left to the
vagaries of what a particular vendor offers.
Chris Torek
might be even more appropriate. The article quoted first below is
not available to me so I have only the quotes themselves.)
>Ludovic Brenta <ludovic...@insalien.org> wrote in message
>news:<m3fzdly...@insalien.org>...
>> 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;
>> }
In article <news:1a61f7e5.0402...@posting.google.com>
Rob Thorpe <robert...@antenova.com> writes:
>In C enums are interchangable with ints so there is no error, though
>there maybe the compiler should give a warning.
More precisely, while "enum" <typename> "{" <id-list> "}" defines
a new enumerated type, the members of the id-list are simply ordinary
integral constants, and the enumerated type is "compatible with"
an integral type (which one is not specified, and different enums
might choose different integral types, so that a "small" enum is
stored in a char while a "big" one uses an int). As such, enum
types are not as useful as one might hope.
Note that the "typedef" keyword is a red herring: as with so many
of C's keywords, it means the opposite of what it claims. :-) In
this case it means "do not define a new type named assessment_t;
define assessment_t as an alias for the type this identifier would
have if this were not a typedef". For instance, "typedef int A,
*B;" makes A a synonym for "int" and B a synonym for "int *".
C's most useful type-definer is actually the "struct" keyword, which
is perhaps best thought of as standing for "STRange spelling for
User-defined abstraCt Type". (Or you can just read it as a weird
way to spell the word "type". All new types are thus record types.)
The sequence:
struct assessment_t { int value; };
defines a new type named "struct assessment_t", after which:
void P(struct assessment_t A) { }
int main(void) {
P(42); /* draws a diagnostic */
return 0;
}
To get constants of type "struct assessment_t" requires C99:
#define AS_T_YES ((const struct assessment_t) { 42 })
#define AS_T_NO ((const struct assessment_t) { 99 })
#define AS_T_MAYBE ((const struct assessment_t) { 1 })
#define AS_T_MAYBE_NOT ((const struct assessment_t) { -1 })
Of course, these macros live in a largely-uncontrolled name space
(their scope starts after the #define and ends only at the end of
the translation unit or a corresponding #undef).
Note that the "obvious" method of defining constants:
const struct assessment_t AS_T_YES = { 42 };
does not define a constant at all, because in C (but not C++), the
"const" keyword, in keeping with tradition :-) , means "do not
define a constant; instead, make this ordinary variable read-only".
On the other hand, one can use pointers to application-wide read-only
variables as a way to fake constants, but then P() needs to take
a "struct assessment_t *". C99's aggregate constructors are probably
better, where available.
(The "const" in the aggregate constructor constants above tells
the C compiler that it is allowed to use a single, read-only object
to store the resulting aggregate, if its address is taken. If the
address is never taken the "const" is not really required, but it
could generate slightly better code on some compilers. The need
to take aggregates' addresses arises because of C's peculiar
treatment of arrays.)
(Ada folks reading this might get the impression that I dislike C.
This is not the case -- I just think it is "so ugly it's cute", as
it were, the way a former girlfriend of mine thought of various
animals. But there is no denying that C is full of sharp edges
and odd mannerisms, and that it is easier to get good compile-time
testing with Ada.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Robert I. Eachus
> Can you write (*) a matrix multiplication routine in Ada, compile it
> with GNAT and measure the number CPU cycles per FLOP, compare to a
> similar routine in C?
> The shootout seems to put GNAT closer to Perl and Java than to C/C++.
As a matter of fact I am writing a fairly complex linear algebra package
in Ada that is designed for high-performance in supercomputer type
applications. I probably could write it in C and stay out of the
asylum, but it would be a close call. Why? It does things like A := A*B;
in place, with only a row sized temporary, and using Strassen's
algorithm with almost no copying. For efficiency the code works not
with an array type, but with a view that may share data with another
view. That way I can, for example, divide an existing matrix into four
smaller matrices in O(1) time and space. Eventually I will also have
code present to support both transposed views of matrices, in fact I
just finished the fast transpose code. That way I can transpose the
right argument, and avoid doing it more than once.
But if I did write the same code in C, I would not expect performance to
be better. (There are a few cases where the parameter passing overhead
in C would be higher, so performance would be technically worse, but
only by a few instructions.)
> (*) Only if you think the one on the shootout page is inadequate.
Which shootout page, this one? http://dada.perl.it/shootout/matrix.html
If so the only questions I would have is why are there no default
initial values for the matrices to insure consistancy. (It would be
possible for any implementation to fail unless overflow checking is
turned off, and in Ada that can cause code to run slower.) Incidently
on this page, on this test gcc takes ten milliseconds, GNAT takes 20 ms.
Hardly in the same class as perl, 34.31 seconds, or even java, 73
milliseconds.
Also I just submitted a new version of the strcat routine to fix a
minor problem that resulted in the test being reported as failed. (The
length was printed with leading spaces, and the test harness didn't
expect that.) While I was at it I rewrote basically the whole thing:
with Ada.Command_Line; use Ada.Command_Line;
with Ada.Strings.Unbounded; use Ada.Strings.Unbounded;
with Ada.Strings.Fixed; use Ada.Strings;
with Ada.Text_Io; use Ada.Text_Io;
procedure Strcat is
N: Integer;
Hello : String := "hello" & Ascii.Lf;
begin
if Argument_Count < 1
then N := 10_000;
else N := Integer'Value(Argument(1));
end if;
declare
Buffer : Unbounded_String := N*Hello;
begin
Put_Line(Ada.Strings.Fixed.Trim
(Integer'Image(Length(Buffer)),Left));
end;
end Strcat;
This results in about a 100x speed up. Is this the right way to write
it and the code they had wrong? In one sense, that probably is true.
But if I use Bounded_String, the version on the website is slightly
faster, and both versions fall midway between the fast and slow
Unbounded versions. (A version that just uses String is actually faster
than the Unbounded String version. However, I think that version is a
bit of a cheat. ;-)
Robert I. Eachus
> After she hung up, what she had said percolated through my head, and I
> e-mailed a short Fortran example. Sure enough it produced garbage...
Hmmm. Trying to be terse, I may have inadvertantly slandered Fortran, or
the (intentionally unnamed) system vendor.
The bug had nothing to do with Fortran as such. The Fortran standard
was just aa clear as the Ada standard in this area. But the hardware
vendor was working on upgrading their compiler for new hardware with a
wider memory interface. So what Carol said on the phone bugged me until
I worked out an example that would determine whether there was a bug in
their compiler, or a misunderstanding. It turned out that the code
worked correctly on their existing hardware, but broke on the new
hardware. So she fixed the optimizer, and was able to share the code
between the Ada and Fortran front-ends. (Unless a user defined
floating-point type had explicit bounds. Then the Ada code would be
much slower, but you have to assume that the user did that intentionally.)
Incidently, I don't know why Ada compiler implementors picked me to call
with that sort of question. (Or maybe they called everyone looking for
an answer they liked to some questions.) There were three areas in the
Ada 83 standard where everyone who was working on an Ada compiler--and
wasn't represented on the then LMC (now ARG)--called me with the exact
same questions.
The simplest was described as "for I in -1..10 loop..." Yes, you were
expected to reject that at compile time. ("for I in Integer(-1)..10
loop..." was okay.) The second, was that yes it was intentional that
the size of record objects with discriminants could change at run-time,
but only if the discriminants had default values. And the final one was
that yes, elaboration of Ada generics happens at run-time not compile
time. This causes some major issues if you want to implement generics
as textual substitutions. Not that you can't do it, but there are some
things that you have to work pretty hard to get right.
I used to joke that I could tell how the vendors were doing on their
compilers by when they called. ;-)
Richard Riehle
"Robert I. Eachus" <riea...@comcast.net> wrote in message
news:YaWdncfnQoO...@comcast.com...
> Richard Riehle wrote:
>
> > 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.
>
> 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.
> 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
> 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.
When I am in China, the tool for communication I prefer is Chinese, although
I often find myself having to think first in English. In Japan, I prefer
to use
Japanese as much as possible. In Russia, I have found it useful to use
Russian, and that does come rather easily to me. English has become the
reasoning and communication tool for most of the educated world, and
anyone who tries to publish a paper in some other language finds the range
of publications quite limited.
Quite right, that programming languages are tools for reasoning. If one of
those languages leads one to faulty reasoning, it is the wrong tool. And
reasoning is largely about choosing the right abstractions. Sometimes
those
abstractions are internally inconsistent or not easily verifiable.
When comparing C++ and Ada, one of the key issues for me is predictability.
The more I am forced to use C++, the more I realize that it is not now nor
will
it ever be as consistently predictable as Ada. I dislike it when a
program
compiles with no errors only to discover something that the compiler should
have
caught. And the ridicule, "You should have known about that little quirk
in the language," does not bring much satisfaction when I realize that such
quirks
are rare in Ada.
Why is it that, in engineering, which is intolerant of surprise, we continue
to use
tools in software engineering that are characterized by their tendency to
produce
surprises?
Richard Riehle
Richard Riehle
"Ed Falis" <fa...@verizon.net> wrote in message
news:opr253fy...@news.verizon.net...
> On Tue, 10 Feb 2004 03:37:39 GMT, Richard Riehle <adaw...@earthlink.net>
> wrote:
>
> > People do not select their programming tools as wisely as they select
> > their
> > carpentry
> > tools.
>
> While I don't disagree with the thrust of your comments, this one is off.
> In woodworking and carpentry, there are many ways to get a specific task
> done, and the choice of tool is often personal preference, just as it is
> for programming language.
'tis true Ed, that there are many ways to accomplish the same task in
carpentry. In fact, in carpentry, we often invent tools on the fly to
create some unusual effect. This goes to the argument of whether
programming is an art, a craft, or an engineering activity. When I
am trying to be artistic (something I am not), my inventiveness is
more far ranging. When I am striving for good craftsmanship, I
am able to be inventive but more likely to choose tried and true tools
and methods that have worked for me before. When I am engineering,
I am encouraged to use well-established, published specifications,
and the corresponding appropriate tools for design representation.
As an artist, I work alone (most of the time). As a craftsperson,
I am usually crafting solo. As an engineer, I must communicate
with other engineers using settled knowledge, reasoning tools
that communicate my ideas with clarity, and strive for a
predictable outcome. If my tools are not conducive to predictability,
they are probably the wrong tools. This is one of my reasons for
disliking C++ as a engineering tool.
Richard Riehle
Alexander Kopilovitch
> I speak French well enough to get along, in
> both Paris and Quebec--although my accent is hardly Parisian. But I
> can't fit my thoughts inside the language imposed worldview. So when I
> am speaking French I am thinking in English then translating. (I don't
> have to go through that step when listening.)
I think that there must be some *right French for you*, which you
just did not find. First, I believe that you'll agree that Cartesian
coordinate system is distinctly French (extremely imperialistic -:) ,
and at the same time very good thing. Second, take a book - a
collection of famous speeches given in court by French advocates near
1900. Third, read "War Pilot" (or "Military Pilot" - I don't know its
title in English translation, I read it in Russian) by Saint-Exupery.
And finally read memoirs of Grothendieck (it isn't easy to obtain, but
possible - in French... there is Russian translation, but perhaps
still no English translation). I guess that this package will create
a glimpse of worldview, which is certainly French and at the same time
acceptable for you.
> It has been awhile since
> I studied Chinese, long enough that the new transliterations still seem
> strange. And I suspect I would feel more at home in Taiwan than
> mainland China.
I guess that the difference between Traditional and Simplified Chinese
would not be the most significant reason for that your feeling -:)
> And the French pretend they were on the winning side, rather than losing
> early, being occupied for years, and then liberated by the Allies. ;-)
Well, I must confess that this situation annoyed me for a couple of
decades -:) . But then I realized that taking a physisist's viewpoint,
I must admit that the French actually were among winners - this is a
fact, a primary fact, and all the theories and reasons are secondary.
But nevertheless we need a theory, a reason - so I managed to produce
one: despite all their losing and occupation, French appear *ready*,
immediately ready to carry all the banners and duties of a winner.
I hope you agree that it isn't easy and simple for a war loser, for
an recently occupied country to behave correctly as a true winner -
and French did that succesfully. So I concluded that there was a sense
in admitting French into the company of winners - not because they
significantly contributed to the victory, but because they were able
to carry a share in post-war matters as a winner.
> In fact in French, it is hard to think of French military history as
> other than glorious.
Do you know a big country, in which own military history isn't
glorious? -:)
> All this is sort of very off topic for this newsgroup, with one
> exception. The languages that we discussed as not imposing world views
> seem to be required learning at a young age (usually as a "milk tongue")
> to be any good at building compilers and designing programming
> languages. (There are some excellent language designers in France, but
> they all seem to speak fluent English. So it may be that if French is
> your milk tongue you can learn another language later, and still commit
> language design.) I have often felt that this was due to some spoken
> languages being easily extensible, and others forcing you into another
> language if you want to add a new concept. The two extremes seem to be
> English and Japanese.
I tend to agree, but with one addition: those coming from other
languages (which have a "fixed worldview) may convey elements of their
"native" worldview to the whole construction, and this may be very
important, even critical for overall success.
> All popular programming languages seem to have an English heritage.
It coudn't be othewise simply because of the weight of American
computer industry and American market.
> There
> have been a few languages from non-English speaking areas. SIMSCRIPT
> has a Scandinavian heritage.
It is somehow strange that you did not mention Simula-67 here.
Alexander Kopilovitch a...@vib.usr.pu.ru
Saint-Petersburg
Russia
Jerry Coffin
martin...@btopenworld.com says...
[ ... ]
> > A fundamental mistake: assuming that one compiler's inferiority means
> > something about the language itself, or even about other compilers.
>
> That's all well and good but where in the C standard is it required to
> produce a warning?
It's not -- in some ideal world, it might be that there's a programming
language implementation that warns you every time you do something
wrong, but it certainly doesn't exist in this world.
I, however, never claimed that the situation with this in C was ideal by
any means. He claimed that because it wasn't caught by one compiler,
that this proved it could only ever be caught by human examination. I
proved that wrong.
> .. That's the bottom line - what one language throws
> out as an error, another may say nothing and then the user is left to the
> vagaries of what a particular vendor offers.
Rarely true and irrelevant on the rare occasion that it is. Comparing
the languages only makes sense when both are available for the target
platform. If a particular target is so obscure that it truly leaves to
the vagaries of a particular vendor (i.e. there's only one C compiler
for it) then there's basically no chance of finding even one Ada
compiler for the platform. As such, Ada is useless relative to that
platform, regardless of how much merit it might have in theory.
Chad R. Meiners
> the vagaries of a particular vendor (i.e. there's only one C compiler
> for it) then there's basically no chance of finding even one Ada
> compiler for the platform. As such, Ada is useless relative to that
> platform, regardless of how much merit it might have in theory.
Not exactly true. There exist Ada to ANSI C compilers so you can make use
of Ada's compile time benefits for such platforms.
-CRM
Ludovic Brenta
> In article <c0e5su$33j$1...@titan.btinternet.com>,
> martin...@btopenworld.com says...
>
> [ ... ]
>
> > > A fundamental mistake: assuming that one compiler's inferiority means
> > > something about the language itself, or even about other compilers.
> >
> > That's all well and good but where in the C standard is it required to
> > produce a warning?
>
> It's not -- in some ideal world, it might be that there's a programming
> language implementation that warns you every time you do something
> wrong, but it certainly doesn't exist in this world.
>
> I, however, never claimed that the situation with this in C was ideal by
> any means. He claimed that because it wasn't caught by one compiler,
> that this proved it could only ever be caught by human examination. I
> proved that wrong.
No, I was comparing languages not compilers. As stated elsewhere, the
C language does not require any compiler to catch the particular bug I
used as an example. If your compiler does, good for you, but the C
language says you cannot assume it will. What your compiler did was
akin to "lint", which I referred to as using heuristics, not language
rules. Heuristics means that so many people were hurt by this bug
before that it seemed like a good idea to try and catch it at compile
(or "lint") time.
The Ada language mandates that all Ada compilers must catch this bug.
This gives much more confidence in Ada than in C.
--
Ludovic Brenta.
Marin David Condic
>
> Yes, but there are some caveats. Ada insists on getting floating point
> arithmetic "right", so it will typically do it differently than C,
> even though the Ada and C programs superficially look the same. For
Well, I *did* say that only if you had similarly coded examples could
you hope to do any comparison. Not that you couldn't do a comparison and
see a difference. ;-)
Secondly, one needs to insist that some code under evaluation must
produce a *correct* result. If a C coded example computes the wrong
answer at twice the speed of a similar Ada example that gets the answer
right, is it even worth discussing?
My final objection to the whole "Benchmark Wars" is that for 90% of the
uses of compilers, it just plain doesn't matter. If I build a program to
solve a matrix and it gets me an answer displayed on my screen in 10
seconds - but I re-code it in another language and the answer pops up in
8 seconds instead, what am I going to do with those extra two seconds?
Save them up for Christmas? People do this sort of math stuff all day
long in spreadsheets which are interpreting the answers at great
inefficiency and they spend lots of time not caring about it. So why do
programmers without a real performance constraint spend so much time
getting their panties in a bunch over something that never has a real
impact on what they're doing?
Keep in mind that I work with apps where miliseconds count, so I know
how to worry about compiler efficiency. I also know I can get good
compiler efficiency out of Ada (plus all of Ada's other benefits), so
when I *must* be efficient, I know I can get there. But when I go over
to a PC or workstation to develop some hacker tool I need, worrying
about a few extra CPU cycles is way down on my list of concerns.
Too many people spend too much time agonizing over "Compiler Efficiency"
- usually without any real scientific data to back up their perceptions
of what is fast and what is slow - and most of the time it just plain
doesn't matter. I'd bet that if we took most of the applications that
people use on a daily basis and inserted random delay statements
throughout them to double the amount of CPU cycles they use, nobody
would notice any difference in how they got their job done.
MDC
Preben Randhol
>
> Too many people spend too much time agonizing over "Compiler Efficiency"
> - usually without any real scientific data to back up their perceptions
> of what is fast and what is slow - and most of the time it just plain
> doesn't matter. I'd bet that if we took most of the applications that
> people use on a daily basis and inserted random delay statements
> throughout them to double the amount of CPU cycles they use, nobody
> would notice any difference in how they got their job done.
Yes. It is like debating which car is best and safest by how far the
speedometer goes and not caring if it has a seat belt or not. C/C++ do
not have seat belts.
Reivilo Snuved
[snip]
> In fact in French, it is hard to think of French military history as
> other than glorious.
You might be attaching more "baggage" to the language than is really
necessary here.
Ole-Hjalmar Kristensen
> Ole-Hjalmar Kristensen wrote:
> >
> > Yes, but there are some caveats. Ada insists on getting floating point
> > arithmetic "right", so it will typically do it differently than C,
> > even though the Ada and C programs superficially look the same. For
>
>
> Well, I *did* say that only if you had similarly coded examples could
> you hope to do any comparison. Not that you couldn't do a comparison
> and see a difference. ;-)
>
> Secondly, one needs to insist that some code under evaluation must
> produce a *correct* result. If a C coded example computes the wrong
> answer at twice the speed of a similar Ada example that gets the
> answer right, is it even worth discussing?
>
It could well be. In the case of an interactive raytracer, minor
numerical errors does not really matter if you can get the results at
twice the speed. I imagine you can find other applications with
similar characteristics. But in general, I agree that for the
majority of applications the difference in speed between languages and
compilers is nothing to worry about.
<snip>
Alexandre E. Kopilovitch
> English has become the
> reasoning and communication tool for most of the educated world,
This may be mostly true for communication, but certainly not for reasoning -
please don't make such dangerous illusions.
> and
> anyone who tries to publish a paper in some other language finds the range
> of publications quite limited.
Although mostly true, there were and are notable exceptions. First, any
significant scientific result that was published in prominent journal in any
language will be immediately and widely known, and either the article will be
soon translated into English or a detailed English review will be provided...
at least in "mainstream sciences" - mathematics, physics, chemistry, biology.
Second, I remember that in 70-80th several Soviet mathematical journal were
translated into English by Americans (American Mathematical Society) - in whole
and every issue.
> Why is it that, in engineering, which is intolerant of surprise, we continue to use
> tools in software engineering that are characterized by their tendency to produce
> surprises?
That's because not only tools, but also people may produce surprises.
And there is widespread suspicion that the people who select and insist on
good and robust tools have a tendency to produce surprises by themselves.
And management often prefers surprises from tools to surprises from employers -;) .
Jerry Coffin
says...
[ ... ]
> No, I was comparing languages not compilers.
That may have been what you _intended_, but here's what you actually
_said_:
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
I was addressing that statement, and proved it wrong. Worse than simply
being wrong, however, is the fallacious reasoning it represents. You
claim that a single example proves an entire class. I honestly don't
want to turn this into a personal attack, but it's difficult to take any
of your opinions seriously when you apparently lack all grasp of logic
or reasoning.
> As stated elsewhere, the
> C language does not require any compiler to catch the particular bug I
> used as an example. If your compiler does, good for you, but the C
> language says you cannot assume it will. What your compiler did was
> akin to "lint", which I referred to as using heuristics, not language
> rules. Heuristics means that so many people were hurt by this bug
> before that it seemed like a good idea to try and catch it at compile
> (or "lint") time.
Rather the contrary: it gets caught because it's trivial to catch, and
the market for C compilers is sufficiently competitive that nearly every
vendor is constantly working at adding features, especially those that
are easy to implement.
> The Ada language mandates that all Ada compilers must catch this bug.
> This gives much more confidence in Ada than in C.
It may give you "much more confidence in Ada", but if so, it's precisely
the false sense of security I've pointed out a number times before. If
you were being realistic, this would increase your confidence in Ada
over C by approximately the number of real bugs it catches.
In my experience that would be well under one part per million --
probably closer to one part per billion. I've a pretty fair amount of
experience, and I've yet to see a real bug like this. I don't think it
hurts anything for the compiler to catch it, but the degree of
confidence it should inspire is exceptionally minimal.
The sad part is that Ada is a good enough language that it deserves a
much better defense than you're giving it. Ada provides features that
really can (and do) help prevent bugs that are much more common in C.
Unfortunately, every indication you've given so far in this thread is
that you lack sufficient insight into either language to recognize those
areas and base your arguments on them.
On a slightly different subject, given that this is cross-posted to
c.l.ada and c.l.c++, if you're going to advocate Ada as being superior,
the comparison should clearly be to C++ rather than C.
Jerry Coffin
says...
Also rarely true -- for better or worse, the "ANSI C" compilers on many
obscure (especially embedded) systems are "ANSI C" only by courtesy --
they're generally enough like C that it's easy for a reasonably
experienced programmer to learn and live with their restrictions, but
unless the translator in question uses quite a restricted portion of C,
there's still a pretty good chance that what it produces won't be
accepted by the "C compiler" in question.
In many cases, the editing that would be involved to make it work would
theoretically be pretty trivial. Unfortunately, that fact that it's
machine-generated code prevents almost anything from being trivial --
such code is usually opaque in the extreme. Worse, this route places
even higher demands on the programmers: they have to know Ada to write
the original code, AND they have to know C to edit the output of the
translator. Worse, the problems involved are often in relatively
obscure corners of the language that few programmers would ever delve
into, so they can't just be reasonably good C programmers either: they
have to be exceptionally knowledgeable and well-informed ones.
The bottom line is that an Ada to C translator could be useful under
some circumstances, but in the situation that was being described, it's
likely to be far more of a problem than a solution.
Frank J. Lhota
> Surely you haven't tasted Belgian beer. Next time you're in Brussels,
> give me a call and I'll treat you to some :)
I haven't been to Belgium yet, but I have had imported Belgian beer, and I
can vouch that it is quite good. :)
MSG
> msg...@yahoo.com (MSG) wrote in
> news:54759e7e.0402...@posting.google.com:
> > Can you write (*) a matrix multiplication routine in Ada, compile it
> > with GNAT and measure the number CPU cycles per FLOP, compare to a
> > similar routine in C?
> > The shootout seems to put GNAT closer to Perl and Java than to C/C++.
>
> Java was 0.73 and Perl was 34.31.
>
> I do not see how .2 is closer to .7 or 34 than it is to .1.
>
> Your mathematics seems seriously flawed.
Only to the uninitiated :)
To keep it simple (I'm a mathematician actually), you seem to be
giving special importance on the execution _time_ and the
_arithmetic_ average, as opposed to, say, execution _speed_ (or the
_harmonic_ average). Let's compare speeds in tasks per second using
your data:
VC = 14.2
GCC = 10.0
GNAT = 5.0
Java = 1.4
Perl = 0.03
Now can you see how GNAT is "closer" to both Java and Perl than even
to the "slower" of the C compilers here? :)
I replaced the dead Java group with comp.lang.fortran - maybe they'll
clue us in on the matrix multiplication performance issues (or at
least keep Adaists from feeding us strange explanations).
To recap the discussion (or my understanding of it) :
1. GNAT, an Ada compiler, is a front end to GCC and so should use the
same "window" (i.e. local) optimizations GCC does
2. Arrays are unaliased in Ada (as I understood), much like in
FORTRAN, which may be beneficial in terms of performance (given that
the compiler takes advantage of this, and I believe, in case of GCC,
it does)
3. Ada is compiled to native code and isn't garbage collected, which
puts its execution mode in the same language group with C, C++ and
Fortran
And yet, dispite all of these (especially (1)). GNAT did not fair as
well as GCC and G++ (I'm sure G77 would have done at least as well).
MSG
P.S. BTW is the code generated by IFC as fast as G77 on modern CPUs
(P4 and Athlon)? Is it worth bothering with IFC on benchmarks, etc.?
Alexandre E. Kopilovitch
> To keep it simple (I'm a mathematician actually), you seem to be
> giving special importance on the execution _time_ and the
> _arithmetic_ average, as opposed to, say, execution _speed_ (or the
> _harmonic_ average).
As you are a mathematician then it should be correct to ask you for a full
definition of that _speed_ and/or accessible reference for it. (I never heard
about a connection between execution speed and harmonic average, and I'm sure
that I can understand proper mathematical definition at the level of MS in
mathematics.)
Chad R. Meiners
> > > As such, Ada is useless relative to that
> > > platform, regardless of how much merit it might have in theory.
> >
> > Not exactly true. There exist Ada to ANSI C compilers so you can make
use
> > of Ada's compile time benefits for such platforms.
>
> Also rarely true
Even if it is rarely true, it proves that your above statement is false.
Perhaps that is not what you intended to say, but it is what you wrote.
> -- for better or worse, the "ANSI C" compilers on many
> obscure (especially embedded) systems are "ANSI C" only by courtesy --
courtesy? An ANSI C compiler that doesn't compile ANSI C is incorrect.
<snip>
> In many cases, the editing that would be involved to make it work would
> theoretically be pretty trivial.
In the trivial cases the backend for the translator can be modified by the
vendor.
Greg Lindahl
MSG <msg_...@yahoo.com> wrote:
>I replaced the dead Java group with comp.lang.fortran - maybe they'll
>clue us in on the matrix multiplication performance issues (or at
>least keep Adaists from feeding us strange explanations).
Please don't cross-post a cross-posted flamewar into new newsgroups. If
the Ada people are bothering you, stop bothering them.
The Fortran view is that if you want a fast matrix multiply, you'll
use the built-in language matmul(), or you'll call an appropriate BLAS
3 subroutine. This results in getting cache-blocked tweaked-assembly
routines. Alternately, use a compiler which has built-in cache
blocking, such as that generated by the KAP preprocessor, or the
SGI IRIX or PathScale Opteron compilers.
Followups to comp.lang.fortran.
-- greg
(disclaimer: I work for, but don't speak for, PathScale.)
James Rogers
news:88dc613b.0402...@posting.google.com:
>> The shootout numbers I saw put vc at .07, gcc at 0.10 and GNAT at
>> .20. Java was 0.73 and Perl was 34.31.
>>
>> I do not see how .2 is closer to .7 or 34 than it is to .1.
>>
>> Your mathematics seems seriously flawed.
>
> Only to the uninitiated :)
>
> To keep it simple (I'm a mathematician actually), you seem to be
> giving special importance on the execution _time_ and the
> _arithmetic_ average, as opposed to, say, execution _speed_ (or the
> _harmonic_ average). Let's compare speeds in tasks per second using
> your data:
>
> VC = 14.2
> GCC = 10.0
> GNAT = 5.0
> Java = 1.4
> Perl = 0.03
This is physical nonesense. Your analysis would say that Perl, which
performed 300 matrix multiplications in 34.31 seconds is on the same
order of speed as some language taking 28640 seconds. Which would
result in a "speed" of .0003. 28640 seconds is 24 hours.
You are stating that Perl has a speed closer to a language taking
24 hours to complete the task than to VC.
The important relationship is the ratio between the numbers, not the
absolute difference between the numbers. Given that relationship
GNAT is as close to Java as it is to VC, and Java is closer to VC
than it is to Perl.
Jim Rogers
Richard Heathfield
> 28640 seconds is 24 hours.
<cough> 28640 seconds is just under eight hours.
<snip>
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Larry Hazel
> James Rogers wrote:
>
>
>>28640 seconds is 24 hours.
>
>
> <cough> 28640 seconds is just under eight hours.
>
> <snip>
>
James Rogers
news:c0ha2t$2tf$3...@titan.btinternet.com:
> James Rogers wrote:
>
>> 28640 seconds is 24 hours.
>
> <cough> 28640 seconds is just under eight hours.
I seem to have been relying upon alzheimer's instead of
arithmetic. Sorry about that.
Jim Rogers
Georg Bauhaus
: The Fortran view is that if you want a fast matrix multiply, you'll
: use the built-in language matmul(), or you'll call an appropriate BLAS
: 3 subroutine.
This seems to be a common Ada view too.
-- Georg