No call for Ada (was Announcing new scripting/prototyping language)

java-programmer, No call for Ada (was Announcing new scripting/prototyping language) Josh Sebastian wrote:
> 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.

java-programmer >> No call for Ada (was Announcing new scripting/prototyping language) Josh Sebastian wrote:
> 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.

java-programmer >> No call for Ada (was Announcing new scripting/prototyping language) 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

James Rogers <email***@***.com> wrote in message news:<email***@***.com>...
> Given the quite reasonable objections presented by some in the
> cross-posted news-groups I would like to carry on this conversation
> with you via email. My return email is valid.
>
> Jim Rogers

java-programmer >> No call for Ada (was Announcing new scripting/prototyping language) On 9 Feb 2004 18:26:33 -0800, MSG <email***@***.com> wrote:

> 3. not very performance demanding (don't know about other compilers,
> but they say GNAT produces slow executables)

"... but they say ..."

Great research!

;-)

java-programmer >> No call for Ada (was Announcing new scripting/prototyping language) email***@***.com (MSG) wrote in
news:email***@***.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

java-programmer >> No call for Ada (was Announcing new scripting/prototyping language) 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++.

/David, writing from comp.lang.c++

java-programmer >> No call for Ada (was Announcing new scripting/prototyping language) "Dmitry A. Kazakov" <email***@***.com> wrote in message
news:email***@***.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.

java-programmer >> No call for Ada (was Announcing new scripting/prototyping language) "David Rasmussen" <email***@***.com> wrote in message
news:c0aa3o$i3t$email***@***.com...
> 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.

java-programmer >> No call for Ada (was Announcing new scripting/prototyping language) MSG wrote:
> 3. not very performance demanding (don't know about other compilers,
> but they say GNAT produces slow executables)
>
I don't know how this comes up - I've used Gnat for non-realtime code
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

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

java-programmer >> No call for Ada (was Announcing new scripting/prototyping language) "Dmitry A. Kazakov" <email***@***.com> wrote in message
news:email***@***.com...
> >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.

java-programmer >> No call for Ada (was Announcing new scripting/prototyping language) Martin Dowie wrote:

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

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

java-programmer >> No call for Ada (was Announcing new scripting/prototyping language) On Tue, 10 Feb 2004 14:11:16 +0000 (UTC), in comp.lang.c , "Martin Dowie"
<email***@***.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 =---

java-programmer >> No call for Ada (was Announcing new scripting/prototyping language) Martin Dowie wrote:
> "Dmitry A. Kazakov" <email***@***.com> wrote in message
> news:email***@***.com...
>
>>>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.
>

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.

java-programmer >> No call for Ada (was Announcing new scripting/prototyping language) Dmitry A. Kazakov <email***@***.com> wrote in message news:<email***@***.com>...
> On 9 Feb 2004 18:26:33 -0800, email***@***.com (MSG) wrote:
> >
> >1. no real time

[...]

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

java-programmer >> No call for Ada (was Announcing new scripting/prototyping language) email***@***.com (MSG) wrote in
news:email***@***.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++.

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

java-programmer >> No call for Ada (was Announcing new scripting/prototyping language) 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

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

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

java-programmer >> No call for Ada (was Announcing new scripting/prototyping language) Marin David Condic <email***@***.com> writes:

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

java-programmer >> No call for Ada (was Announcing new scripting/prototyping language)
"Dmitry A. Kazakov" <email***@***.com> wrote in message
news:email***@***.com...
> On 10 Feb 2004 18:19:13 -0800, email***@***.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;
>
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.

DrX

java-programmer >> No call for Ada (was Announcing new scripting/prototyping language) On 2004-02-11, Xenos <email***@***.com> wrote:
> 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

java-programmer >> No call for Ada (was Announcing new scripting/prototyping language)
"Preben Randhol" <randhol+email***@***.com> wrote in
message
news:slrnc2kn4d.aav.randhol+email***@***.com...
>
> Yes, you won't get a buffer overflow.
>
You wouldn't of gotten a buffer overflow either way, it would have raised a
constraint_error.

DrX

java-programmer >> No call for Ada (was Announcing new scripting/prototyping language) ["Followup-To:" header set to comp.lang.ada.]
On 2004-02-11, Xenos <email***@***.com> wrote:
>
> "Preben Randhol" <randhol+email***@***.com> wrote in
> message
> news:slrnc2kn4d.aav.randhol+email***@***.com...
>>
>> Yes, you won't get a buffer overflow.
>>
> You wouldn't of gotten a buffer overflow either way, it would have raised a
> constraint_error.

Not in C.

But you cut that example out.

--
"Saving keystrokes is the job of the text editor, not the programming
language."