Ada vs C++ vs Java

Ada vs C++ vs Java

[Leszek Sczaniecki]

We are about to start a big project, something about 250k lines of code.
We are going to stick to it for next several years. We would like to
make an educated choice for the underlying language. This language
should
- support object oriented programming
- support parallel programming
- lead to easily maintainable code
- promote safe programming techniques
- have significant support from commercial vendors (compilers, GUI
design, testing sw)
- be available for popular processors (such as 68xxx, PowerPC, etc.)
- enjoy wealth of existing solutions
- support "almost real time" execution
- be suitable for design of embedded systems
- have existing support for vxworks

There is a legacy code written in Ada and our customer would prefer Ada
95. However, we became seriously concerned that there is not sufficient
support for Ada in the commercial world. Given, that we will be stuck
with our project for the next several years we would like to choose
something that still will have adequate support few years down the road.
Given all that we decided to check C++ and Java. I would appreciate
greatly any comparisons, comments, hints, pointers to electronic and
hard copy sources, warnings about traps and pitfalls, etc. that would
help us thoroughly justify the language choice to our customer.

-leszek

PS
If you are afraid that your response may start a religious war or that
it is not of interest of your newsgroup please send me e-mail.

Re: Ada vs C++ vs Java

[dennison]

In article <369C1F31.AE5AF7EF@concentric.net>,
  Leszek Sczaniecki <lsczan@concentric.net> wrote:

> There is a legacy code written in Ada and our customer would prefer Ada
> 95. However, we became seriously concerned that there is not sufficient
> support for Ada in the commercial world. Given, that we will be stuck

I'm a little confused by the phrase "sufficient support". What exactly is it
you want to do but can't? What is it you are afraid will happen?

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Erik Funkenbusch]

It's not a very cut and dried situation i'm afraid.

(comments below)

Leszek Sczaniecki <lsczan@concentric.net> wrote in message
news:369C1F31.AE5AF7EF@concentric.net...
>We are about to start a big project, something about 250k lines of code.
>We are going to stick to it for next several years. We would like to
>make an educated choice for the underlying language. This language
>should

I don't think size of the project has much influence over the choice when
considering language.  At least not in the languages you've mentioned.

>- support object oriented programming

All three do, although at differing levels and differing feature sets
(example:  Java doesn't support Multiple Inheritance, C++ does.  But that
may not be a concern to you).

>- support parallel programming

I'm not sure exactly what you mean by that.  You mean multi-processor
support?  Threads?  Those are OS constructs, but of course the Language has
to be able to handle them (VB for instance doesn't do a good job of that).

>- lead to easily maintainable code

No language will do that.  It's a function of design.

>- promote safe programming techniques

Be aware that "safe" often means "confining".  You may not be able to do the
things you need to do in a language that doesn't support pointers or direct
hardware access (like Java).

>- have significant support from commercial vendors (compilers, GUI
>design, testing sw)

Well, Java is gaining a lot of vendor support.  But be aware that the
language is changing rapidly and that there is no standardization of it.
New versions are likely to make older code obsolete (for instance, the
switch from 1.0.x to 1.1 introduced whole new event models).  It's a very
immature language and is likely to go through a lot more growing pains.

>- be available for popular processors (such as 68xxx, PowerPC, etc.)

Processors aren't the key, OS platforms are.  You're most safe with C++ on
this matter i think.  Java isn't available on everything yet.  You're also
likely to find limited choices in ADA compilers on more obscure OS's.

>- enjoy wealth of existing solutions

If you mean add-on libraries, again this is mostly OS platform related,
although there are certainly a number of platform independant libraries as
well.  I don't know much about the 3rd party ADA market, but C++ certainly
has a strong support here.

>- support "almost real time" execution

Well, Java certainly can't do this yet.  C++ can, depending on OS support.
ADA most certainly does, or it wouldn't be able to be used in Jet Avionics
and such.

>- be suitable for design of embedded systems

C++ generally isn't.  There is an "embedded C++" that's in the works, and
there might even be some implementations.  C is better for embedded work
than C++.  I don't know the specifics of ADA embedded work.

>There is a legacy code written in Ada and our customer would prefer Ada
>95. However, we became seriously concerned that there is not sufficient
>support for Ada in the commercial world.

Well, there seems to be plenty of vendor support for ADA, but I think you
won't find as much 3rd party library support.  That means you'll be stuck
writing everything from scratch in most cases.

>Given, that we will be stuck
>with our project for the next several years we would like to choose
>something that still will have adequate support few years down the road.
>Given all that we decided to check C++ and Java. I would appreciate
>greatly any comparisons, comments, hints, pointers to electronic and
>hard copy sources, warnings about traps and pitfalls, etc. that would
>help us thoroughly justify the language choice to our customer.

Well, I would vote against Java.  It's too immature for a long term project
and has questionable speed.

Your choice of ADA and C++ has many factors.  It's likely going to be easier
to find people to maintain C++ code than ADA.  It's also got more 3rd party
support.  Both are standardized, although not all current compilers support
the full standard C++ yet (in fact, I don't know of any that are fully
compliant yet).

ADA is mature, and has proven itself in military applications and stability
over the years.

You've got to weigh the pros and cons and come to your own decision.

Re: Ada vs C++ vs Java

[Peter]

In article <tz5n2.4608$TO5.129375@ptah.visi.com>, "Erik Funkenbusch"
<erikf@visi.com> wrote:

> >- lead to easily maintainable code
> 
> No language will do that.  It's a function of design.


It is a function of the programming language though.  To take an extreme
example, most programmers don't find programs written in machine language
to be particularly maintainable for large projects compared to programs
written high-level programming languages.  But even comparing high-level
programming languages there is much differences in the level of
maintainability of programs written in the programming languages.  In some
languages, pointer errors, memory management, etc. are not even a
possibility.  This makes it easier for a person who did not write the code
to go in and modify the program because there are less hidden assumptions
that they have to be aware of.

> 
> >- promote safe programming techniques
> 
> Be aware that "safe" often means "confining".  You may not be able to do the
> things you need to do in a language that doesn't support pointers

Safe often means unconfining too.  For example, having references instead
of pointers is unconfining because you don't have to worry about pointer
errors (one of the leading cause of errors in C and C++ programs)
corrupting the state of your program.  You shouldn't equate lack pointers
in a language with limitations in Java's functionality.  Other languages
without pointers are very powerful.

Re: Ada vs C++ vs Java

[Corvus]

Peter wrote:
> 
> In article <tz5n2.4608$TO5.129375@ptah.visi.com>, "Erik Funkenbusch"
> <erikf@visi.com> wrote:
> 
> > >- lead to easily maintainable code
> >
> > No language will do that.  It's a function of design.
> 
> It is a function of the programming language though.  To take an extreme
> example, most programmers don't find programs written in machine language
> to be particularly maintainable for large projects compared to programs
> written high-level programming languages.  But even comparing high-level

<snip>

Actually I find machine code easier to maintain and understand in small
projects...Even tho' Machine Code isn't used anymore, I still like to
open up Debug once in a while and see what I can accomplish...

> >
> > >- promote safe programming techniques
> >
> > Be aware that "safe" often means "confining".  You may not be able to do the
> > things you need to do in a language that doesn't support pointers
> 
> Safe often means unconfining too.  For example, having references instead
> of pointers is unconfining because you don't have to worry about pointer
> errors (one of the leading cause of errors in C and C++ programs)
> corrupting the state of your program.  You shouldn't equate lack pointers
> in a language with limitations in Java's functionality.  Other languages
> without pointers are very powerful.

-- 
This is my .SIG file.  Enjoy.

Re: Ada vs C++ vs Java

[Marin David Condic]

Erik Funkenbusch wrote:
<snip>
> 
> >- support parallel programming
> 
> I'm not sure exactly what you mean by that.  You mean multi-processor
> support?  Threads?  Those are OS constructs, but of course the Language has
> to be able to handle them (VB for instance doesn't do a good job of that).

Not entirely accurate. Ada has the Task construct which allows parallel
programming without dependence on the specific OS. Typical
implementations on Unix and WinNT platforms will be via system calls.
However, since Ada was originally targeted for embedded systems, a
number of implementations go directly to the bare hardware and the
implementation's runtime support has to provide the primitives for task
scheduling, etc.

Tasks in Ada provide parallelism in a machine-independent and
invisible-to-the-programmer manner. I do not know of a similar mechanism
in either C++ or Java. Maybe it is there. Maybe not. You'd need someone
else to fill you in on that.

> 
> >- lead to easily maintainable code
> 
> No language will do that.  It's a function of design.

Yes and no. "Yes", a bad design or a bad realization of a design is
possible in *any* language. It has never been the least bit hard to
write bad programs in any known language. "No", maintainability *can* be
enhanced by the language. Some languages are inherently more readable,
less cryptic, easier to develop extendable constructs, less apt to
produce errors, etc. etc. etc. To discount this would be to claim that
programs written in raw machine code (zeros and ones - not assembler)
are just as easily maintained as a program written in a state-of-the-art
high level language. Such a statement is patently absurd, so we can
conclude that there is at least *some* influence the language has on
maintainability. That being the case, it is fair to ask "Is language X
more easily maintained than language Y?" Quad Erat Demonstratum.

> 
<snip>
> >- be available for popular processors (such as 68xxx, PowerPC, etc.)
> 
> Processors aren't the key, OS platforms are.  You're most safe with C++ on
> this matter i think.  Java isn't available on everything yet.  You're also
> likely to find limited choices in ADA compilers on more obscure OS's.

Possibly, but C++ & Java both are relatively new languages and aren't
likely to appear on out of date or obscure hardware/OS's either. And the
question seems to indicate that it is "bare processors" that are of
interest. (Typical of any embedded app). So it will depend on if you
want an embedded compiler or a "regular" compiler.

<snip>
> >- be suitable for design of embedded systems
> 
> C++ generally isn't.  There is an "embedded C++" that's in the works, and
> there might even be some implementations.  C is better for embedded work
> than C++.  I don't know the specifics of ADA embedded work.

For the record - Ada was originally developed with embedded applications
in mind. There are a number of compilers for Ada which do target bare,
embedded processors. Aonix, Green Hills, and Rational to name a few I
can think of off the top of my head. There are plenty of choices for a
variety of targets, but you have to start by defining what you want.
Bare processor or running on top an RTOS? Which processor? What sort of
application domain? 

<snip>

Hope this sheds a little light on the subject.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

    "Nobody shot me."

        --  Last words of Frank Gusenberg when asked by police who
            shot him fourteen times with a machine gun in the Saint
            Valentine's Day Massacre.

Re: Ada vs C++ vs Java

[Ken Keys]

Marin David Condic wrote:

> Not entirely accurate. Ada has the Task construct which allows parallel
> programming without dependence on the specific OS. Typical
> implementations on Unix and WinNT platforms will be via system calls.
> However, since Ada was originally targeted for embedded systems, a
> number of implementations go directly to the bare hardware and the
> implementation's runtime support has to provide the primitives for task
> scheduling, etc.

I suppose this is terribly off-topic discussing technical details in the
middle of a flame war but...

Have you (or do you have first hand knowledge of anyone who has) ever
used an Ada Rendezvous in an RTOS environment, such as, say, Vxworks? Or
do you, like everyone I have ever met, use the OS services (semaphores
etc.) directly?

> Tasks in Ada provide parallelism in a machine-independent and
> invisible-to-the-programmer manner. I do not know of a similar mechanism
> in either C++ or Java. Maybe it is there. Maybe not. You'd need someone
> else to fill you in on that.

Java has threads. In C++ it is more of a library issue. The C++ standard
doesn't address it but Posix does. The RTOS probably includes a Posix
library and if it doesn't, it probably doesn't support Ada either.

You need to be concerned with reentrancy and synchronization issues when
you choose a C++  STL library, especially if you plan to use iostreams
or other such goodies.

KLK

Re: Ada vs C++ vs Java

[John Woodruff]

>>>>> "Ken Keys" == Ken Keys <klkeys@west.raytheon.com> writes:
In article <369E4A41.8D7DDA14@west.raytheon.com> Ken Keys <klkeys@west.raytheon.com> writes:

    > Marin David Condic wrote:
    >> Not entirely accurate. Ada has the Task construct which allows
    >> parallel programming without dependence on the specific
    >> OS. 

    > I suppose this is terribly off-topic discussing technical details
    > in the middle of a flame war but...

    > Have you (or do you have first hand knowledge of anyone who has)
    > ever used an Ada Rendezvous in an RTOS environment, such as, say,
    > Vxworks? Or do you, like everyone I have ever met, use the OS
    > services (semaphores etc.) directly?

The portion of the project I described in an earlier note that is
running on VxWorks does indeed use tasking (and protected types in
Ada95). Our environment uses CORBA to communicate from (roughly 20)
supervisory level workstations to some 400 "front-end processors" of
eighteen different varieties that are usually PowerPC's with VxWorks.
Multitasking is used everywhere for concurrency.

--
John Woodruff                                             N I F   \ ^ /
Lawrence Livermore National Lab                         =====---- < 0 >
925 422 4661                                                      / v \

Re: Ada vs C++ vs Java

[Ken Keys]

John Woodruff wrote:

>     > Have you (or do you have first hand knowledge of anyone who has)
>     > ever used an Ada Rendezvous in an RTOS environment, such as, say,
>     > Vxworks? Or do you, like everyone I have ever met, use the OS
>     > services (semaphores etc.) directly?
> 
> The portion of the project I described in an earlier note that is
> running on VxWorks does indeed use tasking (and protected types in
> Ada95). Our environment uses CORBA to communicate from (roughly 20)
> supervisory level workstations to some 400 "front-end processors" of
> eighteen different varieties that are usually PowerPC's with VxWorks.
> Multitasking is used everywhere for concurrency.

Well, my question was whether you controlled the tasks entirely through
Ada language constructs or if you bypassed Ada and talked directly to
VxWorks. Or are you saying that you implemented CORBA and inter process
communications entirely through the use of Ada Rendezvous?

Maybe I should give some background. I am pretty much an agnostic when
it comes to language issues. I had always thought of Ada as "Pascal with
an attitude" although Ada has a lot of nice features that were missing
from Pascal. As such, I never saw much use for the Rendezvous (which
isn't explained very well in most Ada texts). I figured that it was
something that was added to the language spec to satisfy some ivory
tower academic. A year or so ago a colleague enlightened me with some
examples of just what could be done with the Rendezvous. However when I
asked him if he had ever used any in his production code, the answer was
no. He used the underlying OS primitives just like everybody else.

KLK

Re: Ada vs C++ vs Java

[Marc A. Criley]

Ken Keys wrote:
> 
  <snips>
>
> from Pascal. As such, I never saw much use for the Rendezvous (which
> isn't explained very well in most Ada texts). I figured that it was
> something that was added to the language spec to satisfy some ivory
> tower academic. A year or so ago a colleague enlightened me with some
> examples of just what could be done with the Rendezvous. However when I
> asked him if he had ever used any in his production code, the answer was
> no. He used the underlying OS primitives just like everybody else.

Ada tasking with rendezvous are used to good effect in the production
code of the Advanced Tomahawk Weapon Control System (ATWCS).  Two of
the three major subsystems each may have hundreds of simultaneously
active tasks.  ATWCS, though, is a "soft real-time" rather than embedded
system.

Marc A. Criley
Chief Software Architect
Lockheed Martin M&DS
W : (610) 354-7861
marc.a.criley@lmco.com

Re: Ada vs C++ vs Java

[dennison]

In article <369F87EE.88403F96@west.raytheon.com>,
  Ken Keys <klkeys@west.raytheon.com> wrote:

> Maybe I should give some background. I am pretty much an agnostic when
> it comes to language issues. I had always thought of Ada as "Pascal with
> an attitude" although Ada has a lot of nice features that were missing
> from Pascal. As such, I never saw much use for the Rendezvous (which
> isn't explained very well in most Ada texts). I figured that it was
> something that was added to the language spec to satisfy some ivory
> tower academic. A year or so ago a colleague enlightened me with some

In the obsolete version of Ada, rendezvous were the only way to synchronize
tasks. Therefore if two tasks needed to reference a non-scalar object safely,
rendezvous *had* to be used. There's nothing "ivory tower" about it. Code just
would not work properly without them!

> examples of just what could be done with the Rendezvous. However when I
> asked him if he had ever used any in his production code, the answer was
> no. He used the underlying OS primitives just like everybody else.

I have worked on 5 Ada83 projects. Of those 3 used tasking. I did see some use
of external synchronization methods for special purposes (eg: VMS locks to
synchronize tasks running on different machines in a VaxCluster), but I never
saw anyone use OS calls for a job that rendezvous could handle. Frankly the
whole idea is somewhat appalling; much akin to hearing that someone only uses
integer types because "strong typing is slow and cramps my style".
(Whoops! Let's please not start a strong/weak typeing flamewar too..)

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Marin David Condic]

Ken Keys wrote:
> 
> Maybe I should give some background. I am pretty much an agnostic when
> it comes to language issues. I had always thought of Ada as "Pascal with
> an attitude" although Ada has a lot of nice features that were missing
> from Pascal. As such, I never saw much use for the Rendezvous (which
> isn't explained very well in most Ada texts). I figured that it was
> something that was added to the language spec to satisfy some ivory
> tower academic. A year or so ago a colleague enlightened me with some
> examples of just what could be done with the Rendezvous. However when I
> asked him if he had ever used any in his production code, the answer was
> no. He used the underlying OS primitives just like everybody else.
> 
Ahhhhhh. Now it all becomes clear to me! I thought your question had
something to do with Ada rendesvous and efficiency. But your real
interest is "Why have it as a language primitive when I can just call OS
routines?"

1) There are at least some hard real time embedded systems for which
there is no underlying operating system to call. You write your own
"operating system". Ada was originally designed for programs that fall
into this category - or rather, this was *one* of the categories whos
requirements had to be met. Yes, when you are operating at this level,
you can find lots of good uses for Ada's rendesvous mechanism. Your only
issue is one of CPU time required to use the mechanisms. (And, as
observed earlier, Ada95 has cured many of the speed & priority problems
originally in Ada83, so there are fewer reasons to avoid them.)

2) Even for embedded or other applications where there *is* an
underlying operating system, you cannot necessarily be sure of *which*
operating system or what the precise calls are to get the same effects
as those provided by the rendesvous. If you are comfortable with the
application being short lived and only ever going to run on, say, Unix,
then I guess it's a toss up as to using rendesvous or system calls. But
in a large number of systems, you don't know how long the software has
to last and you don't know that it won't have to be ported to some other
environment. So its nice to have a well defined mechanism within the
language for accomplishing the goals because doing so leads to
portability, reusability and reliability. Its also advantageous in that
the programmer need not learn some set of underlying OS primitives in
order to accomplish multitasking & inter-task communication. Its all
right there in the language, the ARM and the related textbooks.

Maybe your experience is different. In my experience it has been easier
to learn to use Ada's rendesvous mechanisms than it is to dig up the
same information out of OS documentation. And in the embedded code arena
in which I work, there is no OS, so I'm real glad that Ada provides a
way to get there.

MDC

-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

    "Nobody shot me."

        --  Last words of Frank Gusenberg when asked by police who
            shot him fourteen times with a machine gun in the Saint
            Valentine's Day Massacre.

Re: Ada vs C++ vs Java

[Marin David Condic]

Ken Keys wrote:
> 
> Marin David Condic wrote:
> 
> > Not entirely accurate. Ada has the Task construct which allows parallel
> > programming without dependence on the specific OS. Typical
> > implementations on Unix and WinNT platforms will be via system calls.
> > However, since Ada was originally targeted for embedded systems, a
> > number of implementations go directly to the bare hardware and the
> > implementation's runtime support has to provide the primitives for task
> > scheduling, etc.
> 
> I suppose this is terribly off-topic discussing technical details in the
> middle of a flame war but...

But I was beginning to enjoy the flame war! ;-) I seriously believe that
most of the posts of the form "I hear that language X sucks..." or
"Which language is better: X or Y?" are really experiments by doctoral
students studying abnormal psychology. That, or they are started by
someone's artificial intelligence experiment gone haywire. :-)

> 
> Have you (or do you have first hand knowledge of anyone who has) ever
> used an Ada Rendezvous in an RTOS environment, such as, say, Vxworks? Or
> do you, like everyone I have ever met, use the OS services (semaphores
> etc.) directly?

Well, that depends on what y'all mean by "an RTOS environment". I built
a rocket engine control based on a Mil-Std-1750a microprocessor which
had 7 threads of control, 5 of which were tasks. We used Ada entries to
initiate aperiodic and periodic tasks, but they were just simple
entries, so the rendesvous was the simplest form and not very expensive.
The higher speed tasks (1ms, 5ms) had some data sharing or
synchronization issues which would have been well served by parameters &
the handshaking possible with the rendesvous, but the time was too
costly for the poor little 1750a. ****VERY IMPORTANT NOTE!!!!**** Before
someone runs off screaming about how this "proves" that Ada sucks, let
me state this: We were using ****ADA83!!!**** with the XD-Ada compiler
and did not have access to the more efficient constructs of Ada95
(protected types, etc.). So now the situation is a bit different -
although I know of no Ada95/1750a compiler and if one exists I have not
had a chance to see its code generation. (XD-Ada was pretty good for the
type of code we do.)

So XD-Ada provided its own built-in RTOS which is pretty common for
those of us in the bare machine business. A close comparison would be
using something like RTEMS with the GNAT compiler, but I've never done
any real time work with this setup. I have *never* used an RTOS of the
kind that most "real time" programmers are used to (versions of MS-DOS,
etc.) I have no objections to these - they just never seem to fit what
we do. Basically, we start with the Ada support and build up a real time
executive on top of that which allows our logic designers to schedule
their workload and have all their I/O handled. This is not the
environment most people are familiar with WRT real time.

Other controls we have done have had faster processors but used fewer
tasks, mostly because they were started a very long time ago before Ada
tasking had been reasonably well understood and optimized. We don't have
any problems doing tasks, etc. in Ada mostly because we were willing to
simply bite the bullet and learn how to use Ada effectively. Most of the
folks in our little shop here have grown quite expert in it and have
learned to love it over the years.

> 
> > Tasks in Ada provide parallelism in a machine-independent and
> > invisible-to-the-programmer manner. I do not know of a similar mechanism
> > in either C++ or Java. Maybe it is there. Maybe not. You'd need someone
> > else to fill you in on that.
> 
> Java has threads. In C++ it is more of a library issue. The C++ standard
> doesn't address it but Posix does. The RTOS probably includes a Posix
> library and if it doesn't, it probably doesn't support Ada either.

Sorry. I don't know much of anything about "Posix" except that it is
generally associated with Unix. We're down at the bare metal with hard
real time constraints so we don't have the luxury of a "real" operating
system. I hear that most of the Ada implementations that ride on top of
something like Unix will use as their underlying implementation of
tasking, Posix calls or similar. Still, this supports the point that the
language hides all of this from you and does it in a portable manner.

> 
> You need to be concerned with reentrancy and synchronization issues when
> you choose a C++  STL library, especially if you plan to use iostreams
> or other such goodies.
> 
> KLK

Ada subprograms are naturally reentrant (except of course when the
programmer does stuff like accessing global memory without appropriate
cautions.) and there are mechanisms for handling synchronization, so I
kind of enjoy not having to worry so much about it. However one of
Ada95's claim to fame is as the "glue" language for interfacing to
libraries, etc. in other languages. (I've done some of this with
Win32api calls, but not enough to consider myself an expert.) Obviously,
when doing this it is wise to know about the calling conventions, etc.
of the other language lest you create havoc with reentrancy from
multiple tasks.

I understand that CLAW - an interface to Win32api built by RR Software -
is supposed to wrap the Win32api calls up in appropriate Ada constructs
to make them tasking-safe. Something like this might be of value to more
than just Ada programmers.

MDC

-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

    "Nobody shot me."

        --  Last words of Frank Gusenberg when asked by police who
            shot him fourteen times with a machine gun in the Saint
            Valentine's Day Massacre.

Re: Ada vs C++ vs Java

[Ken Keys]

Marin David Condic wrote:

> Well, that depends on what y'all mean by "an RTOS environment". I built
> a rocket engine control based on a Mil-Std-1750a microprocessor which

I really meant an OS which has support for tasks/threads independent of
the application program. That would certainly apply to UNIX/VMS/NT, but
I was more interested in cases where there was some incentive to be
small, fast or both which is why I used VxWorks as an example.

> So XD-Ada provided its own built-in RTOS which is pretty common for
> those of us in the bare machine business. A close comparison would be

So obviously you are not going to bypass Ada and talk directly to the
RTOS.

OK, you made me do it. I'm going to toss in a war story of my own.

Back in the 80's I was involved in a bare metal Ada project. It was
entirely interrupt driven and didn't use tasks as such. Therefore, it is
not directly applicable to the above discussion. However, it involves
some language issues which apply to the outer thread.

We used the Telesoft compiler which left a lot to be desired. More
important, it was a very Ada-unfriendly design. It was a direct port
from a C program which was in turn a more or less direct port from an
assembly language program that ran on a different processor. As just one
example, the design made heavy use of packed flag words and masks. At
the time Ada did not have a bit wise AND operator, so we emulated the
operation (rather expensively) with bit field operations. 

Not surprisingly, the Ada version was much bigger and much slower than
the C version. (We measured the performance by increasing the input data
rate until the program started missing interrupts.) If I would have had
the leeway (and the time) to make some design changes, I'm sure that I
could have brought the performance of the Ada version more in line with
that of the C version. However, getting the size of the Ada version down
would have required a better compiler.

KLK

Re: Ada vs C++ vs Java

[dennison]

In article <369F911E.8A85D333@west.raytheon.com>,
  Ken Keys <klkeys@west.raytheon.com> wrote:
> Marin David Condic wrote:
>
> > Well, that depends on what y'all mean by "an RTOS environment". I built
> > a rocket engine control based on a Mil-Std-1750a microprocessor which
>
> I really meant an OS which has support for tasks/threads independent of
> the application program. That would certainly apply to UNIX/VMS/NT, but
> I was more interested in cases where there was some incentive to be
> small, fast or both which is why I used VxWorks as an example.

You have a highly unusual definition of RTOS, if Windows NT qualifies...

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[dennison]

In article <369F911E.8A85D333@west.raytheon.com>,
  Ken Keys <klkeys@west.raytheon.com> wrote:
> Marin David Condic wrote:
>
> > Well, that depends on what y'all mean by "an RTOS environment". I built
> > a rocket engine control based on a Mil-Std-1750a microprocessor which
>
> I really meant an OS which has support for tasks/threads independent of
> the application program. That would certainly apply to UNIX/VMS/NT, but
> I was more interested in cases where there was some incentive to be
> small, fast or both which is why I used VxWorks as an example.

You have a highly unusual definition of RTOS if NT qualifies...

> We used the Telesoft compiler which left a lot to be desired. More
> important, it was a very Ada-unfriendly design. It was a direct port
> from a C program which was in turn a more or less direct port from an
> assembly language program that ran on a different processor. As just one
> example, the design made heavy use of packed flag words and masks. At
> the time Ada did not have a bit wise AND operator, so we emulated the
> operation (rather expensively) with bit field operations.

Acutally, Ada has *always* had a bit-wise AND. The trick was that in Ada83 it
was only defined for arrays of boolean. If you are dealing with flag words
anyway, that's probably the type you should have been using.


T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Marin David Condic]

Ken Keys wrote:
> 
> Marin David Condic wrote:
> 
> > Well, that depends on what y'all mean by "an RTOS environment". I built
> > a rocket engine control based on a Mil-Std-1750a microprocessor which
> 
> I really meant an OS which has support for tasks/threads independent of
> the application program. That would certainly apply to UNIX/VMS/NT, but
> I was more interested in cases where there was some incentive to be
> small, fast or both which is why I used VxWorks as an example.
> 
Believe me, if we had a commercial RTOS thrown into my little 1750 job,
we'd have had no room left for the application! The XD-Ada runtime
support for the whole of the Ada language, including the support for all
of the tasking, was really incredibly small. The poor little box only
had 64k words of memory for the whole job. By the time we were driving
an RL10 rocket engine out on the stand, we were up to 90% memory
utilization. I doubt we could have tolerated any unused OS routines
lying around.

It's been said that an elephant is a mouse with an operating system.


> > So XD-Ada provided its own built-in RTOS which is pretty common for
> > those of us in the bare machine business. A close comparison would be
> 
> So obviously you are not going to bypass Ada and talk directly to the
> RTOS.
>
I'm not sure I understand. There was no RTOS in the sense that most
people use the word. Just a small collection of runtime support code to
implement the tasking primitives needed to schedule tasks and handle
rendesvous. There really wasn't anything to "call directly" - well, I
guess we could have connected up to the primitives directly, but why?
It's the same call the compiler would generate for you when using the
"accept XYZ" statement anyway.

I guess I'd apply the same logic if I had an RTOS or a "real" OS like
VMS or NT. I could bother to learn all the OS calls to synchronize up
threads and pass data between them, etc., but why bother? If the
compiler is not a P.O.S., it's going to degenerate the Ada statements
into exactly those OS calls anyway, so why go to the trouble and risk of
trying to call them directly?

> OK, you made me do it. I'm going to toss in a war story of my own.
> 
> Back in the 80's I was involved in a bare metal Ada project. It was
> entirely interrupt driven and didn't use tasks as such. Therefore, it is
> not directly applicable to the above discussion. However, it involves
> some language issues which apply to the outer thread.
> 
> We used the Telesoft compiler which left a lot to be desired. More
> important, it was a very Ada-unfriendly design. It was a direct port
> from a C program which was in turn a more or less direct port from an
> assembly language program that ran on a different processor. As just one
> example, the design made heavy use of packed flag words and masks. At
> the time Ada did not have a bit wise AND operator, so we emulated the
> operation (rather expensively) with bit field operations.
> 
> Not surprisingly, the Ada version was much bigger and much slower than
> the C version. (We measured the performance by increasing the input data
> rate until the program started missing interrupts.) If I would have had
> the leeway (and the time) to make some design changes, I'm sure that I
> could have brought the performance of the Ada version more in line with
> that of the C version. However, getting the size of the Ada version down
> would have required a better compiler.
> 
Nice story. We all enjoy telling them, don't we?

The Telesoft compiler was pretty crappy and the folks who were running
the show were not doing a good job of customer support. (At least not to
*this* customer!) It was many early implementations like this which
succeeded in giving Ada a bad reputation. I guess compiler technology
sort of had to catch up to the language, eh?

At least Ada95 managed to get a good deal of those early Ada83
weaknesses taken care of. Bit level operations, unsigned integers,
passive tasks, etc, all went a long way at improving life at the
embedded level. While I have not yet acquired any direct personal
experience with anybody hawking what would claim to be an "avionics
quality" real time Ada95 compiler, I know some people in house who have
done some evaluations of what is out there. So far, I have not heard any
excessive cursing over the wall about gross inefficiencies, etc. so I'm
guessing there are reasonably good quality Ada95 compilers out there for
real time work. I know that lots of the vendors have done a good job at
optimizing their back ends, and they seem to understand the language
well enough that I have heard no complaints about performance from those
using compilers on Unix and WinNT systems. I really wish this had been
the case in the early days of Ada, but at least we're there now.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

    "Nobody shot me."

        --  Last words of Frank Gusenberg when asked by police who
            shot him fourteen times with a machine gun in the Saint
            Valentine's Day Massacre.

Re: Ada vs C++ vs Java

[Matthew Heaney]

Marin David Condic <condicma@bogon.pwfl.com> writes:

> At least Ada95 managed to get a good deal of those early Ada83
> weaknesses taken care of. Bit level operations, unsigned integers,
> passive tasks, etc, all went a long way at improving life at the
> embedded level. While I have not yet acquired any direct personal
> experience with anybody hawking what would claim to be an "avionics
> quality" real time Ada95 compiler, I know some people in house who have
> done some evaluations of what is out there. So far, I have not heard any
> excessive cursing over the wall about gross inefficiencies, etc. so I'm
> guessing there are reasonably good quality Ada95 compilers out there for
> real time work. I know that lots of the vendors have done a good job at
> optimizing their back ends, and they seem to understand the language
> well enough that I have heard no complaints about performance from those
> using compilers on Unix and WinNT systems. I really wish this had been
> the case in the early days of Ada, but at least we're there now.


Check out the Ravenscar profile, which defines a high-integrity
real-time subset.  At least one vendor (through Aonix) sells a certified
Ada run-time that implements the subset.

Future work by the safety-wg is to standardize on a set of restriction
pragmas for use specifically with the Ravenscar profile.

Re: Ada vs C++ vs Java

[Marin David Condic]

Matthew Heaney wrote:
> 
> Check out the Ravenscar profile, which defines a high-integrity
> real-time subset.  At least one vendor (through Aonix) sells a certified
> Ada run-time that implements the subset.
> 
> Future work by the safety-wg is to standardize on a set of restriction
> pragmas for use specifically with the Ravenscar profile.

One of my partners in crime down here in Florida - Sam Hoover - has
spent some time evaluating the Aonix compiler targeted to the PowerPC
chip. He was looking at the safety critical subset stuff along with
efficiency issues, etc., to evaluate the whole thing for use on the
PW6000 engine (commercial, not military - just in case anybody wants to
make claims that Ada is only used in military stuff, and then only
because we were forced to.)

I have not discussed the full details of the analysis with Sam but from
what he has shared with me, it looks pretty good. Given the speed
potential of the PowerPC, we don't think we are going to have issues
with code generation. I don't know that it makes the tightest code
possible - I have not looked into it that far. If we were really in a
tight CPU budget the standards for acceptability would be much higher.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

    "Nobody shot me."

        --  Last words of Frank Gusenberg when asked by police who
            shot him fourteen times with a machine gun in the Saint
            Valentine's Day Massacre.

Re: Ada vs C++ vs Java

[dennison]

In article <369E4A41.8D7DDA14@west.raytheon.com>,
  Ken Keys <klkeys@west.raytheon.com> wrote:

> Have you (or do you have first hand knowledge of anyone who has) ever
> used an Ada Rendezvous in an RTOS environment, such as, say, Vxworks? Or
> do you, like everyone I have ever met, use the OS services (semaphores
> etc.) directly?

Right here. Our first crack at a scheduler here did just that. If you think
about it, in a good RTOS a rendezvous can be supported almost entirely via the
RTOS' tasking exec and mutual-exclusion mechanisms. On VxWorks that means a
semaphore. However, with Ada95 you don't actually need rendezvous to achieve
mutual exclusion or perform real-time task scheduling. The "delay until"
statement allows tasks to be scheduled at a specific rate by the RTOS itself.
And of course the language allows you to set task priorities (in a portable
manner too). Using those two facts, one can acutally create a RMT real-time
application that will run on *any* RMT-supporting RTOS with just a recompile.
The only non-portable scheduling code we have is the call that sets the clock
rate (VxWorks' default of 60Hz wasn't fast enough for us).

Simple (or evey fairly complicated) mutual exclusion can be more efficiently
accomplished w/ protected objects than rendezvous. Thus there really isn't
much call for rendezvous anymore, unless you want the data-passing
client/server interaction they provide.

Use the OS directly? Yuk. Then you'd loose the portability. That's sort of
like optimizing; You shouldn't bother unless you are known to be operating
too slowly, and the changes *will* solve that problem.

> Java has threads. In C++ it is more of a library issue. The C++ standard
> doesn't address it but Posix does. The RTOS probably includes a Posix
> library and if it doesn't, it probably doesn't support Ada either.

That's fine, if you can live with being tied to POSIX RTOS's. But why tie
yourself down when you don't have to?


T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Ralph Cook]

Erik Funkenbusch wrote:

> It's not a very cut and dried situation i'm afraid.
>
> (comments below)
>
> Leszek Sczaniecki <lsczan@concentric.net> wrote in message
> news:369C1F31.AE5AF7EF@concentric.net...
> >We are about to start a big project, something about 250k lines of code.
> >We are going to stick to it for next several years. We would like to
> >make an educated choice for the underlying language. This language
> >should
>
> I don't think size of the project has much influence over the choice when
> considering language.  At least not in the languages you've mentioned.
>
> >- support object oriented programming
>
> All three do, although at differing levels and differing feature sets
> (example:  Java doesn't support Multiple Inheritance, C++ does.  But that
> may not be a concern to you).
>
> >- support parallel programming
>
> I'm not sure exactly what you mean by that.  You mean multi-processor
> support?  Threads?  Those are OS constructs, but of course the Language has
> to be able to handle them (VB for instance doesn't do a good job of that).

I like Java's standard constructs for threads, if that meets your case.

> >- lead to easily maintainable code
>
> No language will do that.  It's a function of design.

hear, hear.

> >- promote safe programming techniques
>
> Be aware that "safe" often means "confining".  You may not be able to do the
> things you need to do in a language that doesn't support pointers or direct
> hardware access (like Java).

see "easily maintainable code".  Safe programming techniques are not a
language choice issue, though I find pointer use in C and C++ to be very
error-prone.

> >- have significant support from commercial vendors (compilers, GUI
> >design, testing sw)
>
> Well, Java is gaining a lot of vendor support.  But be aware that the
> language is changing rapidly and that there is no standardization of it.

This is a lie.  Sun has been criticized for controlling its standardization too
much.

The language has evolved, so that versions 1.0, 1.1, and 1.2 are more different
than
similar version numbers of, say, a compiler for an already defined language.
But there
IS a standard, regardless of what MS thinks.

> New versions are likely to make older code obsolete (for instance, the
> switch from 1.0.x to 1.1 introduced whole new event models).  It's a very
> immature language and is likely to go through a lot more growing pains.

Your bias against Java is obvious: let me restate this in a less
negative way.  The language has gone through many changes; how many
it has to go through yet before being considered "mature" is a matter of
opinion.  I think, myself, that the parts of the it they didn't get quite right
in the first place are mostly reworked satisfactorily now, and that
growth and change will slow down greatly.  Others (obviously) think
differently on the subject.

Be sure, in your research on Java, to differentiate between the net and
browser world (much of which is just now converting to 1.1) and those
people without the installed browser base that are (more) free to use
Java's current version.

> >- be available for popular processors (such as 68xxx, PowerPC, etc.)
>
> Processors aren't the key, OS platforms are.  You're most safe with C++ on
> this matter i think.  Java isn't available on everything yet.  You're also
> likely to find limited choices in ADA compilers on more obscure OS's.

Well, look at WHAT processors and OSs you want to run, and then what
languages are available for them.  There is also the matter of compatiblity;
Java programs are object-code-compatible across processors.  You don't
say whether you want to run on different platforms with the same version of
your code.

> >- support "almost real time" execution
>
> Well, Java certainly can't do this yet.  C++ can, depending on OS support.
> ADA most certainly does, or it wouldn't be able to be used in Jet Avionics
> and such.

Unfortunately, the phrase is meaningless, so we can't say what languages
can and cannot do this (on what processors and OSs, again).  Real-time
means a lot of things, but really what somebody needs is "fast enough".
Whether you're doing human genome mapping or GUI interaction makes
a lot of difference.  Don't get caught in the trap of thinking faster is always
better unless you really need all the speed you can get -- there are VERY few
applications/systems like that (and FORTRAN still has C, C++, and Java all
beat in this regard).

> >- be suitable for design of embedded systems
>
> C++ generally isn't.  There is an "embedded C++" that's in the works, and
> there might even be some implementations.  C is better for embedded work
> than C++.  I don't know the specifics of ADA embedded work.

And Java can work well in many embedded environments, and has definitions
of EmbeddedJava and PersonalJava for the purpose.  I note that the original
responder doesn't mention this...

> >There is a legacy code written in Ada and our customer would prefer Ada
> >95. However, we became seriously concerned that there is not sufficient
> >support for Ada in the commercial world.
>
> Well, there seems to be plenty of vendor support for ADA, but I think you
> won't find as much 3rd party library support.  That means you'll be stuck
> writing everything from scratch in most cases.
>
> >Given, that we will be stuck
> >with our project for the next several years we would like to choose
> >something that still will have adequate support few years down the road.
> >Given all that we decided to check C++ and Java. I would appreciate
> >greatly any comparisons, comments, hints, pointers to electronic and
> >hard copy sources, warnings about traps and pitfalls, etc. that would
> >help us thoroughly justify the language choice to our customer.
>
> Well, I would vote against Java.  It's too immature for a long term project
> and has questionable speed.

And I would vote for Java; you need to figure out if there is enough speed
(for your environments and applications) *regardless* of your language.
The runtime environment is far easier to debug, and the language itself is
more strictly OO, without the baggage of C compatibility.  I find Java's
changes to be less of a problem than things about C++ that will not change.

> Your choice of ADA and C++ has many factors.  It's likely going to be easier
> to find people to maintain C++ code than ADA.  It's also got more 3rd party
> support.  Both are standardized, although not all current compilers support
> the full standard C++ yet (in fact, I don't know of any that are fully
> compliant yet).

Isn't it wonderful to have a standard that no one supports?
What does that mean?

And there *is* a java standard; go and get the books from Barnes
& Noble if you want.

Again, the previous poster seems to have given up on Java.
I would expect people familiar with Java to be more numerous
than for Ada, but I don't have numbers and don't really know.
Actually, I'd try to hire good programmers and have them use
whatever language got chosen; good programmers are harder
to find than people who know the tricks of one language.

rc
--
When I do speak for my company, I list my title and use "we".

Re: Ada vs C++ vs Java

[Bob Munck]

On Wed, 13 Jan 1999 14:47:38 -0500, Ralph Cook <rcook@pobox.com>
wrote:

>And there *is* a java standard; go and get the books from Barnes
>& Noble if you want.

Really?  How did that slip by?  I've seen nothing about this on the
SC22 mailing list (ISO/IEC JTC1/SC22 Java Study Group, convened
by old-Ada-hand Bob Mathis)

It might be more correct to say that there is a _proposed_ Java
standard, though even that is stretching it a bit since Sun hasn't
even submitted the PAS for review.

>Again, the previous poster seems to have given up on Java.

Not only him; I've seen Java on a couple of "whatever happened
to... ?" and "where are they now?" lists of technology whose time
has come and gone.

Bob Munck
Mill Creek Systems LC

Re: Ada vs C++ vs Java

[Erik Funkenbusch]

Ralph Cook <rcook@pobox.com> wrote in message
news:369CF85A.B108ACA8@pobox.com...
>> Well, Java is gaining a lot of vendor support.  But be aware that the
>> language is changing rapidly and that there is no standardization of it.
>
>This is a lie.  Sun has been criticized for controlling its standardization
too
>much.

Ummm.. Standardization means standardization by a public comittee like ISO
or ANSI.  While Sun has made a lot of hoopla about making Java an ISO
standard, it's not even really begun yet.

>The language has evolved, so that versions 1.0, 1.1, and 1.2 are more
different
>than
>similar version numbers of, say, a compiler for an already defined
language.
>But there
>IS a standard, regardless of what MS thinks.

Who said anything about MS?  The fact is that Java can change at Sun's whim.
That's not a standard, nor is it something you want to base a long term
project on.

>> New versions are likely to make older code obsolete (for instance, the
>> switch from 1.0.x to 1.1 introduced whole new event models).  It's a very
>> immature language and is likely to go through a lot more growing pains.
>
>Your bias against Java is obvious: let me restate this in a less
>negative way.  The language has gone through many changes; how many
>it has to go through yet before being considered "mature" is a matter of
>opinion.  I think, myself, that the parts of the it they didn't get quite
right
>in the first place are mostly reworked satisfactorily now, and that
>growth and change will slow down greatly.  Others (obviously) think
>differently on the subject.

Are you willing to bet your next 20 year project on that?  Suppose your (or
others) life depended on it.  Java hasn't even been around long enough to
prove it's stability over time.  I'm not saying that it's not stable, I'm
simply saying that it isn't old enough to get valid statistics.

>> >- support "almost real time" execution
>>
>> Well, Java certainly can't do this yet.  C++ can, depending on OS
support.
>> ADA most certainly does, or it wouldn't be able to be used in Jet
Avionics
>> and such.
>
>Unfortunately, the phrase is meaningless, so we can't say what languages
>can and cannot do this (on what processors and OSs, again).  Real-time
>means a lot of things, but really what somebody needs is "fast enough".

Real time doesn't mean a lot of things.  It has a pretty well defined
meaning.  It means the ability to react to external time-critical events as
they happen.  For instance, you don't want a fly-by-wire aircraft avionics
system to have to wait 150 ms's to process that a wind gust has just pushed
a plane going Mach 7 downwards.

>Whether you're doing human genome mapping or GUI interaction makes
>a lot of difference.  Don't get caught in the trap of thinking faster is
always
>better unless you really need all the speed you can get -- there are VERY
few
>applications/systems like that (and FORTRAN still has C, C++, and Java all
>beat in this regard).

in many applications faster is always better, as long as accuracy is also
present.  You might be surprised at how many time-critical applications
there really are.  An ATM network might not seem like it's speed sensitive,
but it is.  When processing millions of transactions an hour speed is of
very great importance.

Don't get caught in the trap of thinking that every application is a
stand-alone application running on a single user PC.

>> C++ generally isn't.  There is an "embedded C++" that's in the works, and
>> there might even be some implementations.  C is better for embedded work
>> than C++.  I don't know the specifics of ADA embedded work.
>
>And Java can work well in many embedded environments, and has definitions
>of EmbeddedJava and PersonalJava for the purpose.  I note that the original
>responder doesn't mention this...

Both of which do not exist in practical form yet.

>> Well, I would vote against Java.  It's too immature for a long term
project
>> and has questionable speed.
>
>And I would vote for Java; you need to figure out if there is enough speed
>(for your environments and applications) *regardless* of your language.
>The runtime environment is far easier to debug, and the language itself is
>more strictly OO, without the baggage of C compatibility.  I find Java's
>changes to be less of a problem than things about C++ that will not change.

So, tell me.  If you were about to start a 15 year project in which you
cannot go back and rewrite code because of compiler changes, and you were
betting your own personal fortune on it's success (if not your life).  Would
you still choose Java?

>> Your choice of ADA and C++ has many factors.  It's likely going to be
easier
>> to find people to maintain C++ code than ADA.  It's also got more 3rd
party
>> support.  Both are standardized, although not all current compilers
support
>> the full standard C++ yet (in fact, I don't know of any that are fully
>> compliant yet).
>
>Isn't it wonderful to have a standard that no one supports?
>What does that mean?

The standard was only ratified last year (1998).  It takes time for
implementations to match the standard.  Yes, It's true that the standard has
been roughly static for about 2 years, but most compiler vendors didn't want
to take the chance of it changing yet again (like it's done several times
before when it was "almost done").  The standard is done, it's now a matter
of vendors implementing it.

>And there *is* a java standard; go and get the books from Barnes
>& Noble if you want.

There is no international standard for Java.  Java is what Sun says it is,
and that's not a standard.

>Again, the previous poster seems to have given up on Java.
>I would expect people familiar with Java to be more numerous
>than for Ada, but I don't have numbers and don't really know.
>Actually, I'd try to hire good programmers and have them use
>whatever language got chosen; good programmers are harder
>to find than people who know the tricks of one language.

And what do you do when all you have are people that know the tricks of one
language and can't find any "good" programmers?

Re: Ada vs C++ vs Java

[Dave Whipp]

Ralph Cook wrote:

> > >- support parallel programming
> >
> > I'm not sure exactly what you mean by that.  You mean multi-processor
> > support?  Threads?  Those are OS constructs, but of course the Language has
> > to be able to handle them (VB for instance doesn't do a good job of that).
> 
> I like Java's standard constructs for threads, if that meets your case.

I find Java's thread support a bit like C's memory management support. i.e.
you have to do it yourself using primitives supplied in the library (using
the runnable interface and the thread class).

Languages like Ada (or Occam, or various others) provide more complete
support for parallelism. The programmer just uses the appropriate block
declaration.

If you look at hardware description languages (e.g. VHDL or Verilog)
then parallelism is the default: sequential operations are either inferred
through data dependencies or are explicitly programmed. When an RTL
architecture is used, a synthesis tool can be used with a constraints file
to optimise the speed/space tradeoffs for an implementation.

A few software languages do the same. For example, the language used with
the Shlaer-Mellor method uses an asynchronous execution model. There is
no stack, (nor functions/procedures). Processes can execute in parallel
unless constrained. When you use a language like this, you need to use
techniques like those of aspect-oriented-programming to constrain an
implementation to a specific thread model. (SM uses the term 'architecture'
for this aspect)

There are very few mainstream langauges that have comprehensive support for
parallism. Ada probably comes closest. Languages like C++ or Java are
able to interact with an OS (or the VM) to allow threading; but they don't,
themselves, support it.


Dave.

-- 
Dave Whipp, Siemens AG: HL DC PE MC, MchM, Munich, Germany
mailto:David.Whipp@hl.Siemens.de  Phone. +49 89 636 83743
Opinions are my own. Factual statements may be in error.

Re: Ada vs C++ vs Java

[Michael J. Tobler]

Erik Funkenbusch wrote:
[snip]
> 
> >- support object oriented programming
> 
> All three do, although at differing levels and differing feature sets
> (example:  Java doesn't support Multiple Inheritance, C++ does.  But that
> may not be a concern to you).

Java does support multiple-interfaces, so there is a sort of
"simulation" of multiple inheritance. But there are reasons
the designers opted not to provide "true" MI, reasons I wont
go into in this thread.

> >- support parallel programming
> 
> I'm not sure exactly what you mean by that.  You mean multi-processor
> support?  Threads?  Those are OS constructs, but of course the Language has
> to be able to handle them (VB for instance doesn't do a good job of that).
> 
> >- lead to easily maintainable code
> 
> No language will do that.  It's a function of design.

And the people writing the code.

> >- promote safe programming techniques
> 
> Be aware that "safe" often means "confining".  You may not be able to do the
> things you need to do in a language that doesn't support pointers or direct
> hardware access (like Java).

I think here it's meant that you cant do anything "crazy"
and have some wild pointer or what-not. The OS should take
care of this for you; yet, there are reasons you might
want a language to help you in this respect. Say, something
like handling array-out-of-bounds, etc.

> >- have significant support from commercial vendors (compilers, GUI
> >design, testing sw)
> 
> Well, Java is gaining a lot of vendor support.  But be aware that the
> language is changing rapidly and that there is no standardization of it.
> New versions are likely to make older code obsolete (for instance, the
> switch from 1.0.x to 1.1 introduced whole new event models).  It's a very
> immature language and is likely to go through a lot more growing pains.

This is a mistake that a lot of people are making. The JDK is
changing rapidly - I dont necessarily see this as a hinder as
more functionality is coming to the forefront. The LANGUAGE proper
hasnt really changed. Hey - there's something to be said for a 
language that doesnt support "goto".

> >- be available for popular processors (such as 68xxx, PowerPC, etc.)
> 
> Processors aren't the key, OS platforms are.  You're most safe with C++ on
> this matter i think.  Java isn't available on everything yet.  You're also
> likely to find limited choices in ADA compilers on more obscure OS's.

You cant say C++ is "more safe" in this matter. It depends how the
system is designed and coded. I can write a program targeted for the
unix platform that will pure h@ll to port anywhere else. It is harder
to do this in Java. BTW, I build a lot of C++/Java/CORBA systems and
haven't found a platform that didnt run Java. Yea, maybe some obscure
platform ....

> >- be suitable for design of embedded systems
> 
> C++ generally isn't.  There is an "embedded C++" that's in the works, and
> there might even be some implementations.  C is better for embedded work
> than C++.  I don't know the specifics of ADA embedded work.

You're off-target here. There are a handfull of vendors offering
C++ tools for the embedded systems market. Saying that C is better
than C++ is just not valid.

[snip]
> >Given, that we will be stuck
> >with our project for the next several years we would like to choose
> >something that still will have adequate support few years down the road.
> >Given all that we decided to check C++ and Java. I would appreciate
> >greatly any comparisons, comments, hints, pointers to electronic and
> >hard copy sources, warnings about traps and pitfalls, etc. that would
> >help us thoroughly justify the language choice to our customer.
> 
> Well, I would vote against Java.  It's too immature for a long term project
> and has questionable speed.

I think you should educate yourself concerning Java. As I've said,
we've been building Java (collaborative, multi-tier) systems for
about 3 years now and the customers are very happy. I am currently
on a C++/Java/CORBA project that is 90% Java and 10% C++. The coding
is going VERY fast - I find that we can code a system much faster,
with less errors in Java than in C++. I'm not knocking C++ because
it's my TRUE language, but I have found power in Java.

To address you concern for speed with Java - that issue
is out the door. We are using JIT tools that get us to
C++ like speed. Depending on platform, you can get tools
to build true binary executables.

[snip]

-- 
<<<<<<<<<<< Blue Skies >>>>>>>>>>>>
<       Michael J. Tobler         >
< remove "no-spam"when replying   >
< mailto:mtobler@no-spam-ibm.net  >
< http://www.webbrew.com/toblermj >
<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>

Re: Ada vs C++ vs Java

[Erik Funkenbusch]

Michael J. Tobler <mtobler@no-spam-ibm.net> wrote in message
news:369DF242.B0613E1C@no-spam-ibm.net...
>Erik Funkenbusch wrote:
>> All three do, although at differing levels and differing feature sets
>> (example:  Java doesn't support Multiple Inheritance, C++ does.  But that
>> may not be a concern to you).
>
>Java does support multiple-interfaces, so there is a sort of
>"simulation" of multiple inheritance. But there are reasons
>the designers opted not to provide "true" MI, reasons I wont
>go into in this thread.

I wasn't criticizing Java over this.  I was simply stating the fact that
there are differing levels of OO features in the different languages.  Don't
be so sensitive just because I used Java as an example.  I could have just
as easily said that C++ doesn't provide the flexibility of Java with nested
classes.

>> Be aware that "safe" often means "confining".  You may not be able to do
the
>> things you need to do in a language that doesn't support pointers or
direct
>> hardware access (like Java).
>
>I think here it's meant that you cant do anything "crazy"
>and have some wild pointer or what-not. The OS should take
>care of this for you; yet, there are reasons you might
>want a language to help you in this respect. Say, something
>like handling array-out-of-bounds, etc.

Which doesn't change the point that "safe" languages do not allow some
things which are necessary to do certain things.  For instance, you can't
use Java to point to a memory mapped I/O structure.  C++ can (because it
allows pointers).

>> Well, Java is gaining a lot of vendor support.  But be aware that the
>> language is changing rapidly and that there is no standardization of it.
>> New versions are likely to make older code obsolete (for instance, the
>> switch from 1.0.x to 1.1 introduced whole new event models).  It's a very
>> immature language and is likely to go through a lot more growing pains.
>
>This is a mistake that a lot of people are making. The JDK is
>changing rapidly - I dont necessarily see this as a hinder as
>more functionality is coming to the forefront. The LANGUAGE proper
>hasnt really changed. Hey - there's something to be said for a
>language that doesnt support "goto".

The problem is that you can't differentiate the language from the
environment in Java.  If the environment changes, so must your programs.
Whole features of Java have been deprecated and will be going away in future
versions.  The point is that this kind of change is not good for a long term
project that must rely on the code to continue functioning.

What's worse with Java is that since it's a run-time language.  If the JVM
changes, existing compiled code will no longer work.  WIth a compiled
language the already compiled code continues to function no matter what
changes occur in the language.  In other words, it's very likely that you
won't be able to use Java 1.0 byte code with Java 3.0 byte code.

>> Processors aren't the key, OS platforms are.  You're most safe with C++
on
>> this matter i think.  Java isn't available on everything yet.  You're
also
>> likely to find limited choices in ADA compilers on more obscure OS's.
>
>You cant say C++ is "more safe" in this matter. It depends how the
>system is designed and coded. I can write a program targeted for the
>unix platform that will pure h@ll to port anywhere else. It is harder
>to do this in Java. BTW, I build a lot of C++/Java/CORBA systems and
>haven't found a platform that didnt run Java. Yea, maybe some obscure
>platform ....

I didn't use safe in the same way you are.  I said "most safe with C__ *ON
THIS MATTER*".  This simply means that C/C++ compilers are more common than
either Ada or JVM's.

Never found a platform that doesn't run Java?  How about BeOS?  How about
WindowsCE?  How about Real-time operating systems?  How about a standard
embeded processor without any OS?  The point is that "some obscure platform"
is the most likely going to be the target platform for an embedded system.

>> C++ generally isn't.  There is an "embedded C++" that's in the works, and
>> there might even be some implementations.  C is better for embedded work
>> than C++.  I don't know the specifics of ADA embedded work.
>
>You're off-target here. There are a handfull of vendors offering
>C++ tools for the embedded systems market. Saying that C is better
>than C++ is just not valid.

Better meaning "more availability".  A "handful" of vendors is very
different from hundreds of implementations.  The fact is, apart from
assembler, C is the most common langauge used in embedded systems.  There
are far more C compilers for embedded systems than anythign else.  C++ also
tends to generate large code.  That's not good for embedded applications
where you have maybe 4K of ROM.  Embedded is getting much bigger today, and
C++ will certainly be easier to use in today's embedded applications than
yesterday's.

>> Well, I would vote against Java.  It's too immature for a long term
project
>> and has questionable speed.
>
>I think you should educate yourself concerning Java. As I've said,
>we've been building Java (collaborative, multi-tier) systems for
>about 3 years now and the customers are very happy. I am currently
>on a C++/Java/CORBA project that is 90% Java and 10% C++. The coding
>is going VERY fast - I find that we can code a system much faster,
>with less errors in Java than in C++. I'm not knocking C++ because
>it's my TRUE language, but I have found power in Java.

And?  You seem adept at diverting the point.  The point is that Java is an
immature platform and language.  It's changing rapidly, and it's likely to
change a lot more before it settles down.  C++ was in that stage until the
last few years, and C++ is more than 15 years old.  3 years is nothing.
Java has a *LOT* more growth ahead of it, and a lot of it will be painful.
Standardization will take at least another 3-5 years and the ISO committees
will demand that a lot of things change.

>To address you concern for speed with Java - that issue
>is out the door. We are using JIT tools that get us to
>C++ like speed. Depending on platform, you can get tools
>to build true binary executables.

JIT doesn't cut it when you're talking about real-time (or near real-time as
required in this case) processing.  I'm sorry, but an aircraft avionics
system cannot wait while the subroutine it needs to use compiles and loads.
Speed of execution is not the only factor of how fast a system runs and how
acceptable the delays introduced by the system are.

Even Native compilers for Java do not produce equivelant code to native C or
C++ code (only in certain circumstances of very poor C++ and very good java
do they compare).

Re: Ada vs C++ vs Java

[Larry Kilgallen]

In article <P4qn2.4877$TO5.139567@ptah.visi.com>, "Erik Funkenbusch" <erikf@visi.com> writes:

> Which doesn't change the point that "safe" languages do not allow some
> things which are necessary to do certain things.  For instance, you can't
> use Java to point to a memory mapped I/O structure.  C++ can (because it
> allows pointers).

But the goal, presumably, is not to "point to" a memory mapped
I/O structure but rather to transfer data to and from it.

If Java does not allow that, it is certainly not because it is
impossible in a "safe" language, since Address Clauses in Ada
(even Ada83) allow you to define an entity (an array of 16-bit
words, for example) and specify its address.  Then you can
iterate through your array (or access specific elements in
your record, if you have chosen a non-uniform representation)
without running off the end as you might if you were programming
in a pointer-centric language.

Larry Kilgallen

Re: Ada vs C++ vs Java

[Chris Gray]

On Thu, 14 Jan 1999, Erik Funkenbusch wrote:

> Never found a platform that doesn't run Java?  How about BeOS?  How about
> WindowsCE?  How about Real-time operating systems?  

There are a couple of people working on porting Kaffe to BeOS in their
spare time: I dare say it could be done rather quickly if one were to
cross Transvirtual's palm with silver.  There are also JVMs for several 
RTOSes: it just takes someone to sit down and do it.  (And someone else
to pay them to do so ;>)

-- 

  Chris Gray            chris@kiffer.eunet.be    chris_gray@bcs.org.uk

Re: Ada vs C++ vs Java

[Gerhard Menzl]

Erik Funkenbusch wrote:

> >- be suitable for design of embedded systems
>
> C++ generally isn't.  There is an "embedded C++" that's in the works, and
> there might even be some implementations.  C is better for embedded work
> than C++.

This claim is completely unfounded. Since C is "for all practical purposes" (as
Bjarne Stroustrup puts it) a subset of C++, there is no reason why C should be a
better choice, providing compilers are available for both languages. Whether
certain *features* of C++ such as templates or exceptions can be reasonably used
on embedded systems is a matter of debate.

Gerhard Menzl

Re: Ada vs C++ vs Java

[John Birch]

On Thu, 14 Jan 1999 13:06:27 +0100, Gerhard Menzl
<gerhard.menzl@sea.ericsson.se> wrote:

>Erik Funkenbusch wrote:
>
>> >- be suitable for design of embedded systems
>>
>> C++ generally isn't.  There is an "embedded C++" that's in the works, and
>> there might even be some implementations.  C is better for embedded work
>> than C++.
>
>This claim is completely unfounded.

There are many embedded programmers who regard the concept of dynamic
memory allocation in an embedded system as laughable at best and a
terminal offence at worst. If you restict C++ in such a way (i.e.
prevented the use of dynamic memory allocation) you'd pretty much end
up with C anyway!

Since I do not regard dynamic memory allocation as a _good_ thing for
most hard embedded systems, I find this claim well founded :-)

> Since C is "for all practical purposes" (as
>Bjarne Stroustrup puts it) a subset of C++, there is no reason why C should be a
>better choice, providing compilers are available for both languages. Whether
>certain *features* of C++ such as templates or exceptions can be reasonably used
>on embedded systems is a matter of debate.

Except that a perfectly valid ANSI C program need not compile or
execute correctly under C++. Consequently, if it's a subset, it's a
pretty poor one!


regards John B.

Re: Ada vs C++ vs Java

[Pat Rogers]

John Birch wrote in message <369e309a.32671759@news.demon.co.uk>...
>On Thu, 14 Jan 1999 13:06:27 +0100, Gerhard Menzl
><gerhard.menzl@sea.ericsson.se> wrote:
>
>>Erik Funkenbusch wrote:
>>
>>> >- be suitable for design of embedded systems
>>>
>>> C++ generally isn't.  There is an "embedded C++" that's in the
works, and
>>> there might even be some implementations.  C is better for
embedded work
>>> than C++.
>>
>>This claim is completely unfounded.
>
>There are many embedded programmers who regard the concept of dynamic
>memory allocation in an embedded system as laughable at best and a
>terminal offence at worst. If you restict C++ in such a way (i.e.
>prevented the use of dynamic memory allocation) you'd pretty much end
>up with C anyway!
>
>Since I do not regard dynamic memory allocation as a _good_ thing for
>most hard embedded systems, I find this claim well founded :-)


While I certainly agree that the default implementation -- in both Ada
95 and C++ -- for dynamic allocation is probably not desirable in a
real-time environment, in both languages once can easily define how
allocation is done while still using the language's syntax (i.e.,
"new", in both).  As a result allocation can be completely
deterministic, without resorting to user-defined functions.  So "don't
throw the baby out with the bathwater" as the saying goes.


---
Pat Rogers                          Training & Development in:
http://www.classwide.com    Deadline Schedulability Analysis
progers@acm.org                 Software Fault Tolerance
(281)648-3165                       Real-Time/OO Languages

Re: Ada vs C++ vs Java

[John Birch]

Pat Rogers wrote in message <77ledn$eu7$1@remarQ.com>...

I originally wrote
>>There are many embedded programmers who regard the concept of dynamic
>>memory allocation in an embedded system as laughable at best and a
>>terminal offence at worst. If you restict C++ in such a way (i.e.
>>prevented the use of dynamic memory allocation) you'd pretty much end
>>up with C anyway!
>>
>>Since I do not regard dynamic memory allocation as a _good_ thing for
>>most hard embedded systems, I find this claim well founded :-)

You replied;

>While I certainly agree that the default implementation -- in both Ada
>95 and C++ -- for dynamic allocation is probably not desirable in a
>real-time environment, in both languages once can easily define how
>allocation is done while still using the language's syntax (i.e.,
>"new", in both).  As a result allocation can be completely
>deterministic, without resorting to user-defined functions.  So "don't
>throw the baby out with the bathwater" as the saying goes.

I feel the issue here is whether you regard any form of run-time memory
allocation a good thing! Whether it is by overriding new is irrelevant. The
very act of designing a program that is not explicitly coded with a known
memory requirement precludes it's use in a system that does not provide a
virtual memory mechanism.

Of course a lot of this depends on your 'view' of the meaning of embedded
system. I still hold to the early definitions that an embedded system
comprised of a CPU, IO (serial / parallel), RAM and ROM (and limited
quantities of it ;-)). At present the term embedded system has come to
encompass even high powered computer systems (at what might be called mini
computer level) providing they are placed in an unusual environment e.g. an
aeroplane.

This has led to the proliferation of 'embedded solutions' that use virtual
memory, disk I/O and operating systems, all of which IMHO encourage a
'never, never approach' to coding. By this I mean that instead of working
within unbreakable memory constraints with static data, programmers choose
to produce solutions that are more open. Whilst initially this appears a
more laudable approach, in the domain of critical software it is potentially
disastrous. What do you do at Mach 2 if your flight control system decides
it needsmore memory because the mission duration is six seconds longer than
the software designer anticipated.

If you are confident that by using C++ you can absolutely determine the
memory footprint of your code under all conditions, then by all means feel
free to use it, but don't expect me to fly with you! I will stick to using
C, static memory structures, avoid pointers unless absolutely necessary and
feel safer for it ;-).

regards John Birch (at home)

Re: Ada vs C++ vs Java

[Pat Rogers]

John Birch wrote in message <77pnqc$cgi$1@newnews.global.net.uk>...
>Pat Rogers wrote in message <77ledn$eu7$1@remarQ.com>...
>I originally wrote
<snip>
>>>Since I do not regard dynamic memory allocation as a _good_ thing
for
>>>most hard embedded systems, I find this claim well founded :-)
>
>You replied;
>
>>While I certainly agree that the default implementation -- in both
Ada
>>95 and C++ -- for dynamic allocation is probably not desirable in a
>>real-time environment, in both languages once can easily define how
>>allocation is done while still using the language's syntax (i.e.,
>>"new", in both).  As a result allocation can be completely
>>deterministic, without resorting to user-defined functions.  So
"don't
>>throw the baby out with the bathwater" as the saying goes.
>
>I feel the issue here is whether you regard any form of run-time
memory
>allocation a good thing! Whether it is by overriding new is
irrelevant. The
>very act of designing a program that is not explicitly coded with a
known
>memory requirement precludes it's use in a system that does not
provide a
>virtual memory mechanism.


It isn't just the overriding of 'new' -- it is how you do it in the
context of the system requirements.  If we override it such that the
block of storage from which it allocates is of a known size, then we
have placed an upper bound on the amount of storage available, as in a
static allocation, but have also retained the flexibility of linked
data structures.

We don't magically say that we can do unbounded allocations just by
overriding 'new', but that, given a proper overriding, we can say that
a) we know the time required per allocation, and b) we know the
maximum storage used. Sure, we have to know what the requirements will
be beforehand, but we don't lose the flexibility.

Re: Ada vs C++ vs Java

[Matthew Heaney]

"John Birch" <johnb@invision.co.uk> writes:

> If you are confident that by using C++ you can absolutely determine the
> memory footprint of your code under all conditions, then by all means feel
> free to use it, but don't expect me to fly with you! I will stick to using
> C, static memory structures, avoid pointers unless absolutely necessary and
> feel safer for it ;-).

This is throwing the baby out with the bath-water.  Ada95 and C++ are
both static languages, just like C.  It is no more difficult to
statically determine storage requirements using those higher-level
languages than it is for C.

In this day and age, there is very little reason to continue using C.

-- 
Those who believe in the supernatural should be required to learn
computer programming.  This would force them to discover that things
which appear at first to be completely mysterious and incomprehensible,
in fact have a logical (and usually simple) explanation.  --J.B.R. Yant

Re: Ada vs C++ vs Java

[Mike Coffin]

Matthew Heaney <matthew_heaney@acm.org> writes:
> This is throwing the baby out with the bath-water.  Ada95 and C++ are
> both static languages, just like C.  It is no more difficult to
> statically determine storage requirements using those higher-level
> languages than it is for C.
> 
> In this day and age, there is very little reason to continue using C.

 Scene: the water cooler in a good sized company.
 Dramatis personae: manager and programmer.

 The curtain rises...

 manager: You should use C++ or Ada.  They're higher level than C.

 programmer: But I hate them.

 manager: But they're higher level!  

 programmer: Yeah, right.  When it first appeared, Ada was the
         laughingstock of programmers everywhere for its insane
         complexity and C++ has managed to outdo it.

 manager: But you'll be more productive! Your types will be checked!
         Your templates will be expanded!  

 programmer: Then let me use Eiffel, or ML, or Scheme, or Haskell, or, 
        or... Those are even higher level. I'll be even more productive.

 manager: But everyone knows that the language doesn't matter!
         Bad programmers can write bad code in any language!  It's the
         quality of the engineer, not the language, that determines
         the quality of the code.

 programmer: So let me use C.

 manager:  But, but, but, but ... it's too low level!  Try C++ or
         Ada!  You'll like it!

 programmer: I used them for years.  I hate them.  I got into this
         business because I like elegance, not baling wire and duct
         tape.  If I had wanted to roll around in the muck I'd have
         been a pig farmer.  Ada gives me a headache; C++ gives me a
         headache *AND* ulcers.

 manager: Well, I'm making an executive decision.  Use C++.  I know
         you don't like it now, but you'll get over it.  

 programmer:  Yup, I will.  I quit.  There: I'm over it.

 Happy ending:

         The project was abandoned after running 2 years late and
         ballooning from 3 programmers to 20.  The code never did
         anything useful, but the types were all checked and the
         templates were all expanded.  The manager was promoted.

         The programmer is now writing Java for an internet startup
         and has stock options worth $3.6 million.  He has an
         occasional mild headache but no ulcers.

-mike

Obviously, not speaking for Sun Microsystems.

Re: Ada vs C++ vs Java

[robert_dewar]

In article <8p64spq5lo5.fsf@Eng.Sun.COM>,
  Mike Coffin <mhc@Eng.Sun.COM> wrote:

> When it first appeared, Ada was the
> laughingstock of programmers everywhere for its insane
> complexity and C++ has managed to outdo it.

In my experience, people who think Ada is an unacceptably
complex language are those who simply don't know it and
prefer to find a reason for rejecting a programming
language without having to make the effort to learn it.

Dave Parnas is an example of a well known person who has
made the statement that Ada is too complex. I challenged
him to a debate, and (to my surprise) he accepted! In the
run up discussion to the debate, he commented that he did
not want to debate technical details because he was not
that familiar with the technical details of Ada, I agreed
to this ground rule. Unfortunately, the debate was
cancelled by Dave because of poor health, and he never
rescheduled it despite my offer to reschedule at any time
or place. It would have been interesting!

Of course there are those for whom Ada is too complex, but
then there are those for whom programming itself is far
too complex, and unfortunately far too many of those kind
of people are graduated with computer science degrees and
working on critical software of various kinds!

> Then let me use Eiffel, or ML, or Scheme, or Haskell

Not out of the question, providing that you know the
language well, and that it is suitable for the task. You
do have to worry about non-programming language issues.
For example, lack of standardization, lack of sufficient
diversity of commercially supported tool sets etc.

>  I used them for years. I hate them. I got into this
>  business because I like elegance, not baling wire and
>  duct tape.

If you really think that you cannot write elegant code
in Ada, then you may have used it for years, but you never
learned it. The same is true for C++. You probably just
have never learned some of the really important elements
of elegance such as data abstraction, and separation of
specification and implementations, since they aren't in
C, they are probably foreign to you. Using Ada and C++
does not necessarily cure this gap in knowledge, learning
them properly does!

As for the argument that any programmer can write horrible
code in any language and that therefore language does not
matter, this is a commonly argued point, but in fact it is
a ludicrous non-sequitur.

It is like saying, a bad doctor can kill patients no matter
what tools they are using, therefore tools don't matter,
therefore let's stop wasting money on xray machines and
other expensive tools.

> The programmer is now writing Java for an internet
> startup and has stock options worth $3.6 million.
> He has an occasional mild headache but no ulcers.

To think that making money is evidence of competence or
quality is particularly naive. I guess you think NT must
be the best operating system in the world *simply because*
Microsoft is making lots of money -- an interesting theory
indeed.

Actually suh internet startups are often typical of
companies that indeed are operating at CMM level 1, and
have internal software practices that are the envy of none.

Here is an interesting test. For all people in your
organization, what would happen if they suddenly changed
jobs and disappeared in 3 days (happens all the time in
the valley). How much critical knowledge and know-how would
be lost?

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[mll]

In article <77t3ld$nou$1@nnrp1.dejanews.com>,
  robert_dewar@my-dejanews.com wrote:
> In article <8p64spq5lo5.fsf@Eng.Sun.COM>,
>   Mike Coffin <mhc@Eng.Sun.COM> wrote:
>
> > When it first appeared, Ada was the
> > laughingstock of programmers everywhere for its insane
> > complexity and C++ has managed to outdo it.
>
> In my experience, people who think Ada is an unacceptably
> complex language are those who simply don't know it and
> prefer to find a reason for rejecting a programming
> language without having to make the effort to learn it.
>

HERE HERE, I've been writing C for 17 years, C++ for 7 and Ada for 7 and
would select Ada over the other 2 anytime (there may be SOME?? applications
which would be better written in C). I've only met one person who said they
didn't prefer Ada over C/C++ and she had only maintained and tested Ada, not
authored anyting in it. The only real obstacle to people learning Ada is the
C- ish attitude of "slap it together, almost anthing will compile and then
I'll debug." Once Ada compiles you rarely deal with anything other than logic
errors.

....snip....
>
> If you really think that you cannot write elegant code
> in Ada, then you may have used it for years, but you never
> learned it. The same is true for C++. You probably just
> have never learned some of the really important elements
> of elegance such as data abstraction, and separation of
> specification and implementations, since they aren't in
> C, they are probably foreign to you. Using Ada and C++
> does not necessarily cure this gap in knowledge, learning
> them properly does!
>
I find it difficult to accept that anyone who can program well could use a
language for years without learning its finer points. Someone who can do this
is just a mechanic.

....snip....
>
> > The programmer is now writing Java for an internet
> > startup and has stock options worth $3.6 million.
> > He has an occasional mild headache but no ulcers.
>
A ludicrous point since many of the characteristics of java are taken directly
from Ada and this person should be having severe headaches over them.

> To think that making money is evidence of competence or
> quality is particularly naive. I guess you think NT must
> be the best operating system in the world *simply because*
> Microsoft is making lots of money -- an interesting theory
> indeed.
>
touche

> Actually suh internet startups are often typical of
> companies that indeed are operating at CMM level 1, and
> have internal software practices that are the envy of none.
>
> Here is an interesting test. For all people in your
> organization, what would happen if they suddenly changed
> jobs and disappeared in 3 days (happens all the time in
> the valley). How much critical knowledge and know-how would
> be lost?
>
> Robert Dewar
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
>

Mike Lockhart
Aspectus anas, actus anas, sonus anas, ex aequo anas.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[mike]

In article <79ce4s$lfq$1@nnrp1.dejanews.com>, mll@xmission.com says...
>
 
 
>
>HERE HERE, I've been writing C for 17 years, C++ for 7 and Ada for 7 and
>would select Ada over the other 2 anytime (there may be SOME?? applications
>which would be better written in C). 

 
C++, with the standard library is as reliable as Ada, with the addition
that it is more terse.

Look at this code below posted here recently by another poster. This code
sorts a list of names inputed from stdin, look how clear, short, 
elegent, and easy to read it is. 

try to do the same in Ada (actually Ada does not even have a standard
generic library that comes with the compiler as C++ does), and you might 
end up with pages of long code that is hard to read. 

I dont think Ada is more read'able. I think wordy languages for me 
are harder to read. too much words makes thing less hard to understand. 

That is why in mathematics people make up short symbols for longer 
expressions and constructs (for example,  the integration sign has 
embedded in it many things, yet people now write the integration 
sign and they know what it means right away).

Ada offcourse is a fine langauage. but I feel C++ is more expressive
and concise. and in the practical world, it is easier to use than Ada.

Even places like NASA now have moved from Ada to C++. I think this is 
a sign of C++ maturity now, and not a sign that Ada is a bad language.

C++ now, after becoming a standard, and with the standard library is a 
very safe language.

#include <iostream>
#include <vector>
#include <string>
#include <algorithm>

int main()
{
        cout << "Please enter a list of words to be sorted: ";

        vector<string> v;
        string buffer;
        while (cin>>buffer && buffer!="END") v.push_back(buffer);
        
        sort(v.begin(),v.end());

        for (vector<string>::iterator i = v.begin(); i!=v.end(); ++i)
                cout << *i << endl;

        return 0;
}

mike

Re: Ada vs C++ vs Java

[John McCabe]

mike <mike@newsguy.com> wrote:


>C++, with the standard library is as reliable as Ada, with the addition
>that it is more terse.

Which "standard" library are you referring to that C++ comes with? Can
you give an ANSI/ISO/IEC reference for it?

Can you give an ANSI/ISO/IEC reference for the definition of the C++
language (not a draft)?

If you can, I'm a bit behind the times, Ada is ISO/IEC 8652:1995. 


Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Ada vs C++ vs Java

[mike]

In article <36b9ed83.851831@news.demon.co.uk>, john@assen.demon.co.uk.nospam
says...
>
>mike <mike@newsguy.com> wrote:
>
>
>>C++, with the standard library is as reliable as Ada, with the addition
>>that it is more terse.
>
>Which "standard" library are you referring to that C++ comes with? Can
>you give an ANSI/ISO/IEC reference for it?
>

Yes.

"News 98-10-01: The C++ standard now fully approved and published as an
 international standard, ISO/IEC 14882:1998 Information
technology - programming language C++. "

see http://anubis.dkuug.dk/JTC1/SC22/WG21


>Can you give an ANSI/ISO/IEC reference for the definition of the C++
>language (not a draft)?
>

Please see above.

I think the actual standard in hardcopy can be bought for nominal fee.


mike

Re: Ada vs C++ vs Java

[John McCabe]

mike <mike@newsguy.com> wrote:

>In article <36b9ed83.851831@news.demon.co.uk>, john@assen.demon.co.uk.nospam
>says...
>>
>>mike <mike@newsguy.com> wrote:
>>
>>
>>>C++, with the standard library is as reliable as Ada, with the addition
>>>that it is more terse.
>>
>>Which "standard" library are you referring to that C++ comes with? Can
>>you give an ANSI/ISO/IEC reference for it?
>>
>
>Yes.
>
>"News 98-10-01: The C++ standard now fully approved and published as an
> international standard, ISO/IEC 14882:1998 Information
>technology - programming language C++. "

Why thank you for that - it has certainly taking its time getting out.


Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Ada vs C++ vs Java

[Hyman Rosen]

John McCabe wrote:
> Which "standard" library are you referring to that C++ comes with? Can
> you give an ANSI/ISO/IEC reference for it?
> 
> Can you give an ANSI/ISO/IEC reference for the definition of the C++
> language (not a draft)?

Both the language and its library are defined by ISO/IEC 14882:1998(E).

Re: Ada vs C++ vs Java

[Stephen Leake]

mike <mike@newsguy.com> writes:

> In article <79ce4s$lfq$1@nnrp1.dejanews.com>, mll@xmission.com says...
> <snip>

> Even places like NASA now have moved from Ada to C++. I think this is 
> a sign of C++ maturity now, and not a sign that Ada is a bad language.

(Speaking as a NASA employee)

NASA is a big place, and almost never speaks with one mind, especially
on an issue like this. We have programmers that prefer Fortran,
assembler, C, C++, and Ada, to name only a few of the languages I've
run into here. I like to think that those of us who prefer Ada are
more productive (I know I am), but I have no real data on this, and
NASA has no overall policy of measuring such things (although we are
starting the process of becoming ISO 9001 compliant, so there's hope).

So please be more careful about making such sweeping statements.

-- Stephen Leake, NASA Goddard Space Flight Center

Re: Ada vs C++ vs Java

[Michael Stark]

Stephen Leake wrote:
> 
> mike <mike@newsguy.com> writes:
> 
> > In article <79ce4s$lfq$1@nnrp1.dejanews.com>, mll@xmission.com says...
> > <snip>
> 
> > Even places like NASA now have moved from Ada to C++. I think this is
> > a sign of C++ maturity now, and not a sign that Ada is a bad language.
> 
> (Speaking as a NASA employee)
> 
> NASA is a big place, and almost never speaks with one mind, especially
> on an issue like this. We have programmers that prefer Fortran,
> assembler, C, C++, and Ada, to name only a few of the languages I've
> run into here. I like to think that those of us who prefer Ada are
> more productive (I know I am), but I have no real data on this, and
> NASA has no overall policy of measuring such things (although we are
> starting the process of becoming ISO 9001 compliant, so there's hope).
> 
> So please be more careful about making such sweeping statements.
> 
> -- Stephen Leake, NASA Goddard Space Flight Center

Stephe is correct that one shouldn't make sweeping generalizations about
NASA (or any other large org, for that matter).  However, it is
unfortunately
correct that the organization that did extensive measurement on Ada
projects
and saw positive results (The Software Engineering Lab at Goddard
measuring
software in the Flight Dynamics Division) did decide to go C++.  More
accurately,
it was one branch head that made the decision.  He consulted the
directors of the
SEL on what they thought the future held, but did not consult with
technical people
advocating Ada (like me) and I presume the same held for the C++
zealots.  I think
he thought that neither group of zealots would add anything new to the
decision making
process.  The drawback was that he had some misconceptions (severe
underestimates) on
how much it would cost to convert existing Ada software to C++.

The proper approach, in the spirit of the SEL's paradigm of
understanding the 
current environment, assessing new technologies, and feeding
improvements back
into the development organization; would have been to run a C++ project
as an
experiment and compare the metrics with the Ada baseline, then to make a
decision.
Instead, the approach was to guess at the future, which at the time did
not have an
inkling of Java coming over the horizon.  I have maintained that if we
had completed
a conversion to C++ it would have finished in time to start the
conversion to Java ;)

Ironically enough, most of the systems in this area are now implemented
in MATLAB,
as requirements have scaled back to fit smaller budgets, and the MATLAB
GUI library
became as good or better than the GUI we were using (a home-grown C
system).  Our
users also liked having the interpretive environment with the extensive
math library
to allow them to play with algorithms more easily.  So I guess all us
language
zealots ultimately got our comeuppance ;)

BTW, the lack of end-user input into how we developed reusable software
is motivating
my selection of dissertation topic.  It will focus on reuse from the
customer
perspective.  since I'm real early in proposal writing, I don't have a
concrete
plan yet.  

Mike 

-- 
Michael Stark
Goddard Research & Study Fellow
University of Maryland, College Park
e-mail: mstark@cs.umd.edu
phone: (301) 405-2721
"Injustice anywhere is a threat to justice everywhere" --
Martin Luther King, Letter From Birmingham City Jail

Re: Ada vs C++ vs Java

[Stanley Friesen [Contractor]]

In article <36BC74B9.5A8@cs.umd.edu>, Michael Stark  <mstark@cs.umd.edu> wrote:
>Stephen Leake wrote:
>SEL on what they thought the future held, but did not consult with
>technical people
>advocating Ada (like me) and I presume the same held for the C++
>zealots.  I think
>he thought that neither group of zealots would add anything new to the
>decision making
>process.  The drawback was that he had some misconceptions (severe
>underestimates) on
>how much it would cost to convert existing Ada software to C++.
>
Eh!?!?  Convert existing software???

I would hope even most "C++ zealots" would admit how expensive this
is likely to be.  I know enough of both languages to know how much
trouble this is likely to cause.

Re: Ada vs C++ vs Java

[Michael Stark]

Stanley Friesen [Contractor] wrote:
> 
> In article <36BC74B9.5A8@cs.umd.edu>, Michael Stark  <mstark@cs.umd.edu> wrote:
> >Stephen Leake wrote:
> >SEL on what they thought the future held, but did not consult with
> >technical people
> >advocating Ada (like me) and I presume the same held for the C++
> >zealots.  I think
> >he thought that neither group of zealots would add anything new to the
> >decision making
> >process.  The drawback was that he had some misconceptions (severe
> >underestimates) on
> >how much it would cost to convert existing Ada software to C++.
> >
> Eh!?!?  Convert existing software???

Yes indeed!  Our manager, for reasons only he knows, wanted to have
everyone using a single language.  This is what is called a "business
decision"
> 
> I would hope even most "C++ zealots" would admit how expensive this
> is likely to be.  I know enough of both languages to know how much
> trouble this is likely to cause.

The catch is that for our Ada code we had a code generator that created
about 80% of the lines of code.  The basic error was assuming that this
would get rid of 80% of the cost, but since code writing is only 15 to
20 per cent of the effort at best, the savings was much lower.  To be
fair we did have reuse of design and test cases, so there would be
some savings beyond code, but nothing like 80%.  Unfortunately, I
discovered this misconception well after the decision was made.

As you might have guessed, the conversion of existing code never
happened for lack of resources, so the C++ edict only applied to new
code, and was later overtaken by (Java) events.

Mike

-- 
Michael Stark
Goddard Research & Study Fellow
University of Maryland, College Park
e-mail: mstark@cs.umd.edu
phone: (301) 405-2721
"Injustice anywhere is a threat to justice everywhere" --
Martin Luther King, Letter From Birmingham City Jail

Re: Ada vs C++ vs Java

[Richard D Riehle]

In article <79chc7$ko6@drn.newsguy.com>,
	mike <mike@newsguy.com> wrote:
 
>Look at this code below posted here recently by another poster. This code
>sorts a list of names inputed from stdin, look how clear, short, 
>elegent, and easy to read it is. 

 [snipped away the fragment of terse, concise, and error-prone C++ code]

 Unfortunately, one cannot make such large conclusions from such tiny
 source code fragments.  I could easily post some C++ code that would
 be difficult to understand with corresponding Ada code that would be
 emminently readable and vice-versa.  

 If you are trying to compare two languages, you must set out the
 criteria for the comparison, based on your specific needs, examine
 each language in terms of those criteria, and then decide which one
 best satisfies the criteria.  The broadly framed pronouncements that
 X is better than Y usually originate in some biases that have little
 to do with either X or Y.  

 As nearly as I can tell, no one has completed an objective study
 of this kind that can be agreed upon by advocates of their own
 preferred language.  An excellent treatment by Dr. Patricia Lawlis, 
 in her sincere effort to be intellectually honest, is probably the 
 closest right now.  Even that effort is criticized by the C++ camp, the 
 Eiffel camp, etc.  

 "He convinced against his will is of the same opinion still."   

 No amount of evangelism is going to have any benefit.  Ada is only
 going to survive if it be used effectively on real projects with high  
 visibility.  That means we, the Ada advocates, must use it for a wide 
 range of projects, write about our successes, show off our results at 
 conferences (not Ada conferences), and demonstrate how easy it is to be  
 successful with it.  This means, build products that real people use;   
 products that arrive on the shelf in shrink-wrap; products that the      
 consumer selects because they are superior, not because they are 
 written in language  X or language Y.

 There is the ancient story of the IBM salesman on his wedding night 
 which I will not repeat here. Those of you who have been in the 
 industry for a while will recall it. We have a tool, Ada, that can be 
 used to build superior products. Let's start using it instead of 
 prancing about telling everyone how good it's going to be.   

 Richard Riehle
 richard@adaworks.com
 http://www.adaworks.com

Re: Ada vs C++ vs Java

[Tucker Taft]

mike wrote:
> ...
> C++ now, after becoming a standard, and with the standard library is a
> very safe language.

It is correct to say that you can now write safe programs
in C++.  But C++ is not a safe language, in that many of the
basic "building blocks" of the language are not safe.  In fact,
because the "defaults" were mostly inherited from C, the "default"
building blocks are almost all unsafe.  For example:

By default in C++ (and C):

   arrays -- no bounds checking
   pointers -- not default initialized, no checking for null when
     dereferenced
   arithmetic -- no overflow checking
   cast -- no checking for inappropriate "narrowing" casts
   "class" parameters -- passed by copy; "chopped" off (run-time
      type identity lost)
   address-of ("&") operation -- no protection from dangling references

In a "safe" language, the defaults (at least) are safe.
There may be escape hatches for certain low-level programming
situations.  

On the other hand, in C/C++, the defaults are generally
unsafe, though "safe" abstractions exist.  This means
that programmers can program safely (if they are diligent).
However, when faced with a large body of C/C++, it is generally
infeasible to systematically find all the places where an unsafe
operation might be used.
  
In a safe language, a small mistake does not result in loss
of safety.  Only going out of your way to use an unsafe
escape hatch (if they exist at all) can result in loss of safety.
Even in a large program, it is straightforward to find all uses of
escape hatches.  

One might say that the degree of safety inherent in a
language is directly related to the ease of
locating all uses of potentially unsafe features.
In C and C++, this is notoriously difficult.

> mike

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Ada vs C++ vs Java

[Fredric L. Rice]

Tucker Taft wrote:

>    arrays -- no bounds checking

That's easily enough fixed with operator overloading, of course, yet
I have to agree totally on this particular attribute of arrays with C++.
The origin 0 of C++ has plagued old code that I've had to debug and
fix over the years and, because C is an origin 0 language, I have found
a lot of code that merely oversteps its array bounds by one.

To alleviate the problem, believe it or not, I usually always have a habit
of allocating one more than I need for an array.  Additionally, when I'm
working on isolating a curious bug, I always suspect arrays allocated on
a function's stack first.  Traditionally, even more than wild pointers,
that's been the most numerous problem I've seen when debugging old
code.

Re: Ada vs C++ vs Java

[robert_dewar]

In article <79chc7$ko6@drn.newsguy.com>,
  mike <mike@newsguy.com> wrote:
> Look at this code below posted here recently by another
> poster. This code sorts a list of names inputed from
> stdin, look how clear, short, elegent, and easy to read
> it is.

<silly example using a library sort routine>>

That truly is the silliest example we have had in an
otherwise informative thread.

I can only say that if you think this argument is valid,
then you will love APL, where the same sorting routine can
be done in 4 or 5 characters (you do not have to put up
with wordy things like "sort" in APL, since sorting can be
done with a single character!).

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Ole-Hjalmar Kristensen]

robert_dewar@my-dejanews.com writes:

> In article <79chc7$ko6@drn.newsguy.com>,
>   mike <mike@newsguy.com> wrote:
> > Look at this code below posted here recently by another
> > poster. This code sorts a list of names inputed from
> > stdin, look how clear, short, elegent, and easy to read
> > it is.
> 
> <silly example using a library sort routine>>
> 
> That truly is the silliest example we have had in an
> otherwise informative thread.
> 
> I can only say that if you think this argument is valid,
> then you will love APL, where the same sorting routine can
> be done in 4 or 5 characters (you do not have to put up
> with wordy things like "sort" in APL, since sorting can be
> done with a single character!).
> 
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

But the point you seem to be missing is that this libarry now is a
*standard* part of C++.

Comments?

-- 
E pluribus Unix

Re: Ada vs C++ vs Java

[robert_dewar]

In article <umqbtj9m636.fsf@maestro.clustra.com>,
  Ole-Hjalmar Kristensen <ohk@maestro.clustra.com> wrote:
> But the point you seem to be missing is that this libarry
> now is a *standard* part of C++.


Yes, and the sort operator is a part of the standard
language in the case of APL.

So if C++ is better than Ada because the standard library
has a sort built in, and therefore allows a shorter sorting
routine, by the same argument APL must be even better than
C++, since the sorting is even more built in, and we can
get an even shorter sorting routine.


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[mike]

In article <79fm3e$ffs$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com
says...
>
>In article <umqbtj9m636.fsf@maestro.clustra.com>,
>  Ole-Hjalmar Kristensen <ohk@maestro.clustra.com> wrote:
>> But the point you seem to be missing is that this libarry
>> now is a *standard* part of C++.
>
>

>Yes, and the sort operator is a part of the standard
>language in the case of APL.
>
>So if C++ is better than Ada because the standard library
>has a sort built in, and therefore allows a shorter sorting
>routine, by the same argument APL must be even better than
>C++, since the sorting is even more built in, and we can
>get an even shorter sorting routine.
>

 
I think this could be solved by having a standard Ada library be
part of the "language" in the same sense that C++ standard library
is part of "C++" .

May be in Ada 200X this could be done. Without this, Ada will have
even a harder time making it. Being a good language, without a standard
library of usefull routine and data structures readily available to all
programmers is not enough to be a successfull commerical langauge these 
days.

It is the resposibility of Ada compiler companies and the Ada experts
to get togother and come up with such a library. Who else will do it?
Without this, Ada will not survive. 

Untill Ada gets its act togother, more and more programmers will be using 
C and C++ and Java and VB.

mike

Re: Ada vs C++ vs Java

[Ole-Hjalmar Kristensen]

mike <mike@newsguy.com> writes:

> In article <79fm3e$ffs$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com
> says...
> >
> >In article <umqbtj9m636.fsf@maestro.clustra.com>,
> >  Ole-Hjalmar Kristensen <ohk@maestro.clustra.com> wrote:
> >> But the point you seem to be missing is that this libarry
> >> now is a *standard* part of C++.
> >
> >
> 
> >Yes, and the sort operator is a part of the standard
> >language in the case of APL.
> >
> >So if C++ is better than Ada because the standard library
> >has a sort built in, and therefore allows a shorter sorting
> >routine, by the same argument APL must be even better than
> >C++, since the sorting is even more built in, and we can
> >get an even shorter sorting routine.
> >
> 
>  
> I think this could be solved by having a standard Ada library be
> part of the "language" in the same sense that C++ standard library
> is part of "C++" .
> 
> May be in Ada 200X this could be done. Without this, Ada will have
> even a harder time making it. Being a good language, without a standard
> library of usefull routine and data structures readily available to all
> programmers is not enough to be a successfull commerical langauge these 
> days.
> 
> It is the resposibility of Ada compiler companies and the Ada experts
> to get togother and come up with such a library. Who else will do it?
> Without this, Ada will not survive. 
> 
> Untill Ada gets its act togother, more and more programmers will be using 
> C and C++ and Java and VB.
> 
> mike

I agree. Someone once said that "library design is language design",
and he was very right.

-- 
E pluribus Unix

Re: Ada vs C++ vs Java

[robert_dewar]

In article <79fnce$iv8@drn.newsguy.com>,
  mike <mike@newsguy.com> wrote:
> I think this could be solved by having a standard Ada
> library be part of the "language" in the same sense that
> C++ standard library is part of "C++" .

Well of course Ada 95 *does* have a standard library, see
annex A of the RM.

Now it is true that it is less extensive than the C++
standard library, but there is no obvious principle that
more is more here. In fact Annex A represents exactly what
the designers of Ada felt was appropriate to standardize.

For example, should a sort routine be standardized?
Probably not, there are so many different algorithms, and
different algorithms are appropriate for different
purposes, and this very much seems to me to be the sort
of thing that is better handled by external libraries
(which could of course be standardized if that seemed
desirable).

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[mike]

In article <79grbs$d5u$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com
says...
>
 
>
>Now it is true that it is less extensive than the C++
>standard library, but there is no obvious principle that
>more is more here. In fact Annex A represents exactly what
>the designers of Ada felt was appropriate to standardize.
>
>For example, should a sort routine be standardized?
>Probably not, there are so many different algorithms, and
>different algorithms are appropriate for different
>purposes, 

But a standard sort package would only specify the interface, and
would leave the implementation up to the vendor. isn;t this how
things are supposed to be? Maybe even supply a standard interface to
a small number of class of sort API's if that is needed. (this is not
different from the unix 'sort' command for example).

>and this very much seems to me to be the sort
>of thing that is better handled by external libraries
>(which could of course be standardized if that seemed
>desirable).

As long as the "library" comes with the "system", and is standard
(meaning application build on it on one platform, will compile and 
run with no changes on a different platform, and one does not need to
worry if this library will be available or not on the other platform), 
it should not matter if you want to call the library "external" or part 
of the language. 

The point is, Ada has a very small standard library now, that is almost
of no use to write advanced programs that requires advanced data
structures and algorithms. Compares this to C++ and Java, they both
"come" with standard advanced libraries out of the box. Java have so
many API's defined (many with no implementation yet!), that it is even 
hard to find what is it that Java does not have an API for.
  
(Also Perl have lots of standard libraries for doing all sorts of things).

mike

Re: Ada vs C++ vs Java

[dennison]

In article <79hujb$ck3@drn.newsguy.com>,
  mike <mike@newsguy.com> wrote:
> In article <79grbs$d5u$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com
> says...
> >
> >For example, should a sort routine be standardized?
> >Probably not, there are so many different algorithms, and
> >different algorithms are appropriate for different
> >purposes,
>
> But a standard sort package would only specify the interface, and
> would leave the implementation up to the vendor. isn;t this how
> things are supposed to be? Maybe even supply a standard interface to
> a small number of class of sort API's if that is needed. (this is not
> different from the unix 'sort' command for example).

No. The choice of sort algorithm I want to use is highly dependent on my
problem space. Some algorithms are better on nearly sorted data, some are
better on completely scrambled data. Some are great for huge amounts of input
items, but are not so hot for small amounts of input items. There exists one
algorithm that is superior to all others when the items to be sorted are all
integers. Then there's the static vs. dynamic (array vs. pointers) issue...

I don't see how a compiler vender is going to have any better clue which one I
need than a language standard writer would. The only person really capable of
making the decision is the developer in question.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Al Christians]

dennison@telepath.com wrote:
> 
> 
> No. The choice of sort algorithm I want to use is highly dependent on my
> problem space. Some algorithms are better on nearly sorted data, some are
> better on completely scrambled data. Some are great for huge amounts of input
> items, but are not so hot for small amounts of input items. 
> There exists one
> algorithm that is superior to all others when the items to be sorted are all
> integers. Then there's the static vs. dynamic (array vs. pointers) issue...
> 
> I don't see how a compiler vender is going to have any better clue which one I 
> need than a language standard writer would. The only person really capable of
> making the decision is the developer in question.
> 

But there are so  many common cases where any reasonable algorithm is
perfectly ok, ie when you've got a modern computer and a second or
two to sort some number of items less than 100,000 or so.  It doesn't
matter worth 2 cents which one gets used 99% of the time.  Except for
the rare application that has to do an extremely large number of sorts
in a brief interval, the 'not so hot for small amounts of input items' 
criticism is irrelevant, because it means not so hot in relation to a 
totally negligible cost of sorting a small amount of data.

Your logic, if correct, would also apply to many of the algorithms in 
the standard libraries, for example Ada.Strings.Fixed.Index.  We've 
got a choice of algorithms there,   Knuth-Morris-Pratt, Karp-Rabin, 
Quick Search, Boyer-Moore, etc. None is best in all cases. I don't 
know which one the library uses, and I don't care.  Whatever one it 
uses works well enough, and, I doubt that any of the others would be 
enough better in any of my applications that anyone would notice any 
difference at all. When I have an application in which it matters, 
I'll find out and write my own if I need to. But that's not something 
that everyone wants to worry about, ever. 

Some week or two ago, in the discussion of Modula-2 that somehow spilled
into comp.lang.ada, a comment was repeated about the ISO library spec
for 
M2 being bad enough to demise the language.  If a bad library spec can
kill 
a language, maybe a good one could help one at least a little.

Al

Re: Ada vs C++ vs Java

[William Clodius]

Al Christians wrote:
> <snip>
> Some week or two ago, in the discussion of Modula-2 that somehow spilled
> into comp.lang.ada, a comment was repeated about the ISO library spec
> for
> M2 being bad enough to demise the language.  If a bad library spec can
> kill
> a language, maybe a good one could help one at least a little.
> <snip>

I suspect you are paraphrasing me paraphrasing someone else, and not
doing a good job of it. You seem to be combining two comments, that the
library spec had a number of problems, and that the ISO standard
document was bad enough to kill the language. There were many more
problems with the document than just the library spec. The language of
course is still alive, though not well in terms of growth of useage. For
what its worth, some people felt that a smaller and simpler spec for the
library would have been better. Just taking on more procedures without
good thought is not a solution.

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: Ada vs C++ vs Java

[Fredric L. Rice]

mike wrote:

>For example, should a sort routine be standardized?
>Probably not, there are so many different algorithms, and
>different algorithms are appropriate for different
>purposes,

> But a standard sort package would only specify the interface, and
> would leave the implementation up to the vendor. isn;t this how
> things are supposed to be?

That's how it's done in the C++ world.  qsort() is the function that is
normally called when a sort is desired and one must provide the guts
of the function.

Also, it's done in embedded C++ compilers with open(), read(), write(),
and even fprintf().  The compiler vender creates those functions (which
are linked as _open() _read() _write() et al.) and those in turn call a
function that the engineer is supposed to supply (__open() __read()
__write() et al. or some times _xopen() _xread() _xwrite() -- the vender
will have a chapter covering elements of the embedded compiler which
must be supplied by the software engineer.

Re: Ada vs C++ vs Java

[Matt Austern]

"Fredric L. Rice" <frice@linkline.com> writes:

> > But a standard sort package would only specify the interface, and
> > would leave the implementation up to the vendor. isn;t this how
> > things are supposed to be?
> 
> That's how it's done in the C++ world.  qsort() is the function that is
> normally called when a sort is desired and one must provide the guts
> of the function.

Well, more precisely qsort() is the sorting function that's normally
called in the C world.  In the C++ world, the usual sorting function
is sort(). Although qsort() isn't officially deprecated in C++ (the
C++ standard library includes the C standard library), it might as
well be.  

I can't think of any occasion where it would be better to use qsort()
than sort().  The generic sort() algorithm is easier to use, more
flexible, safer, and more efficient.

Re: Ada vs C++ vs Java

[Marin David Condic]

robert_dewar@my-dejanews.com wrote:
> For example, should a sort routine be standardized?
> Probably not, there are so many different algorithms, and
> different algorithms are appropriate for different
> purposes, and this very much seems to me to be the sort
> of thing that is better handled by external libraries
> (which could of course be standardized if that seemed
> desirable).
> 
What would be wrong with specifying a couple of "standard" generic sort
routines that provided some of the most common algorithms? There are
only so many versions of a Quicksort or Heapsort that anyone needs and
having a "standard" version would a) eliminate duplication of effort and
b) establish a "model" interface for any other sorting algorithms.

As you are fond of observing about coding standards, it is not so
important that we pick any one specific standard as it is that we all
agree on one and stick to it. I was not particularly fond of the Strings
packages in Ada95 as described in the annex, but I had to agree that I
could accomplish all of the same things with these packages as I could
with my own home grown ones. (mostly the "Not Invented Here" syndrome
:-) Now they are part of the every day programming experience and I
would like to think my code is a bit easier to deal with by other
programmers because I use a "standard" library with clearly defined
behavior rather than a home grown version.

So if there was a series of annexes which described package interfaces
for libraries of basic data structure manipulations, it would probably
be a good thing. If the annexes were optional for compiler writers -
with the stipulation that if not supplied that nothing about the
compiler should inhibit their inclusion by a third party supplier or the
end user - I think this would help to encourage more use of Ada. If
there were a separate tree for these utilities and the tree could be
extended by end users, it would encourage evolutionary development that
would expand the language. Start with something called
Utilities.Sorts.Quicksort and Utilities.Sorts.Heapsort and let the end
users add algorithms as desired. Utilities.Sorts.Bubblesort?
Utilities.Sorts.Slowsort? ;-)

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

"Government is not reason. It is not eloquence. It is a force. 
Like fire, a dangerous servant and a fearful master."

    --  George Washington

Re: Ada vs C++ vs Java

[Fredric L. Rice]

robert_dewar@my-dejanews.com wrote:

> For example, should a sort routine be standardized?
> Probably not, there are so many different algorithms, and
> different algorithms are appropriate for different
> purposes, and this very much seems to me to be the sort
> of thing that is better handled by external libraries
> (which could of course be standardized if that seemed
> desirable).

In the C and C++ world, sorts _are_ indeed standardized in some ways.
There is a standard library function called qsort() which takes as an
argument
a pointer to the "payload" function which performs the actual compares of
the
data elements being considered in the sort.

In the APL world, monadic or diadic elements are extracted from the array
or matrix using an index but the sort symbol is standard.

Knowing squat about Ada at this point, isn't there something like that in
Ada?

Re: Ada vs C++ vs Java

[Marin David Condic]

Fredric L. Rice wrote:
> 
> In the C and C++ world, sorts _are_ indeed standardized in some ways.
> There is a standard library function called qsort() which takes as an
> argument
> a pointer to the "payload" function which performs the actual compares of
> the
> data elements being considered in the sort.
> 
> In the APL world, monadic or diadic elements are extracted from the array
> or matrix using an index but the sort symbol is standard.
> 
> Knowing squat about Ada at this point, isn't there something like that in
> Ada?

There are no standard sort libraries in Ada yet. (Day ain't over, yet!)
The provision to do something similar to what you describe has been in
Ada since the beginning. Using generic parameters to build a generic
sort procedure, you can import the data type of elements to be sorted,
the array type that holds the elements and comparison functions for
determining order. It would look something like this:

generic
    type Item is private ;
    type Vector_Type is array (Integer range <>) of Item ;
    with function "<" (
        Left    : in     Item ;
        Right   : in     Item) return Boolean ;
procedure Quick_Sort (
    Vector  : in out Vector_Type) ;
--  The rest is left as an exercise for the student...

So the capacity to make really nice, easy to use generic libraries full
of tools was always available. Initially (back in 83) it was believed
that there would be an emerging tool building business, so the standard
didn't want to overspecify things and possibly shut out new ideas. The
tool business never emerged in any major way, so no "industry standard"
libraries of stuff emerged. By the time we got to Ada95, it was realized
that in at least a few areas, there ought to be a "standard interface"
specified for some packages of utilities - mostly in the area of math
functions and strings. That was nice, but IMHO not enough. There could,
and should, be some "standard" package specifications for various tools
so that even if the compiler vendors don't supply it, the tools can be
had from some source and everybody agrees on what they should do and how
they should be called. This sort of library is in the works. See:
http://www.suffix.com/Ada/SCL/ for more info.

Note that for many things you would not call "general purpose tools" -
such as bindings to OS libraries, specialized language processing
subsystems (ASIS) and similar creatures, there are a wealth of packages
available. Its just that not all of them are compiler-vendor-supplied
and you may need to fish around a little to get them.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

"Government is not reason. It is not eloquence. It is a force. 
Like fire, a dangerous servant and a fearful master."

    --  George Washington

Re: Ada vs C++ vs Java

[Fredric L. Rice]

mike wrote:

> In article <79fm3e$ffs$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com
> says...
> >
> >In article <umqbtj9m636.fsf@maestro.clustra.com>,
> >  Ole-Hjalmar Kristensen <ohk@maestro.clustra.com> wrote:
> >> But the point you seem to be missing is that this libarry
> >> now is a *standard* part of C++.>
>
> >Yes, and the sort operator is a part of the standard
> >language in the case of APL.
> >
> >So if C++ is better than Ada because the standard library
> >has a sort built in, and therefore allows a shorter sorting
> >routine, by the same argument APL must be even better than
> >C++, since the sorting is even more built in, and we can
> >get an even shorter sorting routine.
>
> It is the resposibility of Ada compiler companies and the Ada experts
> to get togother and come up with such a library. Who else will do it?
> Without this, Ada will not survive.

Do what C hackers did a decade ago:  Produce good libraries and post
them to the public domain.  Eventually a number of some of the more useful
library packages will be adopted by compiler manufacturers -- only done
up better (taking less resources) since same companies have acess to
engineering budgets.

I know squat about Ada, I must admit, but for the C world, this was done
to a heavy extent and public domain editors and compilers helped to make
C very popular.  Remember when Small C came out?  I used it to program
the old Ohio Scientific Challenger III 6502/Z80/6552 computers.  A large
number of hackers used PD C libraries and compilers, grew up into the
corporate world, and advocated C until it's acquired the popularity that it
has today.

I haven't seen that degree of religious behavior taken with Ada.

Re: Ada vs C++ vs Java

[Robert I. Eachus]

In article <36BF8648.EEBCACEF@linkline.com> "Fredric L. Rice" <frice@linkline.com> writes:

 > Do what C hackers did a decade ago:  Produce good libraries and post
 > them to the public domain.  Eventually a number of some of the more useful
 > library packages will be adopted by compiler manufacturers -- only done
 > up better (taking less resources) since same companies have acess to
 > engineering budgets.

   The Ada attitude is slightly different, but the long term result is
the same.  I wrote some packages which eventually became part of the
Ada standard (in particular the formatted output in Annex F and some
things in Annex A).  Others worked for years as members of the NUMWG
and NRG to provide standard packages for elementary complex functions
that are now part of the standard and so on.  I suspect that a
container library, a statistics library, and a windowing library will
be the next major additions.  (In fact I think it is about time to
create those working groups...)
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada vs C++ vs Java

[Ole-Hjalmar Kristensen]

robert_dewar@my-dejanews.com writes:

> In article <umqbtj9m636.fsf@maestro.clustra.com>,
>   Ole-Hjalmar Kristensen <ohk@maestro.clustra.com> wrote:
> > But the point you seem to be missing is that this libarry
> > now is a *standard* part of C++.
> 
> 
> Yes, and the sort operator is a part of the standard
> language in the case of APL.
> 
> So if C++ is better than Ada because the standard library
> has a sort built in, and therefore allows a shorter sorting
> routine, by the same argument APL must be even better than
> C++, since the sorting is even more built in, and we can
> get an even shorter sorting routine.
> 
> 
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Yes. And from this I infer that you think that any standardization of
libraries, or even built-in functions are a waste of time?
No, the point is that C++ has recently take a major step forward with
the acceptance of a standard library which is rather comprehensive and
has a sound foundation. Arguing that this is not needed in Ada is not
going to convince anyone to use Ada.

-- 
E pluribus Unix

Re: Ada vs C++ vs Java

[Robert I. Eachus]

In article <umq679g45y3.fsf@maestro.clustra.com> Ole-Hjalmar Kristensen <ohk@maestro.clustra.com> writes:

 > Yes. And from this I infer that you think that any standardization of
 > libraries, or even built-in functions are a waste of time?

    I don't remember Robert Dewar objecting to any of the package
heavy annexes during the standardization of Ada 95, so I think you are
misunderstanding what he is saying...

 > No, the point is that C++ has recently take a major step forward with
 > the acceptance of a standard library which is rather comprehensive and
 > has a sound foundation. Arguing that this is not needed in Ada is not
 > going to convince anyone to use Ada.

    Let me turn your argument around, and go back almost ten years, to
the start of the Ada 9X effort.  I think it was pretty well accepted
at that time that some packages should be standardized separate from
the Ada language, and that some belonged in the standard.  The
standard math library for Ada 83 was a separate library, and at that
time adding it to the Reference Manual was a subject of discussion.
The final outcome not only included the elementary functions in the
required libraries, but added complex elementary functions to the
specialized annexes.

    I think that this is definitely the way to proceed with a set of
class libraries for Ada.  We are getting to the point where it will
make sense to create several standard class libraries, starting with a
container library.

   Now a word about the c++ code example that started this discussion.
I've written similar programs in Ada of similar size, mostly to test
sort packages.  So why hasn't anyone posted such an example to the
list?

   I'll tell you why I haven't.  There are no specified requirements
provided, and trying to write a specification for which that code is
in some sense the "right" solution turns out to be almost impossible.
If I was to solve the apparent problem, I'd use Ada.Strings.Unbounded
and an AVL tree package.  Read the input into the tree, then read it
out inorder.  I have several container libraries to choose from, and
the actual program amounts to instantiating the tree type for
unbounded strings, then two three line loops, one to read the input,
and one to write it out again.  So it is easy enough to WRITE in Ada,
and easy to read and understand as well.  It is just that there are a
number of questions I'd send back to the requestor before handing over
the code:

     Are there any concurrency requirements?  In particular, what are
the requirements, if any, for reading from a pipe or a terminal?

     Is the input format limited such that Ada.Strings.Bounded may be
used for better efficiency?

     What are valid characters in the input, and what characters have
special treatment requirements.  (In particular for C++ compatibility,
do I have to treat NUL specially?)

     Is the input small enough that I can sort in memory on the
intended target?  If not, can I keep the index/tree in memory while
writing the data to disk?
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada vs C++ vs Java

[mike]

In article <EACHUS.99Feb8141309@spectre.mitre.org>, eachus@spectre.mitre.org
says...
 
>   Now a word about the c++ code example that started this discussion.
>I've written similar programs in Ada of similar size, mostly to test
>sort packages.  So why hasn't anyone posted such an example to the
>list?
>
>   I'll tell you why I haven't.  There are no specified requirements
>provided, 

snip..

>     Are there any concurrency requirements?  In particular, what are
>the requirements, if any, for reading from a pipe or a terminal?
>

Well. the C++ example was reading from stdin, and it had no tasking?

>     Is the input format limited such that Ada.Strings.Bounded may be
>used for better efficiency?
>

The C++ example used the string standard class. so it is obvious that it will
map to Ada unbounded string?

>     What are valid characters in the input, and what characters have
>special treatment requirements.  (In particular for C++ compatibility,
>do I have to treat NUL specially?)
>


>     Is the input small enough that I can sort in memory on the
>intended target?  If not, can I keep the index/tree in memory while
>writing the data to disk?
>--
 

But these questions are up to you to figure out.

The whole point, is that your Ada program must "behave" the same way as the
C++ program. any input I give to the C++ program, should work with Ada,
as in a black box thing. Offcourse you must use generic data structures like
the C++ program ;)

And if you are going to post code that does the same as those 8 lines of 
C++ did, you need to show all the code used, UNLESS the code is part of the
Ada standard library.

You say you have your own AVL tree that you can instantiate it to 
unbounded string, and since this is not part of Ada standard library, 
then you will have to post the code for that as well :)

I am sure when you are done, you'll have more than 8 lines of Ada code !

and thanks in advanced for your code.

Mike

Re: Ada vs C++ vs Java

[Larry Kilgallen]

In article <79nhe1$3n5@drn.newsguy.com>, mike <mike@newsguy.com> writes:
> In article <EACHUS.99Feb8141309@spectre.mitre.org>, eachus@spectre.mitre.org
> says...
>  
>>   Now a word about the c++ code example that started this discussion.
>>I've written similar programs in Ada of similar size, mostly to test
>>sort packages.  So why hasn't anyone posted such an example to the
>>list?
>>
>>   I'll tell you why I haven't.  There are no specified requirements
>>provided, 
> 
> snip..
> 
>>     Are there any concurrency requirements?  In particular, what are
>>the requirements, if any, for reading from a pipe or a terminal?
>>
> 
> Well. the C++ example was reading from stdin, and it had no tasking?

Presumably the job is to write software to meet the requirements,
rather than to write software that mimics the limitations of some
other implementation.

>>     Is the input format limited such that Ada.Strings.Bounded may be
>>used for better efficiency?
>>
> 
> The C++ example used the string standard class. so it is obvious that it will
> map to Ada unbounded string?

But is that the requirement, or just the way the programmer happened
to write it?

>>     What are valid characters in the input, and what characters have
>>special treatment requirements.  (In particular for C++ compatibility,
>>do I have to treat NUL specially?)
>>
> 
> 
>>     Is the input small enough that I can sort in memory on the
>>intended target?  If not, can I keep the index/tree in memory while
>>writing the data to disk?
>>--
>  
> 
> But these questions are up to you to figure out.
> 
> The whole point, is that your Ada program must "behave" the same way as the
> C++ program. any input I give to the C++ program, should work with Ada,
> as in a black box thing. Offcourse you must use generic data structures like
> the C++ program ;)
> 
> And if you are going to post code that does the same as those 8 lines of 
> C++ did, you need to show all the code used, UNLESS the code is part of the
> Ada standard library.

Writing Ada code to mimic C++ seems as awful as writing C++ code to
mimic Ada.  It is just not a meaningful exercise.

Larry Kilgallen

Re: Ada vs C++ vs Java

[Geoff Bull]

mike wrote:
> 
> 
> And if you are going to post code that does the same as those 8 lines of
> C++ did, you need to show all the code used, UNLESS the code is part of the
> Ada standard library.
> 
> You say you have your own AVL tree that you can instantiate it to
> unbounded string, and since this is not part of Ada standard library,
> then you will have to post the code for that as well :)
> 
Nice test, you put the best feature of C++ 
(a standard container library) against Ada with constraints
imposed to make sure you win.
Why wouldn't it be reasonable to allow any pakage available on the
PAL (Public Ada Library) to be used - there's a hell of a lot more
there than in the C++ standard. Since Ada95 booch components
and ACL are freely available, they should be allowed too.

How about a short multi-threaded program, and you are not
allowed to use anything that is not in the language standard?

A million line program, or least a few thousand lines,
 would be much better indication of a languages capabilities.
Then what would you use to measure the winner?
a) number of lines of code?
b) defect rates?
c) number of catastrophic failures?
d) overall project cost including on going maintenance costs?
e) profits made and customer satisfaction?

The obvious choice is (e), and to get it you need (b .. d) and
(a) is not an issue.


Anybody tried mike's test in Java?

Geoff

Re: Ada vs C++ vs Java

[atomly]

In article <36C003DF.3799DC70@acenet.com.au>,
  Geoff Bull <gbull@acenet.com.au> wrote:

> Anybody tried mike's test in Java?

I wasn't here for the original post.  If anybody could re-post it or give me a
refernce to the article I'd be more than happy to try my hand at it in Java.

By the way, just wanted to note that I never said I know nothing about Ada, I
said I had no *real* experience with Ada. Translation: I've never coded
anything significant in Ada as I'd prefer to use a language that has a
compiler for every platform I use.

(Note to religious Ada people: please don't ask me to list my platforms and
then provide me with a list of links to compilers for each platform that has
one. I'll be more than happy to look around on my own, thank you.)

--
atomly@my-dejanews.com (atomly at mindless dot com)
http://pimplimp.hypermart.net
http://members.tripod.com/~atomly

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Larry Kilgallen]

In article <79q5ak$qof$1@nnrp1.dejanews.com>, atomly@my-dejanews.com writes:

> said I had no *real* experience with Ada. Translation: I've never coded
> anything significant in Ada as I'd prefer to use a language that has a
> compiler for every platform I use.

One of the shortcomings I see with availability of Java is that people
are so busy building bytecode tools that they are skipping entirely
the compilation of Java into native machine language. One of my
favorite platform vendors is not skipping it, but another favorite
of mine didn't understand the issue, so that indicates where they stand.

I was happy to hear Sun's Chief Science Officer at the RSA Conference
indicate that to his way of thinking the WWW graphics use of Java was
a distraction from the strength that he saw in Java as a general language
(as compared to C*).

Larry Kilgallen
Ada fan

Re: Ada vs C++ vs Java

[robert_dewar]

In article <EACHUS.99Feb8141309@spectre.mitre.org>,
  eachus@spectre.mitre.org (Robert I. Eachus) wrote:
> In article <umq679g45y3.fsf@maestro.clustra.com>
> Ole-Hjalmar Kristensen <ohk@maestro.clustra.com> writes:
>
>  > Yes. And from this I infer that you think that any
>  > standardization of
>  > libraries, or even built-in functions are a waste of
>  > time?

Your inference engine is broken, I never even vaguely
said or think any such thing!

>     I don't remember Robert Dewar objecting to any of the
>     package heavy annexes during the standardization of
>     Ada 95, so I think you are
>     misunderstanding what he is saying...

The reason for lack of memory here is that of course RBKD
did not object, he thought the level of complexity of the
standard packages in the annexes was about right (and
thinks it is a shame that C++ lacks many of these important
standard library functions, particularly in the concurrency
and other-language interface area!!!)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Ole-Hjalmar Kristensen]

robert_dewar@my-dejanews.com writes:

> In article <EACHUS.99Feb8141309@spectre.mitre.org>,
>   eachus@spectre.mitre.org (Robert I. Eachus) wrote:
> > In article <umq679g45y3.fsf@maestro.clustra.com>
> > Ole-Hjalmar Kristensen <ohk@maestro.clustra.com> writes:
> >
> >  > Yes. And from this I infer that you think that any
> >  > standardization of
> >  > libraries, or even built-in functions are a waste of
> >  > time?
> 
> Your inference engine is broken, I never even vaguely
> said or think any such thing!
> 

Well, the exchange which led to my comment was this:

<start of quote>

In article <umqbtj9m636.fsf@maestro.clustra.com>,
  Ole-Hjalmar Kristensen <ohk@maestro.clustra.com> wrote:
> But the point you seem to be missing is that this libarry
> now is a *standard* part of C++.


Yes, and the sort operator is a part of the standard
language in the case of APL.

So if C++ is better than Ada because the standard library
has a sort built in, and therefore allows a shorter sorting
routine, by the same argument APL must be even better than
C++, since the sorting is even more built in, and we can
get an even shorter sorting routine.

<end of quote>

To me this still looks like an argument against standardization of
functions.
If you don't get any advantages by standardization, why bother?

-- 
E pluribus Unix

Re: Ada vs C++ vs Java

[robert_dewar]

In article <umq679aegyo.fsf@maestro.clustra.com>,
  Ole-Hjalmar Kristensen <ohk@maestro.clustra.com> wrote:
>
> To me this still looks like an argument against
> standardization of functions. If you don't get any
> advantages by standardization, why bother?

VERY muddled thinking. Your argument goes like this

  Dewar does not think sort should be standardized.

  Sort is a function

  Therefore Dewar does not think functions should be
  standardized.

Well, a classical example of a faulty syllogism. I will
add it to my set of such examples for teaching!

In fact of course I think it is very important to
standardize library functions. I think for example that
it is horrible that C++ has no standardized functions for
dealing with concurrency or with interfacing to other
languages.

Of course I could play the game of writing a five line
Ada program that cannot be duplicated in standard C++ using
either of these features, but that would prove nothing of
itself.

Everyone agrees that a certain minimum set of libraries
should be part of a language standard. The issue for a
particular functionality here is what status it should
have:

   1. Be part of the primary standard
   2. Be part of a secondary standard
   3. Not be standardized

No one is so foolish as to think that every possible
function should be standardized. I do not make the mistake
of assuming that since Ole-Hjalmar thinks that sorting
should be in category 1, it means that he thinks this!

So the issue is not one of general principles here AT ALL.
It is a detailed discussion of which category a particular
functionality falls into.

The C++ and Ada standards both made decisions in this area,
quite different sets of decisions, which leave different
sets of functionality in the standard. I happen to think
that in general Ada made the better set of choices here,
but general claims like this are not really usefull
arguable anyway, so may as well be left moot.

What is productive is to argue about specific cases.
The interesting thing is that Ole-Hjalmar in this exchange
has not given even a single reason why sort in particular
should be standardized.

Merely showing an example that says

1) if X is standardized, then we will be able to write a
short standard program performing function X

is not any kind of argument at all, you might equally well
argue for the inclusion of a special function for
converting HTML files to postscript ("look how short this
standard program for converting HTML to postscript is, bet
you can't do that in language X!")

On the other hand, some cogent arguments for NOT
standardizing sort have been presented. Certainly no one
writing Ada programs has to rewrite a sort algorithm from
scratch. There is a large library of standard sort routines
to choose from, and you choose the one that fits your needs
best.


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[mike]

In article <79s23i$ena$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com
says...
 
>The interesting thing is that Ole-Hjalmar in this exchange
>has not given even a single reason why sort in particular
>should be standardized.
>

The argument is simple.

Having a standard function to do X, makes it more convenient for the 
programmer using the language.

If a standard function to do X was not part of the libraries that 
come in the box, then the programmer would either go use a different 
language tat has those functions they need, or spend more time 
hunting the net looking for such a function, or spend more time 
writing their own.

ofcourse having a standard function to do X, does not mean that 
one has to use that function, they could still use an external 
library that provide a different function to do X also.  But the 
point is that, the more standard functions come in the box, the more 
popular the language become for the programmers.  

Take Java for example. Java provides a package for doing SQL stuff.

This means it is now very easy to use Java to access databases. 

This has also meant more and more programmers are now using Java to 
write database applications. (No one even asks if Java SQL package is
the 'best' in the world, programmers are happy that it comes as part
of Java packages out of the box). 

If Ada had an SQL package as part of its standard or annex libraries, 
its effect would have been to make Ada more popular also. 

people want convenient things. and programmers are people, so it
follows that programmers want convenient languages ;) 

>On the other hand, some cogent arguments for NOT
>standardizing sort have been presented. Certainly no one
>writing Ada programs has to rewrite a sort algorithm from
>scratch. There is a large library of standard sort routines
                           ^^^^^^^^^^^^^^^^^^^^^^^^^
>to choose from, and you choose the one that fits your needs
>best.
>
 
if they are standard, then it would be easy to package them as part of an Ada
pacakge and ship it with GNAT (as an auxillary set of Ada standard
library sort of)?. 

For me, it does not really matter if the packages are part of 
the standard language proper, or an extention, or part of
annex, or whatever you want to call it. The point is, as long as they
come in the same box that compiler comes in, I am, and millions and
millions of other Ada programmers will be happy.

mike

Re: Ada vs C++ vs Java

[nabbasi]

In article <79s889$as4@drn.newsguy.com>, mike says...
>


>
>The argument is simple.
>
>Having a standard function to do X, makes it more convenient for the 
>programmer using the language.
>
>If a standard function to do X was not part of the libraries that 
>come in the box, then the programmer would either go use a different 
>language tat has those functions they need, or spend more time 
>hunting the net looking for such a function, or spend more time 
>writing their own.
>

Many such packages are a quick web click away, see:

http://home.earthlink.net/~nabbasi/

Nasser
 

Re: Ada vs C++ vs Java

[Al Christians]

mike wrote:
> 
> For me, it does not really matter if the packages are part of
> the standard language proper, or an extention, or part of
> annex, or whatever you want to call it. The point is, as long as they
> come in the same box that compiler comes in, I am, and millions and
> millions of other Ada programmers will be happy.
> 

I agree with mike.

An important thing to remember is that reuse and quality are highly
correlated.  Aonix used to emphasize this as part of their sales pitch.
As a component is widely and frequently reused, it accumulates trust.
The NIH excuse is not so viable when the standard development
environment comes with the desired function builtin and in wide usage.   
It should include everything that will be used often enough to 
actually deserve that trust.

Al

Re: Ada vs C++ vs Java

[robert_dewar]

In article <36C1BC8C.253C6E6D@easystreet.com>,
  Al Christians <achrist@easystreet.com> wrote:
> An important thing to remember is that reuse and quality
> are highly correlated.  Aonix used to emphasize this as
> part of their sales pitch. As a component is widely and
> frequently reused, it accumulates trust. The NIH excuse
> is not so viable when the standard development
> environment comes with the desired function builtin and
> in wide usage. It should include everything that will be
> used often enough to actually deserve that trust.

But there are many ways such trust is accumulated. For
example, I think for many people the Microsoft foundation
classes are in this category, but they are of course NOT
part of the language standard, and no one would consider
them for inclusion in the standard.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[robert_dewar]

In article <79s889$as4@drn.newsguy.com>,
  mike <mike@newsguy.com> wrote:
> In article <79s23i$ena$1@nnrp1.dejanews.com>,
> robert_dewar@my-dejanews.com
> says...
>
> >The interesting thing is that Ole-Hjalmar in this
> >exchange
> >has not given even a single reason why sort in
> >particular
> >should be standardized.
> >
>
> The argument is simple.
>
> Having a standard function to do X, makes it more
> convenient for the programmer using the language.

That's complete nonsense. It argues for standardizing
every possible function. I do not know anyone in the
language design/standardization field who would make
such an absurd claim. For example, if someone suggested
that the ISO C++ standard should contain a standardized
function for converting Microsoft WORD version 5.0 files
to Word 7.0 format, they would be regarded as eccentric
at best, and off the wall at worst. Yet the general
argument you give would argue in favor of such an addition.

What everyone agrees on is that a language standard should
contain standardized versions of functions whose
specification and implementation are completely standard,
and whose utility justifies their inclusion.

Different languages make different decisions in this area.
For example, Ada considers that control over priority
of executing threads is in this category, but sorting is
not, and C++ makes exactly the opposite decisions.

Which set of decisions is right? Perhaps one, perhaps the
other, perhaps neither, perhaps both (the requirements
may be different after all). Discussion of whether a choice
is right in a particular case is an interesting technical
discussion, but general arguments of the kind proposed here
do not add even epsilon of value to the discussion of a
specific case.

Standardization is a double edged sword, it has the
advantage of creating a single fixed way of doing things.
It has the disadvantage of stifling continued technical
development and improvement and specialization to a
particular requirement. Every standardization effort
involves carefully deciding *what* to standardize to
reap the advantages, and minimize the disadvtantages.

So I will repeat, no one yet has given arguments as to why
sort *should* be standardized, though we have seen some
arguments on the contrary side.
>
> Take Java for example. Java provides a package for doing
> SQL stuff.

If you are trying to say that the Java standard includes
this function, you are wrong. Why? Because there is no
Java standard, just an informal language design, with
several implementations, which conform more or less to
this design.

It is often the case that actual implementations of
languages do include all sorts of useful functionality
(e.g. C programs can almost certainly call unlink even
though ANSI C has no such function, and Ada 95 programmers
using GNAT will indeed find some "standard" sorting
routines in the GNAT library. There are *many* sources of
informally "standard" routines available to anyone writing
in any language, and this kind of reuse is of course
fundamental.

However, this does not mean that everything possible should
be standardized.

Indeed what often happens is that even where everyone
agrees that something should be standardized, the rigorous
requirements of a standard break down the consensus. For
example, everyone obviously agrees that functions like
sqrt, sin, cos should be standardized, but in the Ada
world, even the standardization of these functions was
very tricky -- why? Because Ada is an odd language, it
thinks that the accuracy of floating-point operations
should be defined :-) Given this attitude, you have to
worry about required accuracy of these primitive
operations, and that is not easy.

Another point is that secondary standards are often the
appropriate way to go. Ada has a standard for SQL binding
(one that is incidentally far more sophisticated and better
thought out than the Java implementation), but it is a
secondary standard, since it really required a separate
working group to work out the details. The math functions
for Ada 83 were handled in a similar manner, though for
Ada 95, the decision was to incorporate this work into the
main standard (the SQL secondary standard was not
incorporated).

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Jean-Pierre Rosen]

robert_dewar@my-dejanews.com a �crit dans le message
<79s23i$ena$1@nnrp1.dejanews.com>...
>Of course I could play the game of writing a five line
>Ada program that cannot be duplicated in standard C++ using
>either of these features, but that would prove nothing of
>itself.
>
FIVE lines ? I know ONE line that cannot be easily duplicated in C++ :
   pragma Remote_Call_Interface ;

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

Re: Ada vs C++ vs Java

[Ole-Hjalmar Kristensen]

robert_dewar@my-dejanews.com writes:

> In article <umq679aegyo.fsf@maestro.clustra.com>,
>   Ole-Hjalmar Kristensen <ohk@maestro.clustra.com> wrote:
> >
> > To me this still looks like an argument against
> > standardization of functions. If you don't get any
> > advantages by standardization, why bother?
> 
> VERY muddled thinking. Your argument goes like this
> 
>   Dewar does not think sort should be standardized.
> 
>   Sort is a function
> 
>   Therefore Dewar does not think functions should be
>   standardized.

I am glad to hear that you have nothing against standardization of
functions in general. However, I assumed that the original poster
used sort as an *example* of how easy it is to use the standard C++
library.

I assume we then agree that C++ with its new standard library is
better than C++ without the same library, or am I jumping to
conclusions again?

> 
> Well, a classical example of a faulty syllogism. I will
> add it to my set of such examples for teaching!
> 

Always glad to be of service.

> In fact of course I think it is very important to
> standardize library functions. I think for example that
> it is horrible that C++ has no standardized functions for
> dealing with concurrency or with interfacing to other
> languages.
> 

There are indeed many horrible aspects of the C++ language.
But there are thread libraries freely available. It should not matter
that they are not part of the standard, right? :-)

> Of course I could play the game of writing a five line
> Ada program that cannot be duplicated in standard C++ using
> either of these features, but that would prove nothing of
> itself.
> 
> Everyone agrees that a certain minimum set of libraries
> should be part of a language standard. The issue for a
> particular functionality here is what status it should
> have:
> 
>    1. Be part of the primary standard
>    2. Be part of a secondary standard
>    3. Not be standardized
> 
> No one is so foolish as to think that every possible
> function should be standardized. I do not make the mistake
> of assuming that since Ole-Hjalmar thinks that sorting
> should be in category 1, it means that he thinks this!
> 
> So the issue is not one of general principles here AT ALL.
> It is a detailed discussion of which category a particular
> functionality falls into.

I never once mentioned sort. What I was talking about should be clear
from the following:

<start of quote>
robert_dewar@my-dejanews.com writes:

> In article <umqbtj9m636.fsf@maestro.clustra.com>,
>   Ole-Hjalmar Kristensen <ohk@maestro.clustra.com> wrote:
> > But the point you seem to be missing is that this libarry
> > now is a *standard* part of C++.
> 
> 
> Yes, and the sort operator is a part of the standard
> language in the case of APL.
> 
> So if C++ is better than Ada because the standard library
> has a sort built in, and therefore allows a shorter sorting
> routine, by the same argument APL must be even better than
> C++, since the sorting is even more built in, and we can
> get an even shorter sorting routine.
> 
> 
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Yes. And from this I infer that you think that any standardization of
libraries, or even built-in functions are a waste of time?
No, the point is that C++ has recently take a major step forward with
the acceptance of a standard library which is rather comprehensive and
has a sound foundation. Arguing that this is not needed in Ada is not
going to convince anyone to use Ada.

<end of quote>

> 
> The C++ and Ada standards both made decisions in this area,
> quite different sets of decisions, which leave different
> sets of functionality in the standard. I happen to think
> that in general Ada made the better set of choices here,
> but general claims like this are not really usefull
> arguable anyway, so may as well be left moot.
>

Yes, certainly which set of functions to include depends on what kind
of applications you foresee.

> 
> What is productive is to argue about specific cases.
> The interesting thing is that Ole-Hjalmar in this exchange
> has not given even a single reason why sort in particular
> should be standardized.
> 

No. Why should I? I was not discussing sort at all. But if you want an
argument, I'll give you one: For the majority of C++ applications it
does not matter how sort is implemented, as long as it's a reasonable
algorithm. If it *does* matter, write your own, or use another library
which includes precisely the sort you need. But having a sort
available is very nice if it works with the data structures you are using.

> Merely showing an example that says
> 
> 1) if X is standardized, then we will be able to write a
> short standard program performing function X
> 
> is not any kind of argument at all, you might equally well
> argue for the inclusion of a special function for
> converting HTML files to postscript ("look how short this
> standard program for converting HTML to postscript is, bet
> you can't do that in language X!")
> 

No. I have argued for the standardization of a richer set of generally
useful functions and data structures which fit together. The STL
library is an example of such a set. I also never argued that C++ is
better than Ada.

> On the other hand, some cogent arguments for NOT
> standardizing sort have been presented. Certainly no one
> writing Ada programs has to rewrite a sort algorithm from
> scratch. There is a large library of standard sort routines
> to choose from, and you choose the one that fits your needs
> best.
> 

Yes. But are those libraries always available on all platforms? If
they are not, it becomes tempting to write your own portable version,
something I would rather avoid. Also, does this library sort work with
my container classes, which I have included from another library?

> 
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

-- 
E pluribus Unix

Re: Ada vs C++ vs Java

[robert_dewar]

In article <umqsocdjin4.fsf@maestro.clustra.com>,
  Ole-Hjalmar Kristensen <ohk@maestro.clustra.com> wrote:
> There are indeed many horrible aspects of the C++
> language. But there are thread libraries freely
> available. It should not matter that they are not part of
> the standard, right? :-)

It matters very much, and your reply here clearly shows
that you have not spent much time trying to write portable
multi-threaded programs in C++. There are two primary
problems.

1. There *are* no portable standardized threads packages.
Pthreads is an attempt, but it leaves many important
details implementation dependent, and in any case, there
are very few implementations that are 100% compliant to the
IEEE standard.

2. Since threading is not part of the language, you have
no idea what will and what will not work in the presence
of threads, even a basic construct like X++ whose meaning
is clear in the base language becomes unclear in the
presence of threading (there are at least two possible
formal semantics in this case). THe problem of which
"standard" routines are or are not thread safe is a
particularly severe one.

So it does indeed matter very much whether functions are
standardized, and each function must be argued carefully
on its merits to see whether or not it should be included
in the standard.

I know you used :-) above, but still, the comment once
again seems to say:

Dewar thinks it is fine for sort not to be standardized
but rather to be freely available.

Sort is a function

Therefore Dewar thinks this is fine for all functions.

Please try to construct your syllogisms more carefully!

P.S. I suggest you quote more selectively, it is very hard
to find your replies buried in mounds of quoted material.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Dale Stanbrough]

robert dewar wrote:

"2. Since threading is not part of the language, you have
 no idea what will and what will not work in the presence
 of threads, even a basic construct like X++ whose meaning
 is clear in the base language becomes unclear in the
 presence of threading (there are at least two possible
 formal semantics in this case). THe problem of which
 "standard" routines are or are not thread safe is a
 particularly severe one."



Another example is the combination of thread termination and
destructors in C++. Of course the thread system has no idea about 
destructors, and so you have to either get _a_ compiler that does
the work, or fudge something by hand.


Dale

Re: Ada vs C++ vs Java

[Ole-Hjalmar Kristensen]

robert_dewar@my-dejanews.com writes:

> In article <umqsocdjin4.fsf@maestro.clustra.com>,
>   Ole-Hjalmar Kristensen <ohk@maestro.clustra.com> wrote:
> > There are indeed many horrible aspects of the C++
> > language. But there are thread libraries freely
> > available. It should not matter that they are not part of
> > the standard, right? :-)
> 
> It matters very much, and your reply here clearly shows
> that you have not spent much time trying to write portable
> multi-threaded programs in C++. There are two primary
> problems.
> 
> 1. There *are* no portable standardized threads packages.
> Pthreads is an attempt, but it leaves many important
> details implementation dependent, and in any case, there
> are very few implementations that are 100% compliant to the
> IEEE standard.
> 
> 2. Since threading is not part of the language, you have
> no idea what will and what will not work in the presence
> of threads, even a basic construct like X++ whose meaning
> is clear in the base language becomes unclear in the
> presence of threading (there are at least two possible
> formal semantics in this case). THe problem of which
> "standard" routines are or are not thread safe is a
> particularly severe one.
> 
> So it does indeed matter very much whether functions are
> standardized, and each function must be argued carefully
> on its merits to see whether or not it should be included
> in the standard.
> 
> I know you used :-) above, but still, the comment once
> again seems to say:
> 

Perhaps. But I never said that.

> Dewar thinks it is fine for sort not to be standardized
> but rather to be freely available.
> 
> Sort is a function
> 
> Therefore Dewar thinks this is fine for all functions.
> 
> Please try to construct your syllogisms more carefully!
> 
> P.S. I suggest you quote more selectively, it is very hard
> to find your replies buried in mounds of quoted material.
> 
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

And it is very hard to have a discussion with you when you remove that
much of the context from previous postings. I assume we are in
agreement for the parts of my last post that you did not comment upon.

-- 
E pluribus Unix

Re: Ada vs C++ vs Java

[robert_dewar]

In article <umqlni0yr7e.fsf@maestro.clustra.com>,
  Ole-Hjalmar Kristensen <ohk@maestro.clustra.com> wrote:
> And it is very hard to have a discussion with you when
> you remove that much of the context from previous
> postings. I assume we are in agreement for the parts of
> my last post that you did not comment upon.

Sorry, I don't understand, there is no point in quoting
stuff I am not commenting on (for my taste people quote
FAR too much).

And no, you cannot assume anything about things I do not
comment on!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[P.S. Norby]

Ole-Hjalmar Kristensen wrote:
> 

> There are indeed many horrible aspects of the C++ language.
> But there are thread libraries freely available. It should not matter
> that they are not part of the standard, right? :-)
> 

So, there are sort libraries freely available. It should not matter that
they are not part of the standard, right? :-)
-- 
P.S. Norby

"No excuses.  No embarrassment.  No apologies...
 Ada -- the most trusted and powerful programming language
 on earth, or in space." -- S. Tucker Taft
 
\\\    \\\    \\\    \\\    \\\    \\\    \\\    \\\    \\\ 
( :)   ( :)   ( :)   ( :)   ( :)   ( :)   ( :)   ( :)   ( :)
///    ///    ///    ///    ///    ///    ///    ///    /// 
(Speaking only for myself)

Re: Ada vs C++ vs Java

[Ole-Hjalmar Kristensen]

"P.S. Norby" <psnorby@cacd.rockwell.com> writes:

> Ole-Hjalmar Kristensen wrote:
> > 
> 
> > There are indeed many horrible aspects of the C++ language.
> > But there are thread libraries freely available. It should not matter
> > that they are not part of the standard, right? :-)
> > 
> 
> So, there are sort libraries freely available. It should not matter that
> they are not part of the standard, right? :-)
> -- 
> P.S. Norby
> 
> "No excuses.  No embarrassment.  No apologies...
>  Ada -- the most trusted and powerful programming language
>  on earth, or in space." -- S. Tucker Taft
>  
> \\\    \\\    \\\    \\\    \\\    \\\    \\\    \\\    \\\ 
> ( :)   ( :)   ( :)   ( :)   ( :)   ( :)   ( :)   ( :)   ( :)
> ///    ///    ///    ///    ///    ///    ///    ///    /// 
> (Speaking only for myself)

Sorry, but this was just my tongue-in-the-cheek answer to the original
poster who argued strongly that sort should not be standardized, but
that threads must be.

I would rather standardize both.

-- 
E pluribus Unix

Re: Ada vs C++ vs Java

[Fredric L. Rice]

Ole-Hjalmar Kristensen wrote:

> > So if C++ is better than Ada because the standard library
> > has a sort built in, and therefore allows a shorter sorting
> > routine, by the same argument APL must be even better than
> > C++, since the sorting is even more built in, and we can
> > get an even shorter sorting routine.

> Yes. And from this I infer that you think that any standardization of
> libraries, or even built-in functions are a waste of time?
> No, the point is that C++ has recently take a major step forward with
> the acceptance of a standard library which is rather comprehensive and
> has a sound foundation. Arguing that this is not needed in Ada is not
> going to convince anyone to use Ada.

Hell, no matter what Ada does -- venders and uses and programmers -- the
fact is that C++ has a plethora of extremely useful libraries that make
computer
software look and feel alike in so many ways that end-users have come to
expect what could almost be considered a standard.  Specifically, GUI with a
pop-up behavior, mechanical looking push buttons et al.

The Borland libraries make programming such applications easily enough that
non-programmers can hack something up in a day or two to do whatever it is
they need.

Until Ada acquired a set of libraries that make applications written in Ada
look
like they were written in Borland's or Microsoft's Windows class libraries, I
don't
think Ada - derived applications are going to be very popular.

Understand that I know squat about Ada as this point.  I've just never heard
of
any popular applications out in the real world having been written in Ada.
It
seems to me that everything these days is done in C++ with assembly language
blocks.

Re: Ada vs C++ vs Java

[Larry Kilgallen]

Reply-To: Kilgallen@eisner.decus.org.nospam
Organization: LJK Software
Lines: 11

In article <36BEECEF.70D8ED5E@pwfl.com>, Marin David Condic <condicma@bogon.pwfl.com> writes:

> What would be wrong with specifying a couple of "standard" generic sort
> routines that provided some of the most common algorithms? There are
> only so many versions of a Quicksort or Heapsort that anyone needs and
> having a "standard" version would a) eliminate duplication of effort and
> b) establish a "model" interface for any other sorting algorithms.

How about a single sort interface with one parameter being the algorithm ?

Larry Kilgallen

Re: Ada vs C++ vs Java

[Marin David Condic]

Larry Kilgallen wrote:
> 
> How about a single sort interface with one parameter being the algorithm ?
> 
Seems to me that when I was in school, the CS profs thought it was "A
Bad Thing" to pass parameters which controlled where the entry into a
subroutine would take place. Did they call that "Control Coupling"? or
was it something else? I don't know why you would have to have a single
name "Sort" for all possible sorting algorithms. These things have been
around long enough that most folks would recognize the algorithm name
and know why they would want to choose one over another. One might also
want to build sort operations for files or some other constructs and the
name overloading might not be desirable in this case either.

Or one could specify a single array sort interface and leave the
algorithm "implementation defined"? Most often, the algorithm used is
not that critical as long as it gets the array sorted is some reasonable
span of time. This doesn't sit too well with me though - I'd prefer to
specify it through the procedure name.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

"Government is not reason. It is not eloquence. It is a force. 
Like fire, a dangerous servant and a fearful master."

    --  George Washington

Re: Ada vs C++ vs Java

[James S. Rogers]

Ole-Hjalmar Kristensen wrote in message ...
>
>But the point you seem to be missing is that this libarry now is a
>*standard* part of C++.
>
>Comments?


Well, yes.

The C++ libraries are quit nice.  Unfortunately they are not nearly
what I really need for my domain.

You see, I need a set of libraries ( or more simply language
capabilities ) which support the development of a highly concurrent
design of asynchronous tasks.  The tasks are REQUIRED by
contract to communicate using shared message queues.

I know I can do all this in C++.  The trouble is that the language has
no libraries or intrinsic capabilities in these areas.  I must either buy
or make my own.

Ada gives me all of this as part of the basic language.  I do not even
need to call libraries to have tasking or protected types.

Note: Ada protected types are shared memory regions protected
from corruption by mutual access of the tasks sharing the region.
They are not at all like the protected part of a C++ class.

Jim Rogers
Colorado Springs, Colorado

Re: Ada vs C++ vs Java

[mike]

In article <79jeos$bu4@bgtnsc01.worldnet.att.net>, "James says...
>
>
>Ole-Hjalmar Kristensen wrote in message ...
>>
>>But the point you seem to be missing is that this libarry now is a
>>*standard* part of C++.
>>
>>Comments?
>

>
>Well, yes.
>
>The C++ libraries are quit nice.  Unfortunately they are not nearly
>what I really need for my domain.
>
>You see, I need a set of libraries ( or more simply language
>capabilities ) which support the development of a highly concurrent
>design of asynchronous tasks.  The tasks are REQUIRED by
>contract to communicate using shared message queues.
>
>I know I can do all this in C++.  The trouble is that the language has
>no libraries or intrinsic capabilities in these areas.  I must either buy
>or make my own.
>

This is really a question of "should a langauge have a build-in support for
threads or not" . This is not a question of libraries.

This question has been debated many times, and if the only argument you
have for Ada over C++ is this, then this is a weak argument, (Java have
build-in support for threads, plus much more rich standard library than
Ada).

It is not clear which is better to have a build-in support in the language 
for threads or using an external STANDARD threads library instead.

nowadays posix pthreads IS standard. With the pthreads library you can 
build anything you can build with Ada tasks and more (Ada tasks actually are
implemented using pthreads on such platforms).

>Ada gives me all of this as part of the basic language.  I do not even
>need to call libraries to have tasking or protected types.
>

I does not matter. pthreads is standard, calling it from your program is
not much different from using a language build-in task. you simply 
add pthreads library to you Makefile and that is it. It is no big deal.
 
I agree that Ada tasks and things like protected types make life a little
easier since it is a higher level abstraction than using pthreads
directly, but someone who knows pthreads well, can build these
abstraction using pthreads also (as in threads C++ classes which acts
as higher level wrappers around pthreads), a little more work, yes, but
it is not hard to use pthreads anyway, it is a very flexible API, and you
get the primitives that you can build any model you want from.

The point is, at the end of the day, it comes back to how extensive and usefull
is the standard library is. In Ada, it is not, with C++ and Java, the
standard library is much more advanced. GNAT for example is doing something
good by adding standard GNAT packages as part of GNAT such as that pattern
matching package. Much more of this is needed. Then we can talk real business.

mike

Re: Ada vs C++ vs Java

[James S. Rogers]

mike wrote in message <79k65l$s0t@drn.newsguy.com>...
>This is really a question of "should a langauge have a build-in support for
>threads or not" . This is not a question of libraries.
>
>This question has been debated many times, and if the only argument you
>have for Ada over C++ is this, then this is a weak argument, (Java have
>build-in support for threads, plus much more rich standard library than
>Ada).

Java thread support is actually quite weak compared to that in Ada.
C++ thread support does not exist.

>
>It is not clear which is better to have a build-in support in the language
>for threads or using an external STANDARD threads library instead.
>
>nowadays posix pthreads IS standard. With the pthreads library you can
>build anything you can build with Ada tasks and more (Ada tasks actually
are
>implemented using pthreads on such platforms).


What do you do when your operating system does not support
posix threads?  What do you do when your program runs on a bare
microcontroller with no operating system at all?  Posix threads
libraries are of no use at all in these cases.

Support for posix threads only is much like support for abstract
data types.  You can build all the queues, bags, lists, etc. in any
language with support for abstract data types.  As you have said
before, this is not the same as having standard solutions for the
higher level abstractions.

Saying high level support for tasking does not count, while high level
support for abstract data types does count is carrying a double
standard.  It appears to me that you are saying "If my favorite
language supports the feature, then it is important. If my favorite
language does not support the feature, then the feature is not
important."  This discussion will get nowhere if this is your attitude.


>>Ada gives me all of this as part of the basic language.  I do not even
>>need to call libraries to have tasking or protected types.
>>
>
>I does not matter. pthreads is standard, calling it from your program is
>not much different from using a language build-in task. you simply
>add pthreads library to you Makefile and that is it. It is no big deal.
>
>I agree that Ada tasks and things like protected types make life a little
>easier since it is a higher level abstraction than using pthreads
>directly, but someone who knows pthreads well, can build these
>abstraction using pthreads also (as in threads C++ classes which acts
>as higher level wrappers around pthreads), a little more work, yes, but
>it is not hard to use pthreads anyway, it is a very flexible API, and you
>get the primitives that you can build any model you want from.
>
>The point is, at the end of the day, it comes back to how extensive and
usefull
>is the standard library is. In Ada, it is not, with C++ and Java, the
>standard library is much more advanced. GNAT for example is doing something
>good by adding standard GNAT packages as part of GNAT such as that pattern
>matching package. Much more of this is needed. Then we can talk real
business.

This gets to the real point of the discussion.  "How useful and
extensive is the standard library?"  Usefulness is, like beauty, in
the eyes of the beholder.  In my work the C++ standard library is
of no use.  On the other hand, the Ada high level support for tasking,
and the Ada standard library, are extremely useful.  It appears to be
otherwise for you.  This situation is to be expected.

How does a language standardization team decide what to put into
a standard library, and what to exclude?  It must be based upon the
experiences of the standardization team.  Those experiences are
founded upon the kinds of problems the team has most experience
solving with software. The C++ team clearly has a different
background than the Ada team.  Does this make one team more
correct than the other.  I do not think so.  Does this, therefore, make
one language more correct than the other.  The answer must be
NO.

It is human nature to want all things to be familiar.  The natural
extension of that in computer languages is that we tend to want all
languages to be like the language we use most. If one language
were really the best solution for all problems, then there would only
be a small set of computer languages.  The fact that there are
hundreds of computer lanuages indicates that no single language
is best for all problems.

>
>mike

Jim Rogers
Colorado Springs, Colorado

Re: Ada vs C++ vs Java

[mike]

In article <79kd5j$q5r@bgtnsc01.worldnet.att.net>, "James says...
>
>
 
>
>How does a language standardization team decide what to put into
>a standard library, and what to exclude?  It must be based upon the
>experiences of the standardization team.  Those experiences are
>founded upon the kinds of problems the team has most experience
>solving with software. 

So, this is the problem then.

If all what Ada is to be used for is real-time, and embedded systems, then
fine. But if you want Ada to be used in the commerical non DoD sector, you
need to add to the standard library things that are needed in the commerical
world.

Look at Java Packages and you'll see what I mean.

>The C++ team clearly has a different
>background than the Ada team.  

Yes, it is backgound in commerical applications? where 99% of software
is written.
 
mike.

Re: Ada vs C++ vs Java

[atomly]

In article <79klod$qud@drn.newsguy.com>,
  mike <mike@newsguy.com> wrote:
> If all what Ada is to be used for is real-time, and embedded systems, then
> fine. But if you want Ada to be used in the commerical non DoD sector, you
> need to add to the standard library things that are needed in the commerical
> world.
>
> Look at Java Packages and you'll see what I mean.
>
> Yes, it is backgound in commerical applications? where 99% of software
> is written.

OK, I agree with you that C++ and Java are better than Ada (though I have no
real experience with Ada) however I have to disagree with you on something
here. 99% of software isn't written in the commercial sector.  I don't think
you realize how much the government uses computers or you just choose to
ignore it. This, combined with private software and such, makes commercial
software a much less significant portion than you stated.

This may seem like nit-picking, but I felt it had to be said because the basis
of your argument seemed to be that commercial software is a much more worthy
cause because that's where all software is developed- and I felt this argument
was flawed.

Anyway, I'll leave this thread now, hoping to never venture back.

--
atomly@my-dejanews.com (atomly at mindless dot com)
http://pimplimp.hypermart.net
http://members.tripod.com/~atomly

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[robert_dewar]

In article <79l722$nc7$1@nnrp1.dejanews.com>,
  atomly@my-dejanews.com wrote:
> OK, I agree with you that C++ and Java are better than
> Ada (though I have no real experience with Ada)

Isn't it remarkable how people don't let a little thing
like ignorance and lack of experience inhibit them in
stating opinions in the programming language field :-)

There are probably for example, more people who know
nothing about COBOL and are sure it is junk, than there
are COBOL programmers, and that is for sure true of Ada
(there are more certainly more people who know that Ada
is useless without knowing anything about it, than there
are people who know Ada -- just the other day I talked to
someone quite well known who shall be nameless, who made
a casual negative comment on Ada, not knowing who I was,
and when I questioned it, she was quick to admit she knew
nothing about Ada, and was just repeating "what she had
heard".

Well I guess it makes life simpler if you don't have to
waste time bothering with facts and data in formulating
your opinions!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Dan Nagle]

Hello,

robert_dewar@my-dejanews.com wrote:
> 
> In article <79l722$nc7$1@nnrp1.dejanews.com>,
>   atomly@my-dejanews.com wrote:
> > OK, I agree with you that C++ and Java are better than
> > Ada (though I have no real experience with Ada)
> 
> Isn't it remarkable how people don't let a little thing
> like ignorance and lack of experience inhibit them in
> stating opinions in the programming language field :-)
> 
The Fortran folks have the same problem.  There's now an effort
underway to create a website designed to refute the "Fortran
Misinformation".  Go over to comp.lang.fortran and check
the thread "Re: Fortran misinformation", it's been on for a week
or so.

Is there a similar site for Ada misinformation?

It seems a lot of folks know only C/C++/Java, and, as the saying
goes "when the only tool in your toollbox is a hammer, every
problem looks like a nail"...

<snip rest of post>

-- 

Cheers!
Dan Nagle		dnagle@erols.com

Re: Ada vs C++ vs Java

[Pascal Obry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]


atomly@my-dejanews.com a �crit dans le message
<79l722$nc7$1@nnrp1.dejanews.com>...
>
>OK, I agree with you that C++ and Java are better than Ada (though I have
no
>real experience with Ada) however I have to disagree with you on something


This is just amusing !!!

You do not know Ada, fine, then please just say nothing about it !

Pascal.


--|------------------------------------------------------------
--| Pascal Obry                               Team-Ada Member |
--|                                                           |
--| EDF-DER-IPN-SID- T T I                                    |
--|                       Intranet: http://cln46gb            |
--| Bureau N-023            e-mail: pascal.obry@edf.fr        |
--| 1 Av G�n�ral de Gaulle  voice : +33-1-47.65.50.91         |
--| 92141 Clamart CEDEX     fax   : +33-1-47.65.50.07         |
--| FRANCE                                                    |
--|------------------------------------------------------------
--|
--|   http://ourworld.compuserve.com/homepages/pascal_obry
--|
--|   "The best way to travel is by means of imagination"

Re: Ada vs C++ vs Java

[Jean-Pierre Rosen]

>If all what Ada is to be used for is real-time, and embedded systems,
then
>fine. But if you want Ada to be used in the commerical non DoD
sector, you
>need to add to the standard library things that are needed in the
commerical
>world.
>
>Look at Java Packages and you'll see what I mean.
>
I had a look at Java packages. Sure there are lots of them. Half are
obsolete or superseded.
I found once a class that looked nice, but the manual said it was
obsolete and that I should use a new one. Fine, I went to the other
one. There was a notice there confirming that, right, that was the one
to use, but unfortunately it was recognized neither by IE 4 nor by
Netscape 4.
There is also (at least) one "obsolete" function that is a misspelling
(get_decent instead of get_descent). But since it was first released
this way, and some people started using it with the misspelling, they
will be forced to keep the obsolete misspelled functions for
centuries.
And then I was hardly getting acquainted with AWT when I learned that
I should use SWING instead.

That's what happens when you release immature technology, that has not
even been carefully reviewed.

Sure, it builds an impressive library !
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Ada vs C++ vs Java

[Geoff Bull]

"James S. Rogers" wrote:
> 

> 
> Java thread support is actually quite weak compared to that in Ada.
> C++ thread support does not exist.
> 
For example, Thread.setPriority () is not guaranteed to do
anything to thread priorities - this is a pain in the proverbial.

There is no control of thread scheduling policy, a program that
works on one platform may fail on another.

Also the Runtime.runFinalizersOnExit() method has been deprecated
because it is not thread safe.
If you can't guarantee that finalizers get run at least once,
they are completely useless for some applications
(like flushing files when the application exits)!


> you can
> >build anything you can build with Ada tasks and more (Ada tasks actually
> are
> >implemented using pthreads on such platforms).
> 
> What do you do when your operating system does not support
> posix threads?  
Does win32 have posix threads?
I don't recall seeing posix threads on my MS windows box,


> It is human nature to want all things to be familiar.  The natural
> extension of that in computer languages is that we tend to want all
> languages to be like the language we use most. 

Then, why do I pine for the power for Ada all day everyday
when I'm using Java all day everyday (for an application
 to which Java is not suited)?

GB

Re: Ada vs C++ vs Java

[Fredric L. Rice]

"James S. Rogers" wrote:

> >This question has been debated many times, and if the only argument you
> >have for Ada over C++ is this, then this is a weak argument, (Java have
> >build-in support for threads, plus much more rich standard library than
> >Ada).
>
> Java thread support is actually quite weak compared to that in Ada.
> C++ thread support does not exist.

In the OS/2 world it does.  The VisualAge C+ compiler comes with a suit of
APIs for launching and managing multi-threaded as well as multi-tasking (well,
pseudo multitasking, I suppose) applications.

Yeah, it's not part of the language but some venders have taken advantage of
OS/2 to make it work well.

Re: Ada vs C++ vs Java

[Marin David Condic]

Fredric L. Rice wrote:
> 
> In the OS/2 world it does.  The VisualAge C+ compiler comes with a suit of
> APIs for launching and managing multi-threaded as well as multi-tasking (well,
> pseudo multitasking, I suppose) applications.
> 
The problem here is that you are looking at one implementation of the
language on one platform. In addition, it is not the "language" which is
giving you the feature - although in many people's minds there is no
distinction made. It is the OS which is providing the feature, with the
language merely giving you a method of connecting to the OS calls. On
WinNT at least, the Win32ada interface (supplied with GNAT 3.11p) gives
you that exact same capability.

Ada originally had a requirement (and still does) to be designed with a
high degree of portability in mind. Whatever features the language
standard specified needed to be done in such a way that they could be
implemented on just about anything from bare hardware, to PCs &
workstations to mainframes. To a very large extent, Ada has succeeded in
this goal. Just look at all the platforms to which GNAT is ported. And
then visit the web pages for Aonix, Green Hills, et alia to find even
more targets.

Ada's direct language support for multi-threading was necessary because
in the embedded, realtime world you are working on bare silicon and
basically have to write your own operating system. (Among other things,
that's what I do for a living :-) The availability of tasks makes this a
snap. If you are developing for machines running WinNT or Unix the
compiler will presumably (but is not required to) map the task
structures onto supporting OS calls. So with Ada, you get the ability to
do multi-threading in a wide array of environments with everything
looking identical to the programmer. C/C++ may give you that capability
indirectly by supplying you with an interface to the OS calls and you
can "roll your own", but this is quite obviously not easily ported, nor
is the knowledge/learning curve of the programmer. Yes, you can get
there from here, but its just easier with Ada.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

"Government is not reason. It is not eloquence. It is a force. 
Like fire, a dangerous servant and a fearful master."

    --  George Washington

Re: Ada vs C++ vs Java

[Simon Wright]

mike <mike@newsguy.com> writes:

> I does not matter. pthreads is standard, calling it from your program is
> not much different from using a language build-in task. you simply 
> add pthreads library to you Makefile and that is it. It is no big deal.

My experience of trying to read others' code using pthreads is that it
is VERY VERY different from using tasks/protected types in Ada.

Or even, I suspect, threads in Java.

OK, if all you want is a thread that can use shared variables to
communicate, it's not too bad, but as soon as you have threads trying
to synchronise/communicate it gets too much. Much better to let your
Ada compiler vendor take the strain.

Re: Ada vs C++ vs Java

[robert_dewar]

mike <mike@newsguy.com> writes:

> I does not matter. pthreads is standard, calling it from
> your program is not much different from using a language
> build-in task. you simply add pthreads library to you
> Makefile and that is it. It is no big deal.

Actually the big deal is precisely the above attitude. It
is of course totally false that it is no big deal to go to
the use of pthreads.

Making programs thread safe is not at all easy (and indeed
the C and C++ language, by not providing nested subprograms
make this technically difficult). In addition, the
semantics of basic C constructs is not well defined in the
presence of threading. The interaction of threading with
language semantics is very tricky. The Ada design gave a
lot of careful thought to it, the C and C++ design was of
course pretty much oblivious to this (you cannot get any
hint for example of whether standard functions mentioned
in the ANSI C standard are required to be thread safe,
because the issue was simply not considered).

As for pthreads being a standard: only someone not very
familiar with pthreads would make this casual statement
with the implication that there are no portability issues.
In fact critical semantics in pthreads is (quite
deliberately) left implementation defined, at least partly
as a result of failing to agree on specific requirements.

The threading in Ada is FAR more tightly defined, and in
fact as a result it is simply not possible to map Ada
threading into pthreads (because the pthreads standard
leaves too much undefined). GNAT is for sure implemented
over a pthreads layer on most machines, but we have to
provide specialized interfaces to each different pthreads
implementation to deal with idiosyncrasies of that
particular implementation. When you are using Ada, the Ada
runtime has taken care of these variations. When you write
in C or C++, the application has to deal with these
variations if it wants to be portable.

So how come in practice people can successfully write C
applications using pthreads? In a lot of cases, the code is
simply not portable. People experiment and find out what
works on a given operating system. Most people using
pthreads have not even read the pthread standard, let alone
carefully absorbed all the technical details so that they
know what needs to be done to write fully portable code,
and as a result much pthreads code written in C is simply
not portable.

When we work with customers trying to port Ada applications
from one system to another, we find that if people have
stuck to the standard Ada tasking semantics, then porting
can be relatively straight forward. If they have used
implementation dependent thread stuff directly, the code is
often very difficult to port. Of course, as usual Ada is
not a guarantee of doing things right, but it often
encourages people to write portable code.

In this particular case, it is quite easy to write
completely portable multi-threaded code using Ada, without
needing any knowledge at all of the underlying operating
system or its particular implementation of pthreads.

I must say it is a big disappointment to us as Ada
implementors that the pthreads world is such a mess. We had
hoped that standardization of pthreads would make it as
easy to move our tasking implementation from one system to
another as it is to move our I/O implementation, but this
is far from the case. Just have a look at the GNAT sources
to see how much target dependent code is required in the
tasking runtime to deal with idiosyncrasies of various
systems. Of course an Ada *programmer* as opposed to an
Ada *implementor* does not have to worry about this, but
you have no such distinction in the C world!


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[nabbasi]

In article <79pdd1$3mj$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com
says...
 
>
>I must say it is a big disappointment to us as Ada
>implementors that the pthreads world is such a mess.

There is also Windows threads, which is not pthreads. And
this is another reason why using Ada, and Ada tasks would 
make life so much simpler, since the Ada run-time would 
take care of what threading is used on the platform.

As for the issue that Rober Dewar raised about pthreads "standard" 
behaving differently on different platforms, I can give an 
example exactly to ilustrate this point. During recent port of some 
application that used pthreads:

Calling sigtimedwait() from inside a signal handler. 
This worked Ok on Solaris (and few other platforms), when the 
code was ported to AIX, this introduced a subtle bug, where 
it turned that doing the above was not safe and did not work on 
AIX, and the code has to be changed so not to call sigtimedwait() 
when in a signal handler.

Also, on AIX, sending a pthread_kill(SIGUSR2) to a thread
who is in pthread_cond_wait() caused a problem, while on
Solaris it seemed to work ok.

These were not easy bugs to find and fix by the the developers,
it took allot of time to fix.  Using Ada and Ada tasks would have meant
that this threaded code would have been more portable and since
Ada gives a higher level of task abstraction and constructs, I would
also say the design would have been easier to understand.

But is any one in the commerical world listening? it does not seem so,
people are still writing large complex applications in windows threads
and in pthreads and in C and C++, and now also in Java threads.

I became aware recently of a HUGE application being designed and
developed now in some large finanical company that is heavlly threaded
and real-time, and it is being done on NT and using window threads :(

A smart person I would say, would use this well kept secret of Ada,
and would go and build a better and more robust applications in Ada, 
and would not let any of the competition know that they used Ada, so
that they would continue to waste their time and money as they wish.
 
Why let the competition know about something that might be good for
them if they used it?

Nasser


 

Re: Ada vs C++ vs Java

[robert_dewar]

In article <79k65l$s0t@drn.newsguy.com>,
  mike <mike@newsguy.com> wrote:
> This is really a question of "should a langauge have a
> build-in support for threads or not" . This is not a
> question of libraries.

Of *course* this is a question of libraries. Thread safety
is a critical aspect of a library (which often affects the
interfaces as well as the implementations).

Yes, it is harder to write portable thread safe libraries
in a language that does not natively support threads, no
doubt about it.

But to say that this is not a library issue is rather
remarkable. Unfortunately FAR too many people agree with
you and an amazing amount of thread-unsafe code has been
produced in the past.

Note incidentally that the lack of nested procedures is a
nasty problem for thread safety, since it means that one
has to pass parameters everywhere or use globals. Globals
are of course a danger spot for thread safety!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Bjarne Stroustrup]

Dan Nagle <dnagle@erols.com> writes:

 > Hello,
 > 
 > robert_dewar@my-dejanews.com wrote:
 > > 
 > > In article <79l722$nc7$1@nnrp1.dejanews.com>,
 > >   atomly@my-dejanews.com wrote:
 > > > OK, I agree with you that C++ and Java are better than
 > > > Ada (though I have no real experience with Ada)
 > > 
 > > Isn't it remarkable how people don't let a little thing
 > > like ignorance and lack of experience inhibit them in
 > > stating opinions in the programming language field :-)
 > > 
 > The Fortran folks have the same problem.  There's now an effort
 > underway to create a website designed to refute the "Fortran
 > Misinformation".  Go over to comp.lang.fortran and check
 > the thread "Re: Fortran misinformation", it's been on for a week
 > or so.
 > 
 > Is there a similar site for Ada misinformation?
 > 
 > It seems a lot of folks know only C/C++/Java, and, as the saying
 > goes "when the only tool in your toollbox is a hammer, every
 > problem looks like a nail"...
 > 
 > <snip rest of post>

Sadly, there is no shortage of misinformation or at least of relatively
ignorant people shooting their mouths off. Every language suffer from this
and every language community has members who contribute to the problem.

	- Bjarne
Bjarne Stroustrup - http://www.research.att.com/~bs

Re: Ada vs C++ vs Java

[robert_dewar]

In article <F6usID.E6r@research.att.com>,
  bs@research.att.com (Bjarne Stroustrup) wrote:
> Sadly, there is no shortage of misinformation or at least
> of relatively ignorant people shooting their mouths off.
> Every language suffer from this and every language
> community has members who contribute to the problem.
>
> 	- Bjarne


This is very true. And some of the LEAST effective advocacy
for language X consists of ignorant statements by X
advocates about language Y when they do not know language
Y well enough.

You can substitute almost any two languages for X and Y,
but I certainly often notice the cases

  X = Ada, Y = C ++
  X = C++, Y = Ada

and I particularly wince when I see Ada advocates make
totally incorrect statements about C or C++. Obviously
a lot of Ada advocates have not carefully read the
C and C++ standards. Of course vice versa is even more
prevalent. Indeed one interesting difference between
professional C/C++ programmers and professional Ada
programmers is that the latter at least have read the
Ada standard, whereas it often surprises me how many
C and C++ programmers are completely unfamiliar with
the standards for the languages they use. Certainly this
is an important area for better education!

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Geoff Bull]

mike wrote:
> 

> This is really a question of "should a langauge have a build-in support for
> threads or not" . This is not a question of libraries.
> 
I think threading is an important question of libraries.
A reasonable number of methods in the Java libraries
have had to be deprecated because they are not thread safe
I think you might be surprised when your libraries screw up
when you try to write a threaded C++ program - have they been
designed with threading in mind?
Do the C++ compiler vendors certify that their libraries 
work with threading?

Geoff

Re: Ada vs C++ vs Java

[Ole-Hjalmar Kristensen]

"James S. Rogers" <jimmaureenrogers@worldnet.att.net> writes:

> Ole-Hjalmar Kristensen wrote in message ...
> >
> >But the point you seem to be missing is that this libarry now is a
> >*standard* part of C++.
> >
> >Comments?
> 
> 
> Well, yes.
> 
> The C++ libraries are quit nice.  Unfortunately they are not nearly
> what I really need for my domain.
> 
> You see, I need a set of libraries ( or more simply language
> capabilities ) which support the development of a highly concurrent
> design of asynchronous tasks.  The tasks are REQUIRED by
> contract to communicate using shared message queues.
> 
> I know I can do all this in C++.  The trouble is that the language has
> no libraries or intrinsic capabilities in these areas.  I must either buy
> or make my own.
> 
> Ada gives me all of this as part of the basic language.  I do not even
> need to call libraries to have tasking or protected types.
> 
> Note: Ada protected types are shared memory regions protected
> from corruption by mutual access of the tasks sharing the region.
> They are not at all like the protected part of a C++ class.
> 
> Jim Rogers
> Colorado Springs, Colorado
> 
> 

Certainly. I did not mean that the standard C++ library meets all
needs, although it does contain much of the "standard" algorithms and
data structures. However, this will make it easier to write many
applications, and I cannot see why adding a standard library with a
larger set of algorithms and data structures to Ada would be wrong.
But the main point is that it have to be standard, so I can rely on
finding it on any implementation.

Btw., the project I'm working on at the moment uses C++, but I argued
strongly for Ada when the project was in its infancy (ca. 1990). C++
was chosen for the following reasons:

1. Almost every possible customer argued that they were using, or
would be using C++ internally, and that C++ was the language of the
future. (the implication being that we would be at a disadvantage if we
did not choose C++)

2. Ada compilers were very expensive. (so were many C++ compilers)

3. We were not able to find an Ada compiler for some of our possible
OS/hardware targets.

4. There were serious doubts about the Ada task switching mechanism
being efficient enough.

5. There were few designers/programmers with Ada experience, and it
was thought that it would be easier to go to C++ for people who had
programmed in C for a long time. Experience has shown that this is
probably not so....

Today, I would say that argument 4 is the only possible serious
drawback. We run our own lightweight thread package, which is very
primitive, and very fast. Ada tasks would have done the design and
programming a lot easier, and on todays computers I believe it would be
fast enough. We could of course have rolled our own in Ada as well.

The main problems we have seen in C++, apart from some unsafe traits,
is that templates have in practice not been portable, because
implementations have been too different (at least until
recently). Simple usage of templates has worked OK, but as soon as we
have used more complex templates, all sorts of problems have
appeared. As a result, we shied away from templates.

-- 
E pluribus Unix

Re: Ada vs C++ vs Java

[Larry Kilgallen]

Reply-To: Kilgallen@eisner.decus.org.nospam
Organization: LJK Software
Lines: 10

In article <36C006B8.FC6C187D@acenet.com.au>, Geoff Bull <gbull@acenet.com.au> writes:

> Do the C++ compiler vendors certify that their libraries 
> work with threading?

If the compiler vendors do not supply access to the threading package,
it would seem there is no way they could no what threading package was
to be used, and thus what they have to safeguard.

Larry Kilgallen

Re: Ada vs C++ vs Java

[Fredric L. Rice]

robert_dewar@my-dejanews.com wrote:

> In article <79chc7$ko6@drn.newsguy.com>,
>   mike <mike@newsguy.com> wrote:
> > Look at this code below posted here recently by another
> > poster. This code sorts a list of names inputed from
> > stdin, look how clear, short, elegent, and easy to read
> > it is.
>
> <silly example using a library sort routine>>
>
> That truly is the silliest example we have had in an
> otherwise informative thread.
>
> I can only say that if you think this argument is valid,
> then you will love APL, where the same sorting routine can
> be done in 4 or 5 characters (you do not have to put up
> with wordy things like "sort" in APL, since sorting can be
> done with a single character!).

That's true.  The overstriked Del or Delta with scallar for either
assending or decending sorts.  Love it!  I purchased IP Sharp's
APL quite a few years ago and never found a use for it -- other
than as a toy.

I'm stepping into this forum to get some idea as to what ADA
is all about.  Generally, I'll be learning Perl and CGI scripts
before I learn ADA but this looks like the place to get a good
feel for the language.

Re: Ada vs C++ vs Java

[Marin David Condic]

Fredric L. Rice wrote:
> 
> I'm stepping into this forum to get some idea as to what ADA
> is all about.  Generally, I'll be learning Perl and CGI scripts
> before I learn ADA but this looks like the place to get a good
> feel for the language.

Glad to see you have an attitude that has not written Ada off based on
rumors & misinformation :-) We get a lot of that here and it can be
frustrating. 

You might start by downloading the GNAT Ada compiler. It works quite
well and is an excellent place to get your feet wet with the language.
(ftp://cs.nyu.edu/pub/gnat) You might also want to check out
http://www.adahome.com/ which has lots of learning material and good
links to other resources.

BTW: Those of us who are Adaphiles consider it bad form to spell the
language name as ADA (Americans with Disabilities Act?) since Ada is a
proper name. The language was named after Ada Byron, Lady Lovelace
(1815-1852) - daughter of Lord Byron and the worlds first programmer.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

"Government is not reason. It is not eloquence. It is a force. 
Like fire, a dangerous servant and a fearful master."

    --  George Washington

Re: Ada vs C++ vs Java

[Geoff Bull]

mike wrote:

> C++ now, after becoming a standard, and with the standard library is a
> very safe language.

Not quite!

$ cat rat.c
#include <stdio.h>
int* one () {return &(1);}
int* two () {return &(2);}

void main (int argc, char** argv) {
    int* one_ptr = one (); int* two_ptr = two ();
    printf ("one = %d\n", *one_ptr);
    one_ptr = one ();
    printf ("two = %d\n", *two_ptr);
}

$ ./rat
one = 2
two = 1


One C compiler I used issued a warning, the other didn't.

You might think this is a ridiculous example, but I have
torn my hair out trying to find bugs as stupid as this code.
I can't think how I could possibly code this in Ada.

Then there's the write off the end of the array trick ...

Geoff

Re: Ada vs C++ vs Java

[Andrew Koenig]

In article <36BAF083.6C413B3D@acenet.com.au>,
Geoff Bull  <gbull@acenet.com.au> wrote:

> > C++ now, after becoming a standard, and with the standard library is a
> > very safe language.

> Not quite!

> $ cat rat.c
> #include <stdio.h>
> int* one () {return &(1);}
> int* two () {return &(2);}

Rest of program snipped, because this is enough to prove my point.

> One C compiler I used issued a warning, the other didn't.

Any compiler that accepts the above program is broken.
Neither 1 nor 2 is an lvalue, so you can't take the address
of either one.  A conforming C compiler is required to issue
a diagnostic message for such a program.

Moreover, this posting talked about C compilers, not C++
compilers.

How a statement of the form ``Some C compilers have bugs in them''
can possibly gainsay a statement about the C++ standard library
is beyond my comprehension.
-- 
				Andrew Koenig
				ark@research.att.com
				http://www.research.att.com/info/ark

Re: Ada vs C++ vs Java

[mike]

In article <36BAF083.6C413B3D@acenet.com.au>, Geoff says...
>

>
>mike wrote:
>
>> C++ now, after becoming a standard, and with the standard library is a
>> very safe language.
>

>Not quite!
>
>$ cat rat.c
>#include <stdio.h>
>int* one () {return &(1);}
>int* two () {return &(2);}
>
>void main (int argc, char** argv) {
>    int* one_ptr = one (); int* two_ptr = two ();
>    printf ("one = %d\n", *one_ptr);
>    one_ptr = one ();
>    printf ("two = %d\n", *two_ptr);
>}
>
>$ ./rat
>one = 2
>two = 1
>
>
>One C compiler I used issued a warning, the other didn't.
>

First, a compiler bug has nothing to do with the language.
bugs are bugs.

(what are you trying to do to return an address of a number any way?

second, your example will not even compile under gcc 2.8 nor under egcs 1.0.3

$cat t10.cpp
#include <stdio.h>
int* one () {return &(1);}
int* two () {return &(2);}

void main (int argc, char** argv) {
    int* one_ptr = one (); int* two_ptr = two ();
    printf ("one = %d\n", *one_ptr);
    one_ptr = one ();
    printf ("two = %d\n", *two_ptr);
}

 
$g++ -Wall t10.cpp
t10.cpp: In function `int * one()':
t10.cpp:2: non-lvalue in unary `&'
t10.cpp:2: warning: control reaches end of non-void function `one()'
t10.cpp: In function `int * two()':
t10.cpp:3: non-lvalue in unary `&'
t10.cpp:3: warning: control reaches end of non-void function `two()'
t10.cpp: At top level:
t10.cpp:5: warning: return type for `main' changed to `int'

Third, you should always use a good C++ compiler, and compile with warning
turned on.
 
Fourth, your example is a C program, not a C++.

>You might think this is a ridiculous example, but I have
>torn my hair out trying to find bugs as stupid as this code.
>I can't think how I could possibly code this in Ada.
>

it is possible to write ridiculous bad code in any language.

>Then there's the write off the end of the array trick ...
>
 
again, using C++ standard library, it provides you with data structures
ready to use so you dont have to build your own eveytime and make
begineer errors. so use those.

anyone nowadays still doing such silly errors as falling of the end
of an array because they dont use standard STL containers, do not deserve
to be programming in any language.

The proper use of C++ with its standard library makes it very safe system
to develop with.


mike

Re: Ada vs C++ vs Java

[Geoff Bull]

mike wrote:
> 
> In article <36BAF083.6C413B3D@acenet.com.au>, Geoff says...
> >
> 
> >
> >mike wrote:
> >
> >> C++ now, after becoming a standard, and with the standard library is a
> >> very safe language.
> >
> 

> >Then there's the write off the end of the array trick ...
> >
> 
> again, using C++ standard library, it provides you with data structures
> ready to use so you dont have to build your own eveytime and make
> begineer errors. so use those.
> 
> anyone nowadays still doing such silly errors as falling of the end
> of an array because they dont use standard STL containers, do not deserve
> to be programming in any language.

Are you saying that when I want an array of objects
that I should use an STL abstraction rather than the languages
built in array type??

This is ridiculous!

Re: Ada vs C++ vs Java

[Stanley Friesen [Contractor]]

In article <36BECC3E.E5D1723F@acenet.com.au>,
Geoff Bull  <gbull@acenet.com.au> wrote:
>
>Are you saying that when I want an array of objects
>that I should use an STL abstraction rather than the languages
>built in array type??
>
>This is ridiculous!

Think of vector<> as the built-in array type, and the type declared with '[]'
as an obsolescent feature retained purely for backwards compatibility.

That is much closer to the truth.

Re: Ada vs C++ vs Java

[mike]

In article <36BECC3E.E5D1723F@acenet.com.au>, Geoff says...
>
 
>> 
>> anyone nowadays still doing such silly errors as falling of the end
>> of an array because they dont use standard STL containers, do not deserve
>> to be programming in any language.
>
>Are you saying that when I want an array of objects
>that I should use an STL abstraction rather than the languages
>built in array type??
>

Yes. offcourse.

Just like only a fool (or a bignner) would use a null terminated char 
array to hold a string, when the C++ standard library comes with a 
build-in string class for doing that.

>This is ridiculous!

It is not. You are given a safe, tested, and higher level and easier to 
use containers such as a vector or string, so use them. if you insist 
on using more primitive data types (which using could result in more 
user errors), then you got only yourself to blame.

C++ standard library provides one with tools to use the langauge in safe
manner. get used to using it.

Mike.

Re: Ada vs C++ vs Java

[Geoff Bull]

mike wrote:
> 
> In article <36BECC3E.E5D1723F@acenet.com.au>, Geoff says...
> >
> 
> >>
> >> anyone nowadays still doing such silly errors as falling of the end
> >> of an array because they dont use standard STL containers, do not deserve
> >> to be programming in any language.

I better look for another career :-(

> >
> >Are you saying that when I want an array of objects
> >that I should use an STL abstraction rather than the languages
> >built in array type??
> >
> 
> Yes. offcourse.
> 
> Just like only a fool (or a bignner) would use a null terminated char
> array to hold a string, when the C++ standard library comes with a
> build-in string class for doing that.

Only a fool (or a bignner) would use C++ for a large application 
where safety and long term maintenace are major issues.

> 
> >This is ridiculous!
> 
> It is not. You are given a safe, tested, and higher level and easier to

Is so.

> use containers such as a vector or string, so use them. if you insist
> on using more primitive data types (which using could result in more
> user errors), then you got only yourself to blame.
> 
> C++ standard library provides one with tools to use the langauge in safe
> manner. get used to using it.
>

If you want to call C++ a safe language you need a means to able
to have a means of having the compiler reject all thos unsafe
arrays, pointers, casts, unions, varargs, implicit type conversion,
and anything that is likely to cause major surprises.

Re: Ada vs C++ vs Java

[P.S. Norby]

mike wrote:
> 

> Yes. offcourse.
> 

Is this "of course" or "off course"?  ( I vote for "off course"!)

> Just like only a fool (or a bignner) would ...

What the &^%$&^%$&^%$ is a "bignner"


Yeah, yeah, yeah, I know: you type more carefully when you code.  That's
what they all say.  

-- 
P.S. Norby

"No excuses.  No embarrassment.  No apologies...
 Ada -- the most trusted and powerful programming language
 on earth, or in space." -- S. Tucker Taft
 
\\\    \\\    \\\    \\\    \\\    \\\    \\\    \\\    \\\ 
( :)   ( :)   ( :)   ( :)   ( :)   ( :)   ( :)   ( :)   ( :)
///    ///    ///    ///    ///    ///    ///    ///    /// 
(Speaking only for myself)

Re: Ada vs C++ vs Java

[Brian Rogoff]

I've axed all newsgroups but comp.lang.ada, since I don't crosspost
anymore, and my response is Ada-centric...

On 4 Feb 1999, mike wrote:
> In article <79ce4s$lfq$1@nnrp1.dejanews.com>, mll@xmission.com says...
> >
> >HERE HERE, I've been writing C for 17 years, C++ for 7 and Ada for 7 and
> >would select Ada over the other 2 anytime (there may be SOME?? applications
> >which would be better written in C). 

I like Ada better too.

> C++, with the standard library is as reliable as Ada, with the addition
> that it is more terse.

More terse, arguably true, more reliable, in my experience quite false. 

> Look at this code below posted here recently by another poster. This code
> sorts a list of names inputed from stdin, look how clear, short, 
> elegent, and easy to read it is. 
           ^^^^^^^^^^^^^^^^^^^^^^
This is the point which I've made before with respect to automatic
instantiation, which is a matter of debate. I agree with Mike here, that
the absence of lots of instantiations is a boon to *readability* here, and 
the large numbers of instantiations that a similar generic library in Ada 
appear as so much noise (like the "_Type" in type names for some people ;-) 
which makes code much worse to read. Matthew Heaney points out that Ada 
provides a tiny bit of help by allowing you to omit some parameters, but
the key bit of help C++ provides is the automatic instantiation.

> try to do the same in Ada (actually Ada does not even have a standard
> generic library that comes with the compiler as C++ does), and you might 
> end up with pages of long code that is hard to read. 

Well, your argument is weak here. The advantage of C++ is not even that it 
comes with such a library, but that using the library doesn't incur the 
excessive wordiness cost. An Ada STL will still be less concise than a 
C++ one, and less readable in this regard. OTOH, Ada generics are far more 
safe than C++ templates, as type constraints are built into Ada generics. 
C++ templates support unconstrained parametric polymorphism, as opposed to
Ada's support for constrained pp. 

> I dont think Ada is more read'able. I think wordy languages for me 
> are harder to read. too much words makes thing less hard to understand. 

This doesn't parse. I know what you're trying to say, but your final
sentence above says the opposite!

I think that readability involves trade-offs. There is a "sweet spot"
in the concise vs verbose space that neither Ada nor C++ optimizes,
though IMO Ada is *far*, *far*, closer. But, a little automatic
instantiation would move it closer still!

> Ada offcourse is a fine langauage. but I feel C++ is more expressive
> and concise. and in the practical world, it is easier to use than Ada.

C++ cannot express concurrency, so how is it more expressive? If anything,
I can express much more in Ada than in C++!

> C++ now, after becoming a standard, and with the standard library is a 
> very safe language.

No, sorry, Tucker Taft had it right. With hard work, you can make write
relatively safe C++, but the defaults are all unsafe. With a bit of
effort, you can write unsafe Ada, but the defaults are safe. I prefer the 
Ada way.

I think what many Ada proponents missed in this post was that this example 
demonstrates how automatic instantiation can lead to short and *readable* 
code sections. 

-- Brian

> #include <iostream>
> #include <vector>
> #include <string>
> #include <algorithm>
> 
> int main()
> {
>         cout << "Please enter a list of words to be sorted: ";
> 
>         vector<string> v;
>         string buffer;
>         while (cin>>buffer && buffer!="END") v.push_back(buffer);
>         
>         sort(v.begin(),v.end());
> 
>         for (vector<string>::iterator i = v.begin(); i!=v.end(); ++i)
>                 cout << *i << endl;
> 
>         return 0;
> }
> 
> mike
> 
> 

Re: Ada vs C++ vs Java

[mike]

In article <Pine.BSF.4.05.9902061051480.21338-100000@shell5.ba.best.com>, Brian
says...
 

>
>> I dont think Ada is more read'able. I think wordy languages for me 
>> are harder to read. too much words makes thing less hard to understand. 
>

>This doesn't parse. I know what you're trying to say, but your final
>sentence above says the opposite!
>

I guess what I meant to say is that to express something in Ada requires
too many words. At least more than in C++. specially for the more advanced
constructs.

I find that it is easier to read and understand anything when things 
are shorter, requiring less words, and more terse. 
 

If you read a book on mathematics that was written say 400 years ago, and
translate that using today's language of mathematics, you'll find the
book shrink to more than half its size, becuase modern mathematics
language uses more terse expressions and symbols to represent the 
same things that used to take pages to represent, and it is far 
easier to understand too.

This is what I mean. I dont think langauges with more bigger words makes them
easier to read as the claim always be made for Ada. 

  
>
>C++ cannot express concurrency, so how is it more expressive? If anything,
>I can express much more in Ada than in C++!
>

OK. C++ does not have threads. So, I use pthreads library. it is no
big deal for me. (plus threads/tasks are oversold, they are only suitable
in limited applications. Even the Apache web server does not use them).
 
>> C++ now, after becoming a standard, and with the standard library is a 
>> very safe language.
>

>No, sorry, Tucker Taft had it right. With hard work, you can make write
>relatively safe C++, but the defaults are all unsafe. With a bit of
>effort, you can write unsafe Ada, but the defaults are safe. I prefer the 
>Ada way.
>

Yes, I understand this. But Tucker and youself agree that using the standard
C++ library makes C++ applications safe( safer?).

So, then it becomes a matter of each group requiring that every programmer
on the project must use C++ standard library classes and containers. problem
fixed :) no more array out of bounds problems, no more of the silly errors
encountered before. when I program in C++ now, I only use standard library
things. I finish faster, less bugs than before, and I feel my code is more
robust now. 

>I think what many Ada proponents missed in this post was that this example 
>demonstrates how automatic instantiation can lead to short and *readable* 
>code sections. 
>

So far, no one has been able to come up with an Ada example to do the
same as below using the only STANDARD Ada library and even with twice as
much code as shown below. The famouse Robert Dewar complained that this 
is a silly example. But where is the Ada example to do the same? If 
this was such a silly example, then it would have been trivial to 
write one that does the same in Ada95. 

The only reason no one has been able to do it is that it would require 
pages and pages on Ada code to write something that does the same as 
those 8 lines of C++ code below.
 
>
>> #include <iostream>
>> #include <vector>
>> #include <string>
>> #include <algorithm>
>> 
>> int main()
>> {
>>         cout << "Please enter a list of words to be sorted: ";
>> 
>>         vector<string> v;
>>         string buffer;
>>         while (cin>>buffer && buffer!="END") v.push_back(buffer);
>>         
>>         sort(v.begin(),v.end());
>> 
>>         for (vector<string>::iterator i = v.begin(); i!=v.end(); ++i)
>>                 cout << *i << endl;
>> 
>>         return 0;
>> }
>> 
 

mike

Re: Ada vs C++ vs Java

[Brian Rogoff]

On 8 Feb 1999, mike wrote:
> I guess what I meant to say is that to express something in Ada requires
> too many words. At least more than in C++. specially for the more advanced
> constructs.
> 
> I find that it is easier to read and understand anything when things 
> are shorter, requiring less words, and more terse. 
>
> ... snip ...
> 
> This is what I mean. I dont think langauges with more bigger words makes them
> easier to read as the claim always be made for Ada. 

Then you should really like APL, J, K, and similar languages, which aim
for maximal code compression. I can also write your example in Perl or
Icon, and it will also be shorter than the C++. 

> >> C++ now, after becoming a standard, and with the standard library is a 
> >> very safe language.
> >
> 
> >No, sorry, Tucker Taft had it right. With hard work, you can make write
> >relatively safe C++, but the defaults are all unsafe. With a bit of
> >effort, you can write unsafe Ada, but the defaults are safe. I prefer the 
> >Ada way.
> >
> 
> Yes, I understand this. But Tucker and youself agree that using the standard
> C++ library makes C++ applications safe( safer?).

I can't speak for Tucker, but I don't agree. You'd have to add many
qualifications to that sentence first.

> >I think what many Ada proponents missed in this post was that this example 
> >demonstrates how automatic instantiation can lead to short and *readable* 
> >code sections. 
> >
> 
> So far, no one has been able to come up with an Ada example to do the
> same as below using the only STANDARD Ada library and even with twice as
> much code as shown below. 

You can't write an Ada tasking program in the STANDARD C++ library at all. 
I have my own set of component libraries which enable me to write Ada code 
only slightly longer than what you wrote. Others also have their own
components. It will be a while before Ada has a standard component
library, but there will be "de-facto" standards soon.

> The famouse Robert Dewar complained that this 
> is a silly example. 

He was correct in reading your mind and guessing what you meant. It is a
really silly example, if you're just complaining about the lack of a
standard collection library. I thought you were commenting on how C++ 
automatic instantiation resulted in more readable code (projection I 
suppose :-), in which case it wouldn't have been so silly. 

> But where is the Ada example to do the same? 

If you let me use my own libraries, or someone else's, it won't be too
much longer than the C++, certainly not pages of code.

-- Brian

Re: Ada vs C++ vs Java

[Geoff Bull]

Brian Rogoff wrote:
> 

>  I thought you were commenting on how C++
> automatic instantiation resulted in more readable code (projection I
> suppose :-), in which case it wouldn't have been so silly.
> 

Is automatic instantiation safe?
I.e. can you be surprised by what actually gets instantiated?

Re: Ada vs C++ vs Java

[Brian Rogoff]

On Tue, 9 Feb 1999, Geoff Bull wrote:
> Brian Rogoff wrote:
> > 
> 
> >  I thought you were commenting on how C++
> > automatic instantiation resulted in more readable code (projection I
> > suppose :-), in which case it wouldn't have been so silly.
> > 
> 
> Is automatic instantiation safe?
> I.e. can you be surprised by what actually gets instantiated?

That's a question that probably needs lots of actual experimentation to 
answer, but the only written study I know of on the subject in the Ada 
context (ACM Tri-Ada 91 p 338-346) suggests that the answer is no, and
provides some examples which show enhanced readability of some code
sections with automatic instantiation. 

Unfortunately I don't think the preprocessor the authors used is available 
for modification. 

-- Brian

Re: Ada vs C++ vs Java

[robert_dewar]

In article <79mn6h$bls@drn.newsguy.com>,
  mike <mike@newsguy.com> wrote:
> I find that it is easier to read and understand anything
> when things  are shorter, requiring less words, and more
> terse.

So you must find C++ an abomination compared to APL!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[dennison]

In article <79mn6h$bls@drn.newsguy.com>,
  mike <mike@newsguy.com> wrote:

> The only reason no one has been able to do it is that it would require
> pages and pages on Ada code to write something that does the same as
> those 8 lines of C++ code below.

Your case would be much stronger if you used the "," operator to compress the
entire procedure into only 1 line of code. Ada could never match that! And
code that terse *has* to be more readable, right?

:-)


T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Geoff Bull]

mike wrote:
> 
> In article <Pine.BSF.4.05.9902061051480.21338-100000@shell5.ba.best.com>, Brian
> says...
> 
> 
> >
> >> I dont think Ada is more read'able. I think wordy languages for me
> >> are harder to read. too much words makes thing less hard to understand.
> >
> 
> >This doesn't parse. I know what you're trying to say, but your final
> >sentence above says the opposite!
> >
> 
> I guess what I meant to say is that to express something in Ada requires
> too many words. At least more than in C++. specially for the more advanced
> constructs.
> 
> I find that it is easier to read and understand anything when things
> are shorter, requiring less words, and more terse.

Great! somebody posted the following here a while ago.
What's it do?
I suppose I could figure it out if I added a bit of formatting 
and a few comments (yeah I know, I shouldn't be programming if
the below isn't immediately obvious ..., and it isn't quite c++)
Do you love reading pages and pages of this stuff?

==================================================================
#include <io.h>
float o=0.075,h=1.5,T,r,O,l,I;int _,L=80,s=3200;main(){for(;s%L||
(h-=o,T= -2),s;4 -(r=O*O)<(l=I*I)|++ _==L&&write(1,(--s%L?_<L?--_
%6:6:7)+"World! \n",1)&&(O=I=l=_=r=0,T+=o /2))O=I*2*O+h,I=l+T-r;}
==================================================================

 

> So, then it becomes a matter of each group requiring that every programmer
> on the project must use C++ standard library classes and containers. problem
> fixed :) 

How do you enforce this - does C++ have a pragma Restrictions?
Or do you rely on code reviews?
Maybe you just don't employ beginners and fools
(unfortuneately most of us have the occasional bad day).

Geoff

Re: Ada vs C++ vs Java

[Ell]

Mike Coffin <mhc@Eng.Sun.COM> wrote:

#Matthew Heaney <matthew_heaney@acm.org> writes:
#> This is throwing the baby out with the bath-water.  Ada95 and C++ are
#> both static languages, just like C.  It is no more difficult to
#> statically determine storage requirements using those higher-level
#> languages than it is for C.
#> 
#> In this day and age, there is very little reason to continue using C.
#
# Scene: the water cooler in a good sized company.
# Dramatis personae: manager and programmer.
#
# The curtain rises...
#
# manager: You should use C++ or Ada.  They're higher level than C.
#
# programmer: But I hate them.
#
# manager: But they're higher level!  
#
# programmer: Yeah, right.  When it first appeared, Ada was the
#         laughingstock of programmers everywhere for its insane
#         complexity and C++ has managed to outdo it.
#
# manager: But you'll be more productive! Your types will be checked!
#         Your templates will be expanded!  
#
# programmer: Then let me use Eiffel, or ML, or Scheme, or Haskell, or, 
#        or... Those are even higher level. I'll be even more productive.
#
# manager: But everyone knows that the language doesn't matter!
#         Bad programmers can write bad code in any language!  It's the
#         quality of the engineer, not the language, that determines
#         the quality of the code.

Seeming flaw in dialog:  manager should still argue that language makes a
difference here, maybe not the whole difference, but language choice(s) is
still a factor that makes a difference in the whole equation.  Given the
overall project resources and goals, perhaps the manager might say Eiffel, or
ML, or Scheme, or Haskell are too high level or there is not enough tool or
personnel support associated with them.

# programmer: So let me use C.
#
# manager:  But, but, but, but ... it's too low level!  Try C++ or
#         Ada!  You'll like it!

As above one needs to balance all project needs.  It is possible to be at
either too high or low a level.  Because one argues against going too far in
one direction does not mean that we are justified in going too in the other
direction.

# programmer: I used them for years.  I hate them.  I got into this
#         business because I like elegance, not baling wire and duct
#         tape.  If I had wanted to roll around in the muck I'd have
#         been a pig farmer.  Ada gives me a headache; C++ gives me a
#         headache *AND* ulcers.
#
# manager: Well, I'm making an executive decision.  Use C++.  I know
#         you don't like it now, but you'll get over it.  
#
# programmer:  Yup, I will.  I quit.  There: I'm over it.
#
# Happy ending:
#
#         The project was abandoned after running 2 years late and
#         ballooning from 3 programmers to 20.  The code never did
#         anything useful, but the types were all checked and the
#         templates were all expanded.  The manager was promoted.
#
#         The programmer is now writing Java for an internet startup
#         and has stock options worth $3.6 million.  He has an
#         occasional mild headache but no ulcers.

Glad the programmer found a happy ending.

Elliott

#
#-mike
#
#Obviously, not speaking for Sun Microsystems.

--
The Craftite conspiracy is:
 1) holding life terms as c.o.m. moderators  2) oligarchic selection of new moderators
 3) not banning "one ups-manship" on c.o.m.  4) moderator comments in c.o.m.
                  :=***=:  Objective  *  Holistic  *  Pre-code Modelling  :=***=:
                                   Hallmarks of the best SW Engineering
                 Study Craftite vs.full blown OO: http://www.access.digex.net/~ell
             Copyright 1999 Elliott. exclusive of others' writing. may be copied w/out
               permission only in the comp., phil., & sci. usenet and bitnet groups.

Re: Ada vs C++ vs Java

[Matthew Heaney]

Mike Coffin <mhc@Eng.Sun.COM> writes:

> Matthew Heaney <matthew_heaney@acm.org> writes:
> > This is throwing the baby out with the bath-water.  Ada95 and C++ are
> > both static languages, just like C.  It is no more difficult to
> > statically determine storage requirements using those higher-level
> > languages than it is for C.
> > 
> > In this day and age, there is very little reason to continue using C.
> 
>  Scene: the water cooler in a good sized company.
>  Dramatis personae: manager and programmer.
> 
>  The curtain rises...
> 
>  manager: You should use C++ or Ada.  They're higher level than C.
> 
>  programmer: But I hate them.
> 
>  manager: But they're higher level!  
> 
>  programmer: Yeah, right.  When it first appeared, Ada was the
>          laughingstock of programmers everywhere for its insane
>          complexity and C++ has managed to outdo it.
[rest of dialog snipped]

This response contains no substantive information.  If vague criticisms
like "Ada is complex" are the best you can do, then I must conclude that
you don't really know Ada.

If you'd like to learn Ada, then you can download gnat, a free,
high-quality Ada95 compiler that's part of the gcc family.

<http://www.gnat.com/>

There are also Ada95 tutorials at the Home of the Brave Ada Programmers.

<http://www.adahome.com/>

Re: Ada vs C++ vs Java

[Mike Coffin]

Matthew Heaney <matthew_heaney@acm.org> writes:

> This response contains no substantive information.  If vague criticisms
> like "Ada is complex" are the best you can do, then I must conclude that
> you don't really know Ada.

I guess I should have inserted smileys for the humor impaired.  
(Ada is very complex compared to a bowling ball, very simple compared
to a space shuttle.)

-mike

Re: Ada vs C++ vs Java

[Matthew Heaney]

Mike Coffin <mhc@Eng.Sun.COM> writes:

> Matthew Heaney <matthew_heaney@acm.org> writes:
> 
> > This response contains no substantive information.  If vague criticisms
> > like "Ada is complex" are the best you can do, then I must conclude that
> > you don't really know Ada.
> 
> I guess I should have inserted smileys for the humor impaired.  
> (Ada is very complex compared to a bowling ball, very simple compared
> to a space shuttle.)

I am interested in specifics.  List 5 specific language features by
which you conclude Ada is "complex."

If you are unable to list 5 (I'll settle for fewer) specific features
that you think make Ada a complex language, then you will have failed to
argue your case for the putative complexity of Ada.

It is customary in logic that the conclusion be preceded by premises.
I guess if your argument begins with the premise "True", then you can
make any conclusion you want!

Statisticians must prove the alternate hypothesis, scientists must show
how all the data is explained (better) by their theory, and lawyers must
prove guilt by a preponderance of evidence. 

I hold you to the same standard, and I will not accept vague criticisms
like "Ada is complex," without specific, substantive reasons for this
assessment.


Here's a little story, often ascribed to Abe Lincoln:

Abe: Suppose you call a tail a leg.  How many legs does a dog have?

Student: Five.

Abe: Wrong.  The answer is four.  Calling a tail a leg, doesn't make it
a leg.

Moral: Just because you say Ada is complex doesn't make it so!  

-- 
Those who believe in the supernatural should be required to learn
computer programming.  This would force them to discover that things
which appear at first to be completely mysterious and incomprehensible,
in fact have a logical (and usually simple) explanation.  --J.B.R. Yant

Re: Ada vs C++ vs Java

[Mike Coffin]

Matthew Heaney <matthew_heaney@acm.org> writes:

> I am interested in specifics.  List 5 specific language features by
> which you conclude Ada is "complex."

I'll have to answer based on Classic Ada; I haven't had occasion to
look seriously at the latest version.

Here are some broad areas that I think are way too complicated:

1. Generics.  Ada generics are much more complicated and harder to use
   than need be.  If you insist on complete run-time type checking,
   ML's type system is easier to use and more powerful.  (I don't
   blame Ada for this: Hindley-Milner-style type systems probably
   didn't exist and certainly weren't widely known.)  I know that
   there were some efforts to get some type-inference technology into
   Ada Mark II or whatever it's called, but I don't know if any
   succeeded. 

   On the other hand, if you're of the opinion that exceptions do
   happen, and that type exceptions are just another kind of
   exception, OO type systems such as Java and Smalltalk are a *lot*
   simpler than Ada's.

2. Rendezvous.  Compare accept/select/when, with all their
   permutations and ramifications, with SR's "in" statement which is
   much more powerful.  (This is chiefly because "when" clauses can't
   reference entry parameters in Ada).  In fact, compare all of Ada's
   interprocess communication with SR's.  SR's is much more powerful
   and easier to use.  (But I'm biased; I worked on SR back when the
   world was new :-)

3. Treatment of variables shared between tasks.  Task A changes a
   variable.  When does task B see the change?  Trying to maintain too
   much generality made Ada much more complicated than any language I
   can think of in this regard.  It's not so much that the language
   rules are complex, it's that writing programs that work reasonably
   given then weak language rules is so hard.  Anyone know of another
   language that tries to conflate shared-memory and distributed
   programming?

4. Parameter passing.  Three modes; named parameters; default values
   (but not for in-out parameters, for some reason).  In spite of all
   the features, the behavior is mostly unspecified for arrays and
   records.  Compare with rules of C, Java, or almost any other
   language: they lack *all* these nifty features and seem to get
   along fine.  C++ of course being the exception.
  
5. Overloading.  Do result types matter?  Do parameter names matter?
   Do default values matter?  Why, or why not?  And, hey:
   parameterless subroutines and enumeration literals look sort of the
   same.  Can they overload each other?  Can they hide each other?  If
   so, when and where?  It could be worse though, as C++ demonstrates.

Next time I make a joke I'll make it about something that people don't 
take so damn seriously.  Death, famine, or nuclear winter maybe. :-)

-mike   

Re: Ada vs C++ vs Java

[adam]

In article <8p6yan1xger.fsf@Eng.Sun.COM>,
  Mike Coffin <mhc@Eng.Sun.COM> wrote:

>
>   Matthew Heaney <matthew_heaney@acm.org> writes:
>
>   > I am interested in specifics.  List 5 specific language features by
>   > which you conclude Ada is "complex."
>
>   I'll have to answer based on Classic Ada; I haven't had occasion to
>   look seriously at the latest version.
>
>   Here are some broad areas that I think are way too complicated:
>
>   1. Generics.  Ada generics are much more complicated and harder to use
>      than need be.

So don't use them.

>      If you insist on complete run-time type checking,
>      ML's type system is easier to use and more powerful.  (I don't
>      blame Ada for this: Hindley-Milner-style type systems probably
>      didn't exist and certainly weren't widely known.)  I know that
>      there were some efforts to get some type-inference technology into
>      Ada Mark II or whatever it's called, but I don't know if any
>      succeeded.
>
>      On the other hand, if you're of the opinion that exceptions do
>      happen, and that type exceptions are just another kind of
>      exception, OO type systems such as Java and Smalltalk are a *lot*
>      simpler than Ada's.

I don't know enough about ML's type system to comment.  However, I've
never thought of Ada's type checking system as complicated.  You have
types, and for each type you can have subtypes.  When you move stuff
from one variable to another, or from an expression to a parameter, or
whatever, the types have to match.  That's the basic idea.  How hard
is that to understand?  It does get a bit more complicated when Ada
95's tagged types and class-wide types are involved.

>   2. Rendezvous.  Compare accept/select/when, with all their
>      permutations and ramifications, with SR's "in" statement which is
>      much more powerful.  (This is chiefly because "when" clauses can't
>      reference entry parameters in Ada).  In fact, compare all of Ada's
>      interprocess communication with SR's.  SR's is much more powerful
>      and easier to use.  (But I'm biased; I worked on SR back when the
>      world was new :-)

So don't use rendezvous.  (I don't know anything about SR, but your
fictional programmer never mentioned this; he was trying to argue for
using C.)

>   3. Treatment of variables shared between tasks.  Task A changes a
>      variable.  When does task B see the change?  Trying to maintain too
>      much generality made Ada much more complicated than any language I
>      can think of in this regard.  It's not so much that the language
>      rules are complex, it's that writing programs that work reasonably
>      given then weak language rules is so hard.  Anyone know of another
>      language that tries to conflate shared-memory and distributed
>      programming?

So don't use tasks.

>   4. Parameter passing.  Three modes; named parameters; default values
>      (but not for in-out parameters, for some reason).

If you say "for some reason", then you really haven't grasped what the
in-out parameter mode is for.  It's for passing a variable that the
procedure is supposed to modify.  A default value would make no sense.

>      In spite of all
>      the features, the behavior is mostly unspecified for arrays and
>      records.

I fail to see how this is "complicated".  It's really simple.  An "in"
parameter is one that goes IN to the procedure.  The procedure uses it
as INput, not as OUTput.  An "out" parameter is one that the procedure
uses as OUTput; it's not used as INput and should not use whatever
value the parameter has when the procedure starts.  An "in out"
parameter is both INput and OUTput.  The procedure takes its current
value as INput, but may modify the value, i.e. OUTput.  How is this
complicated?  I'm sure my 16-month-old could understand it.  (Well,
that's an exaggeration, but he's very good at taking everything out of
a box and putting it back in, and the concept behind Ada parameter
passing isn't much more difficult that that.)  Meanwhile, in C, if you
declare a parameter type to be a pointer, you can't tell whether the
procedure actually wants to input a pointer, or whether it wants to
input the address of an array, or whether it's trying to emulate Ada's
"in out" parameter.  Is Ada really more complex here?  Which one is
harder to learn, harder to use, harder to read?

As far as being unspecified for arrays and records, that's just not
true.  It works just the same as scalars.  If you have an IN OUT
record or array parameter, the variable used by the caller has its
value passed to the procedure, and the procedure gives the variable a
new value.  Same as for anything else.  What's unspecified is that you
don't know whether the variable gets its new value at the end of the
procedure or at some time before that, but usually that doesn't
matter.  In fact, that's a good feature, because it has allowed
compilers that will pass *small* records and arrays in registers and
lets the procedure work with them efficiently in registers, while in
some languages, your only option is to pass the address of the record
or array and force the procedure to make indirect registers through
that address.  I know, you probably think the only computer around is
the register-challenged Intel 80x86/Pentium, in which this isn't an
issue because there aren't enough registers for passing parameters.

As for default values: So don't use them.

>      Compare with rules of C, Java, or almost any other
>      language: they lack *all* these nifty features and seem to get
>      along fine.

So does assembly language, for that matter.

>   5. Overloading.  Do result types matter?  Do parameter names matter?
>      Do default values matter?  Why, or why not?  And, hey:
>      parameterless subroutines and enumeration literals look sort of the
>      same.  Can they overload each other?  Can they hide each other?  If
>      so, when and where?  It could be worse though, as C++ demonstrates.

So don't use this feature.

Out of the five things you think are "way too complicated", four and a
half of them are things that you don't need to use to program in Ada.
I mean, if your complaint is that "Something I can do easily in C [the
language your fictional programmer wanted to use] is complicated to do
in Ada", you might have a valid argument.  But all these examples are
more of the form "Something is complicated in Ada that C doesn't
support at all."  So how is Ada's "complexity" a negative?  OK, so
tasks might be complex, but if you have a program that doesn't need
them, so what?  And if you have a program that does require this kind
of concept, is it "less complex" to do it in C, where you'd have to
write all the synchronization and task-switching and time-slicing
routines yourself?  Maybe "overloading" seems complex (although I
don't see why), but C doesn't have it at all, so you have to come up
with distinct names for everything---so why can't you just do the same
thing in Ada?  Ada does not put a gun to your head and say you must
understand and use overloading.  It's a nice feature if you want to
use it, but if you don't, don't---why would that be a point against
using the language?

I recently bought Quicken Deluxe 99.  There are a lot of options on
there that I don't understand at all, and I'd have to do a fair amount
of reading to see if I wanted to use them and then to use them
effectively.  So what?  Does this mean I'm supposed to return the
program to the store?  The program does the things I need to do all
the time nicely, and I like it; and as for the other features, maybe
if I have time I'll look into it, but I don't need to know anything
about them in order to use the rest of the program.  Ada is pretty
much the same way, and I just can't understand why this "too complex"
argument is used so often as a reason not to use Ada (particularly by
people who want to use C).  It seems silly.


>   Next time I make a joke I'll make it about something that people don't
>   take so damn seriously.  Death, famine, or nuclear winter maybe. :-)

No, next time you make a joke that's not intended to make a point,
write it in such a way so that it looks like it's not intended to make
a point.  Sometimes humor is just to make people laugh, but sometimes
it's a good form for expressing an opinion.  Since several people
(including myself) have assumed you were attempting the latter, I'd
say that the fault lies in your writing style, not in our being
humor-impaired.  And if you were really trying to make a point, then
expect your point to be criticized.

                                -- Adam

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[kevin]

 
>
>In article <8p6yan1xger.fsf@Eng.Sun.COM>,
>  Mike Coffin <mhc@Eng.Sun.COM> wrote:
>

(on parameter passing)
 
>
>>      Compare with rules of C, Java, or almost any other
>>      language: they lack *all* these nifty features and seem to get
>>      along fine.
>

Ok, this is a little test in Java:

write a procedure in java that takes 2 formal parameters of
type integer, and on return the first parameter will have the value 
of the second parameter, and the second parameter will have the value 
of the first parameter before the call. 

i.e. it swaps the parameters around.

guess what. it is impossible to do this trivial thing in Java.

so much for the java power where one can not write trivial procedure
like the above using primitive data typekevin
 

Re: Ada vs C++ vs Java

[Michael J. Tobler]

In article <78107o$ovt@drn.newsguy.com>, kevin@nospam.com.net says...
[snip]
> Ok, this is a little test in Java:
> 
> write a procedure in java that takes 2 formal parameters of
> type integer, and on return the first parameter will have the value 
> of the second parameter, and the second parameter will have the value 
> of the first parameter before the call. 
> 
> i.e. it swaps the parameters around.

Are you stating that the client variables passed as arguments to the 
member function (not a procedure) should have their values swapped? That's 
understandable because Java is pass-by-value with native types. There are 
ways to do it, if you know how to use the language.

> so much for the java power where one can not write trivial procedure
> like the above using primitive data type

Each language has its strengths and weaknesses - use the language that is 
appropriate.

-- 
<<<<<<<<<<<<<<<<  Blue Skies  >>>>>>>>>>>>>>>>
< Michael J. Tobler: mtobler@no-spam-ibm.net >
<   **remove "no-spam-" when replying**      >
<     http://www.webbrew.com/toblermj        >
< MJTobler:Instant Messenger;  28038932:ICQ  >
<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>

Re: Ada vs C++ vs Java

[Mike Coffin]

adam@irvine.com writes, in part:

> Out of the five things you think are "way too complicated", four and a
> half of them are things that you don't need to use to program in Ada.

I didn't say there wasn't a simple subset of Ada.  That would be
stupid; there is a simple subset of any programming language.  I said
Ada was complicated.  You challenged me for some examples; I gave them 
to you.

> I mean, if your complaint is that "Something I can do easily in C [the
> language your fictional programmer wanted to use] is complicated to do
> in Ada", you might have a valid argument.  But all these examples are
> more of the form "Something is complicated in Ada that C doesn't
> support at all."  So how is Ada's "complexity" a negative?  OK, so
> tasks might be complex, but if you have a program that doesn't need
> them, so what?  And if you have a program that does require this kind
> of concept, is it "less complex" to do it in C, where you'd have to
> write all the synchronization and task-switching and time-slicing
> routines yourself?  Maybe "overloading" seems complex (although I
> don't see why), but C doesn't have it at all, so you have to come up
> with distinct names for everything---so why can't you just do the same
> thing in Ada?  Ada does not put a gun to your head and say you must
> understand and use overloading.  It's a nice feature if you want to
> use it, but if you don't, don't---why would that be a point against
> using the language?

This might be a valid argument if I wrote all programs from scratch,
never inherited a program or library from someone else, never had to
debug another's program, and never had to work in a team.  I don't
have that luxury.  If my team uses Ada, I *have to* understand
overloading and tasking. 

-mike

Re: Ada vs C++ vs Java

[Larry Kilgallen]

In article <8p6emoqzt10.fsf@Eng.Sun.COM>, Mike Coffin <mhc@Eng.Sun.COM> writes:
> adam@irvine.com writes, in part:


>> I mean, if your complaint is that "Something I can do easily in C [the
>> language your fictional programmer wanted to use] is complicated to do
>> in Ada", you might have a valid argument.  But all these examples are
>> more of the form "Something is complicated in Ada that C doesn't
>> support at all."  So how is Ada's "complexity" a negative?  OK, so
>> tasks might be complex, but if you have a program that doesn't need
>> them, so what?  And if you have a program that does require this kind
>> of concept, is it "less complex" to do it in C, where you'd have to
>> write all the synchronization and task-switching and time-slicing
>> routines yourself?  Maybe "overloading" seems complex (although I
>> don't see why), but C doesn't have it at all, so you have to come up
>> with distinct names for everything---so why can't you just do the same
>> thing in Ada?  Ada does not put a gun to your head and say you must
>> understand and use overloading.  It's a nice feature if you want to
>> use it, but if you don't, don't---why would that be a point against
>> using the language?
> 
> This might be a valid argument if I wrote all programs from scratch,
> never inherited a program or library from someone else, never had to
> debug another's program, and never had to work in a team.  I don't
> have that luxury.  If my team uses Ada, I *have to* understand
> overloading and tasking. 

Competent programmers do not use exotic (viewed from the problem
domain) features that are not needed for the problem at hand.  If you
are maintaining a GUI calculator (looks like a pocket calculator on the
screen), you should be very skeptical if your predecessors or cohorts
chose to use Ada tasking.  If you are writing a general message switch,
on the other had, use of tasking is to be expected.

So what you encounter in code you did not write should not vary a lot
from the set of features you would have chosen if you wrote it all
yourself from scratch.

Larry Kilgallen

Re: Ada vs C++ vs Java

[adam]

In article <1999Jan20.142122.1@eisner>,
  Kilgallen@eisner.decus.org.nospam wrote:
> In article <8p6emoqzt10.fsf@Eng.Sun.COM>, Mike Coffin <mhc@Eng.Sun.COM>
writes:

> > This might be a valid argument if I wrote all programs from scratch,
> > never inherited a program or library from someone else, never had to
> > debug another's program, and never had to work in a team.  I don't
> > have that luxury.  If my team uses Ada, I *have to* understand
> > overloading and tasking.
>
> Competent programmers do not use exotic (viewed from the problem
> domain) features that are not needed for the problem at hand.  If you
> are maintaining a GUI calculator (looks like a pocket calculator on the
> screen), you should be very skeptical if your predecessors or cohorts
> chose to use Ada tasking.  If you are writing a general message switch,
> on the other had, use of tasking is to be expected.

> So what you encounter in code you did not write should not vary a lot
> from the set of features you would have chosen if you wrote it all
> yourself from scratch.

Good point.  To further this point: Say you had to work on a team that
had written a general message switch.  If they had written the program
in Ada, you'd have to learn tasking.  But if they had written it in C,
what would they have used to implement the same stuff that tasking
implements in Ada?  Somehow, they'd have to write code that
accomplished the same thing.  Would they use POSIX threads?  Well,
then you'd have to learn that.  I only know a little about the POSIX
threads library, but I know it has a lot of little subroutines.  (A
quick "man" on one operating system shows 53 routines, some of which
might be specific to that OS.)  So you'd have to learn about how that
whole library works, and the proper way to use those routines, and
what ways are improper and what might happen if you call a routine at
the wrong time or forget to call a needed routine or whatever.  (At
least in Ada, some of the things you can do wrong are flagged by the
compiler.)  Or did the team write its own library or macros for
handling the concurrent stuff?  Or, instead of a library, do they have
conventional ways of coding the spawning and synchronization and
whatever?  Well, then you'd have to learn the semantics of their
library routines or macros or conventions, which might be even harder
because their code will be poorly documented if they're typical C
programmers :-), and this knowledge won't be something you can take to
another job.  Plus, you won't be able to find any tutorials on the
'net that could help you.

The point is this: If you (Mike) think that joining an Ada shop means
you have to learn more complex stuff than if you joined a C shop,
you're wrong.  You'll still have to learn some complex stuff if the
team uses C.  True, the stuff you'll have to learn may not be in the
language definition; it's somewhere else.  So what?

                                -- Adam




-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Simon Wright]

adam@irvine.com writes:

>              To further this point: Say you had to work on a team that
> had written a general message switch.  If they had written the program
> in Ada, you'd have to learn tasking.

Hmm, no names no pack drill, but I can think of at least one case where
the threads were handled by C code imported to Ada ..

Re: Ada vs C++ vs Java

[Michael Rubenstein]

On Tue, 19 Jan 1999 03:04:39 GMT, adam@irvine.com wrote:

>So don't use them.
....
>So don't use rendezvous.  (I don't know anything about SR, but your
>fictional programmer never mentioned this; he was trying to argue for
>using C.)
....
>So don't use tasks.
....
>As for default values: So don't use them.
....
>So don't use this feature.

Theorem:  All programming languages are simple.

Proof:  Mathematical induction.  Consider a programming language with
0 features; obviously such a language  is simple.  Suppose we have
proven that all languages with n features are simple.  I claim that
all languages with n + 1 features are simple.  Let L be a language
with n + 1 features.  If L is simple, we are done.  If L is not
simple, don't use one of its features.  L is then equivalent to a
language with only n features and so is simple.

QED
--
Michael M Rubenstein

Re: Ada vs C++ vs Java

[robert_dewar]

In article <36aa02d2.27999741@nntp.ix.netcom.com>,
  miker3@ix.netcom.com (Michael Rubenstein) wrote:
> On Tue, 19 Jan 1999 03:04:39 GMT, adam@irvine.com wrote:
>
> >So don't use them.

<<bogus proof that all languages are simple snipped>>

This whole post is based on the entirely erroneous notion
that since you can omit features of the language they
don't count in considering complexity.

But from almost all points of view EXCEPT simplicity of
resulting programs which is only one of the dimensions
of complexity, unused features add to the complexity
of the language.

You might as well say it is easy to get around in London,
and that its street map is no more complex than Manhatten's
Simply ignore all the streets you don't need to get from
where you are now to where you want to go!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Lieven Marchand]

miker3@ix.netcom.com (Michael Rubenstein) writes:

> On Tue, 19 Jan 1999 03:04:39 GMT, adam@irvine.com wrote:
> 
> >So don't use them.
> ....
> >So don't use rendezvous.  (I don't know anything about SR, but your
> >fictional programmer never mentioned this; he was trying to argue for
> >using C.)
> ....
> >So don't use tasks.
> ....
> >As for default values: So don't use them.
> ....
> >So don't use this feature.
> 
> Theorem:  All programming languages are simple.
> 
> Proof:  Mathematical induction.  Consider a programming language with
> 0 features; obviously such a language  is simple.  Suppose we have
> proven that all languages with n features are simple.  I claim that
> all languages with n + 1 features are simple.  Let L be a language
> with n + 1 features.  If L is simple, we are done.  If L is not
> simple, don't use one of its features.  L is then equivalent to a
> language with only n features and so is simple.
> 

Not really. A useful measure of the simplicity of a language is rather 
whether what you don't know will hurt you or not. If you can ignore a
feature, it doesn't need to be counted in the complexity; otherwise it
does. 

When I first started studying Ada I found the fixed point types complex 
and I didn't see their utility. However, they can be ignored when you 
don't need them. In contrast, exceptions as a feature cannot be ignored
since many operations in the language can potentially generate exceptions
whether you want them to or not. Not that I find exceptions complex, 
especially compared to the mess they are in C++.

-- 
Lieven Marchand <mal@bewoner.dma.be> 
------------------------------------------------------------------------------
Few people have a talent for constructive laziness. -- Lazarus Long

Re: Ada vs C++ vs Java

[Matthew Heaney]

Mike Coffin <mhc@Eng.Sun.COM> writes:

> Matthew Heaney <matthew_heaney@acm.org> writes:
> 
> > I am interested in specifics.  List 5 specific language features by
> > which you conclude Ada is "complex."
> 
> I'll have to answer based on Classic Ada; I haven't had occasion to
> look seriously at the latest version.
> 
> Here are some broad areas that I think are way too complicated:
> 
> 1. Generics.  Ada generics are much more complicated and harder to use
>    than need be.

I'm not sure which aspects of generics you find "way to complicated."
Is it the declaration, or the instantiation?

Give some specific examples of generic syntax that you think are too
complex.  Or give an example of an abstraction that you wanted to turn
into a generic, but were unable to.

The other point is --something Robert Dewar brought up-- is what exactly
do we mean by "complex."  Do we mean language definition, compiler
implementation, work for the programmer, or complexity of the resulting
application written in that language?

Your original argument (made in jest, I know) was that because Ada was
too complex, that one should choose C as the implementation language,
because it is a significantly simpler language.

However, C offers no support (beyond preprocessor macros) for writing
abstractions that are independent of the specific type.  For example,
suppose I declare a struct, and then need to put those struct objects on
a stack or in a queue.  

Yes, I can write code to implement those abstractions for that specific
type.  But then what do I do for all the other structs that need to go
in a queue?  I probably have to re-write those abstractions, thus
duplicating code, or, write something that isn't type safe, thus
increasing the frequency of defects.

So even if we posit that Ada generics are "way too complicated," they
are better than the alternative offered by C (nothing).  Abstractions
written using generics means there'll be lots less code to maintain, and
that the code that is there will have far fewer errors.


>    On the other hand, if you're of the opinion that exceptions do
>    happen, and that type exceptions are just another kind of
>    exception, OO type systems such as Java and Smalltalk are a *lot*
>    simpler than Ada's.

I'm not sure what you're trying to say here.  What is a "type
exception"?

No, Ada is not a "pure" language in the Smalltalk sense.  But this is a
proud claim, not an embarrassed confession.  

The language gives you more tools to do the job, and doesn't force you
to wear a straight jacket as you do in a "pure" language.  The richness
of the type system is thus one of Ada's strengths.

(Aside on programming language purity vs consistency.)  Someone started
a rumor that "pure" is defined as "better," but I don't buy into this
argument at all.  Consistency is much more important.

I learned this when I started programming in Ada95.  As I was wending my
way around the new features of the language, I would sometimes guess
when I wasn't sure about syntax, and sure enough, the code would
compile!

The Ada95 designers understood the Ada83 way of thinking, and preserved
that.  The language really is upwardly compatible, right down to the
mind-set you have when you "think in the language."  

A tip of the hat to Tucker and the rest of the design team for a job
well done! (End of aside.)

 
> 2. Rendezvous.  Compare accept/select/when, with all their
>    permutations and ramifications, with SR's "in" statement which is
>    much more powerful.  (This is chiefly because "when" clauses can't
>    reference entry parameters in Ada).  In fact, compare all of Ada's
>    interprocess communication with SR's.  SR's is much more powerful
>    and easier to use.  (But I'm biased; I worked on SR back when the
>    world was new :-)

I'm unfamiliar with SR, so I can't make a comparison.  It's a language?
Is there a standard reference book, or perhaps a web-site describing the
language?  (The Ada tasking model is based in Tony Hoare's CSP.)

What programming problem do you have that was made difficult or
impossible because a guard (a "when clause") couldn't depend on the
value of an entry parameter?  

Maybe you could solve the problem in Ada95 by using a requeue statement,
which allows a called task to move a caller to another entry queue (say,
based on a value of an entry param).  You can also do a lot of slick
stuff using a protected type.
 
Ada and Java are the only mainstream languages that have built-in
support for currency.  Even if Ada's tasking features are too complex or
not powerful enough (a criticism that only applies to Ada83), it's still
better than the alternative offered by C and C++, which is nothing.  In
those languages, you have to leave the language and make OS calls, which
are easily more complex, and less portable.


> 3. Treatment of variables shared between tasks.  Task A changes a
>    variable.  When does task B see the change?  Trying to maintain too
>    much generality made Ada much more complicated than any language I
>    can think of in this regard.  It's not so much that the language
>    rules are complex, it's that writing programs that work reasonably
>    given then weak language rules is so hard.  Anyone know of another
>    language that tries to conflate shared-memory and distributed
>    programming?

The model for intertask communication in Ada83 is provided by the
rendezvous.  If you try to signal a task via some other mechanism such as
shared variables, then you are being naughty, and might not get the
behavior you intend.

It shouldn't surprise you that support for shared variable communication
is weak in Ada83, because there is none, except for some vague stuff
about pragma Shared that only applied to scalar types anyway.

In Ada83, if you want two tasks to communicate (ie for one task to "see"
that a variable has changed), then you have to use a rendezvous.

Support for shared variables has been vastly improved in Ada95.

Support for distributed programming is provided by the Distributed
System Annex in Ada95.  That annex is very very nice.  

 
> 4. Parameter passing.  Three modes; named parameters; default values
>    (but not for in-out parameters, for some reason).  In spite of all
>    the features, the behavior is mostly unspecified for arrays and
>    records.  Compare with rules of C, Java, or almost any other
>    language: they lack *all* these nifty features and seem to get
>    along fine.  C++ of course being the exception.

You seem to be arguing about two different themes: parameter passing
modes (in, out, in out) and parameter passing mechanism (by value, by
reference).

Let's handle the parameter passing mechanism first.  The Ada83 RM
mandated that scalar types be passed by value (copy in, copy out), but
left passing mechanism for composite types (arrays, records) up to the
implementation.

Ada95 added two more rules.  First, tagged types are passed by
reference.  This solves the ugly "slicing" problem you can have in C++.

Second, limited types are also passed by reference.  This solves the
problem of abstraction violations that can occur when limited objects
that are passed by value are aliased.

Now, let's talk about parameter passing modes.  There is nothing magic
going on here:

  in   means the client must provide a valid value for that parameter,
       and has a guarantee that the object won't get changed

  out  means the server has an obligation to provide a value for that 
       parameter

  in out  means the client must provide a valid value for the parameter,
          and that the value of the object may get modified by the
          server

Parameter passing modes thus explicitly document what everyone's
responsibilities are when a subprogram call happens.  I regard this
feature of the language as a Good Thing.

The problem with C is that it's too low level, and the programmer has to
do a lot of mental gymnastics to determine what a subprogram call means.

He must mentally translate low level calls that require pointers into
the higher level semantics ("Oh, let's see, a param that's
pointer-to-int means that it gets a value.  Yeah, I think that's it.").

This semantic information is directly expressible in Ada.

The other problem is that in C, the meaning of a parameter is frequently
ambiguous.  Does the subprogram

  void foo (char *s);

mean that an array of characters in being passed in, or does it mean
that a char is being passed out?  At least in Ada, I can say

  procedure Foo (S : in String);

  procedure Bar (C : out Character);

and there is no ambiguity.

The less things for me to think about, the fewer things I'll get wrong.


> 5. Overloading.  Do result types matter?

Yes.  This is one of the big improvements over Pascal.


>    Do parameter names matter?

Not in a declaration. Only types matter:

   procedure Foo (Bar : in Integer);

   procedure Foo (Bar : in Float);

are a legal pair of declarations.  However, the declarations

   procedure Foobar (Foo : in Integer);

   procedure Foobar (Bar : in Integer);

would be illegal, because parameter names aren't considered part of the
subprogram's signature.

Parameter names can be used to disambiguate an invocation, though.  For
example, given these declarations:

   type American_Color is (Red, White, Blue);

   type French_Color is (Blue, White, Red);

   procedure Fly_Flag (American : in American_Color);

   procedure Fly_Flag (French : in French_Color);

then the invocation

   Fly_Flag (Red);

is ambiguous, because the compiler doesn't know whether you want to fly
the American flag or French flag.  To tell the compiler which one you
mean, you can use named notation in the call:

   Fly_Flag (French => Red);

which gives the compiler enough additional information to allow it to
determine which subprogram you want (here, to fly the French drapeau).

However, this feature of the language is seldom used, because most
programmers don't know about it, and you don't always have a differently
named parameter anyway (say the parameter had been named Flag for both
operations).

A better way to resolve the ambiguity, IMHO, is to use type
qualification:

  Fly_Flag (American_Color'(Red));

or

  Fly_Flag (French_Color'(Red));

This is a more direct way of explicitly indicating which subprogram you
intend to call. 

Note that when there's an ambiguity, the program is illegal, and the
compiler refuses to compile the program.  It's never the case that the
compiler just chooses one or the other for you.  When there's an
ambiguity, you the programmer must state explicitly which subprogram is
intended.


> Do default values matter?  Why, or why not?

No.  All default values do is allow you to omit parameters at the point
of call.  For example, Integer_IO.Put looks something like:

  procedure Put
    (Item  : in Num;
     Width : in Field := Default_Width);

Most of the time, the default width is what you want, and so you can
just call Put with a single param:

   Put (X);

However, it's still possible for there to be ambiguity at the point of
call.  For example, if I had another procedure with the profile

  procedure Put (Item : My_Integer_Type);

directly visible in the same scope as Integer_IO.Put, then the call

  Put (5);

would be ambiguous, because the compiler doesn't know which one you
mean: Integer_IO.Put with a default value for Width, or the Put that
takes My_Integer_Type?

Of course, when there's an ambiguity like this, then the program is
illegal, and won't compile.  A default value is never used to resolve an
ambiguity.  For example, there's no preference rule that says, "call the
subprogram that doesn't have any default parameters."

As with the earlier example, the programmer must state explicitly which
subprogram is intended.

Note also that parameter passing mode isn't used to resolve ambiguities
either.


>    And, hey: parameterless subroutines and enumeration literals look
>    sort of the same.  

Yes they do.  The reason is so that you can have more than one
identically-named literal in the same scope.  That way, I don't have to
do kludgey things like

  type American_Color is (Amer_Red, Amer_White, Amer_Blue);

  type French_Color is (Fr_Blue, Fr_White, Fr_Red);

because the compiler is too stupid to know which type is intended, if
you use just the name "Red".

Given these declaration:

   type American_Color is (Red, White, Blue);

   type French_Color is (Blue, White, Red);

   procedure Foo (American : in American_Color);

   procedure Bar (French : in French_Color);

then the calls 

   Foo (Red);
 
   Bar (Red);

are perfectly legal, because Foo takes American Red, and Bar takes
French Red, and the compiler can figure out which is which.  There is no
ambiguity here.


>    Can they overload each other?  Can they hide each other?  If so,
>    when and where?

You know, I've never tried to declare a parameterless function and an
enumeration type with an identically named literal in the same scope, so
I can't tell you.

About the only time you use parameterless functions in Ada is to provide
a literal for a type that is inheritable during derivation.  

(Actually, there's another use for parameterless functions, and that is
to move dependency on a literal value to a package body, so that if the
value changes, you don't have to recompile the universe because a spec
changed.)

For example:

generic
   ...
package Sets is

   type Set_Type is private;

   function Empty_Set return Set_Type;
   ...

end Sets;

So during a derivation, I inherit the "literal" Empty_Set, because it's
a primitive operation of the type.  (It's also an example of how return
type matters.)

If Empty_Set had been declared as a (constant) object:

  type Set_Type is private;

  Empty_Set : constant Set_Type;
...

then it wouldn't be inherited.  (In that case, you'd have to declare
another Empty_Set object.)


>    It could be worse though, as C++ demonstrates.

I can't say, because I haven't done much C++ programming.  

The thing that's nice about C++ is that it's very flexible and powerful,
allowing you to elegantly implement damn near any kind of abstraction,
and using a natural syntax.  (This is one fault of Ada: programmer
defined types have a different syntax from built-in types.)

However, this power and flexibility doesn't come for free, and the
language is therefore hard to master.  There are a lot of trap doors
waiting for the unwary.


> Next time I make a joke I'll make it about something that people don't 
> take so damn seriously.  Death, famine, or nuclear winter maybe. :-)

I didn't know it was a joke either, until you pointed it out!

You have to realize that there are a lot of guys out there with strong
negative opinions about Ada, who haven't actually done much (if any) Ada
programming.  They'd rather bitch about "problems with the language,"
instead of learning the idiom appropriate for their problem.

This is too bad, because a lot of guys who think they hate Ada would
probably love it, if only they took the time to learn it.  Oh, well.

Matt

Re: Ada vs C++ vs Java

[adam]

In article <m3d847sjjp.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:

> Ada and Java are the only mainstream languages that have built-in
> support for currency. . . .

I have to dispute this.  COBOL has always had support for currency; I
believe it was the first language with features for printing numbers with a
dollar sign and embedded commas, and even gave you the option of putting
asterisks in between the dollar sign and the number for check protection.
However, Ada 95 has added the package Ada.Text_IO.Editing, which should give
it at least as good support for currency as what COBOL has.

Yes, I know you meant to type "concurrency"... I'm just being silly...

:)
				-- Adam

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Matthew Heaney]

adam@irvine.com writes:

> In article <m3d847sjjp.fsf@mheaney.ni.net>,
>   Matthew Heaney <matthew_heaney@acm.org> wrote:
> 
> > Ada and Java are the only mainstream languages that have built-in
> > support for currency. . . .
> 
> Yes, I know you meant to type "concurrency"... I'm just being silly...

I spent a couple of hours writing that response, and it was late, and
you know how it goes...

Re: Ada vs C++ vs Java

[robert_dewar]

In article <78agrm$9jp$1@nnrp1.dejanews.com>,
  adam@irvine.com wrote:
> In article <m3d847sjjp.fsf@mheaney.ni.net>,
>   Matthew Heaney <matthew_heaney@acm.org> wrote:
>
> > Ada and Java are the only mainstream languages that
> > have built-in support for currency. . . .
>
> I have to dispute this.  COBOL has always had support for
> currency; <<rest of joke skipped :-)>>

Actually the interesting thing here is that only COBOL and
Ada 95 have support for currency computations. It is indeed
suprising that this support is missing from Java, but then
Java was intended for small scale embedded applications!


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Robert I. Eachus]

In article <78g16t$907$1@nnrp1.dejanews.com> robert_dewar@my-dejanews.com writes:

  > Actually the interesting thing here is that only COBOL and
  > Ada 95 have support for currency computations. It is indeed
  > suprising that this support is missing from Java, but then
  > Java was intended for small scale embedded applications!

   Don't forget PL/I!  But it is indeed very surprising that you have
two choices when writing a financial applet in Java--use floating
point and hope not to get bitten, or use scaled integer with
hand-coded scaling...

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada vs C++ vs Java

[Al Christians]

"Robert I. Eachus" wrote:
> 
> 
> But it is indeed very surprising that you have
> two choices when writing a financial applet in Java--use floating
> point and hope not to get bitten, or use scaled integer with
> hand-coded scaling...
> 

What is more surprising is the Rogue Wave software package JMoney
for Java.  It is the Java equivalent of their C++ money.h package.  
With money.h, precision into the hundreds of digits is supported,
but JMoney only goes up to 15 decimal digits -- it looks like 
JMoney is just a wrapper around a Java floating point.  

Al

Re: Ada vs C++ vs Java

[Jerry van Dijk]

Al Christians (achrist@easystreet.com) wrote:

: "Robert I. Eachus" wrote:
: > 
: > But it is indeed very surprising that you have
: > two choices when writing a financial applet in Java--use floating
: > point and hope not to get bitten, or use scaled integer with
: > hand-coded scaling...

: What is more surprising is the Rogue Wave software package JMoney
: for Java.  It is the Java equivalent of their C++ money.h package.  
: With money.h, precision into the hundreds of digits is supported,
: but JMoney only goes up to 15 decimal digits -- it looks like 
: JMoney is just a wrapper around a Java floating point.  

Even worse, the people working on such applications (be it in Java or
C++, or Delphi, or ...) do not even seem to grap the significance.

--
-- Jerry van Dijk | Leiden, Holland
-- Team Ada       | jdijk@acm.org
-- see http://stad.dsl.nl/~jvandyk

Re: Ada vs C++ vs Java

[Joe Gwinn]

In article <m3zp7hfzvz.fsf@mheaney.ni.net>, Matthew Heaney
<matthew_heaney@acm.org> wrote:

> Mike Coffin <mhc@Eng.Sun.COM> writes:
> 
> > Matthew Heaney <matthew_heaney@acm.org> writes:
> > > This is throwing the baby out with the bath-water.  Ada95 and C++ are
> > > both static languages, just like C.  It is no more difficult to
> > > statically determine storage requirements using those higher-level
> > > languages than it is for C.
> > > 
> > > In this day and age, there is very little reason to continue using C.
> > 
> >  Scene: the water cooler in a good sized company.
> >  Dramatis personae: manager and programmer.
> > 
> >  The curtain rises...
> > 
> >  manager: You should use C++ or Ada.  They're higher level than C.
> > 
> >  programmer: But I hate them.
> > 
> >  manager: But they're higher level!  
> > 
> >  programmer: Yeah, right.  When it first appeared, Ada was the
> >          laughingstock of programmers everywhere for its insane
> >          complexity and C++ has managed to outdo it.
> [rest of dialog snipped]
> 
> This response contains no substantive information.  If vague criticisms
> like "Ada is complex" are the best you can do, then I must conclude that
> you don't really know Ada.

I think the point being made was that plain vanilla C was less complex
than Ada (83 and 95) and also C++.  

A data point.  In the 1980s, this same issue came up with respect to K&R C
and Ada83.  To avoid unresolvable theological debates, I "weighed" the DEC
Ada and DEC C compilers on VAX/VMS.  The Ada compiler was ten times
larger.  This is roughly the ratio of the sizes of their respective
language reference manuals as well.

So, it would appear safe to conclude that Ada is substantially more
complex than plain vanilla C.  

C++ is quite another matter; my impression is that Ada95 and C++ are of
roughly equal size and complexity, although I haven't weighed any
compilers.  This might be a useful exercise to perform on gnu C, C++, and
Ada95

That said, it doesn't automatically follow that complex is bad and simple
is good.  Assembly language is simpler than any high-order language, but
it's lots more work to code in assembly.  Yet, people still use assembly. 
It all depends on one's needs and objectives.

In the embedded arena, simpler can be better because simpler systems make
fewer assumptions about how the world works, and thus are less likely to
make wrong assumptions, ones needing to be truncated and/or worked around
at great expense.  Also, simpler systems are easier to debug, simply
because there is less stuff to understand and whip into shape.

In any arena, complex can be better because complex systems do more for
you, leaving less to be built and debugged (assuming that the complex
stuff doesn't need debugging, which isn't always the case).

So, match the solution to the problem.

Joe Gwinn

Re: Ada vs C++ vs Java

[robert_dewar]

In article
<gwinn-1801992138590001@d214.dial-2.cmb.ma.ultra.net>,
  gwinn@ma.ultranet.com (Joe Gwinn) wrote:
> I think the point being made was that plain vanilla C was
> less complex than Ada (83 and 95) and also C++.

Not so fast! Complexity/Simplicity can talk about many
things.

  Complexity of implementation
  Complexity of formal definition
  Complexity of informal definition
  Complexity of learning language
  Complexity of programs written in the language

Often these are in direct competition. For example, adding
exceptions as a primitive feature can complicate the
definition and implementation, but it may very well
simplify programs written using this feature.

> A data point.  In the 1980s, this same issue came up with
> respect to K&R C and Ada83.  To avoid unresolvable
> theological debates, I "weighed" the DEC Ada and DEC C
> compilers on VAX/VMS.  The Ada compiler was ten times
> larger.  This is roughly the ratio of the sizes of their
> respective language reference manuals as well.

K&R C is NOT a reference manual, the proper comparison is
the ANSI C standard vs the Ada standard. There is nothing
LIKE a factor of 10 in this. By comparison with either of
these standards, K&R is simply an informal description.
Note that this comparison is on just one dimension, namely
complexity of informal/formal definition.

As for the size of the compilers, you were at that time not
looking at modern optimizing compilers. If you repeat this
experiment with modern optimizing compilers, you will find
that for all the languages, the majority of the complexity,
and weight of the compiler is in the optimizer. For
example, even when using the GNAT front end, there are more
lines of code in the gcc backend than in the front end. So
you couldn't even reach a factor of 2 in that context.

And of course this also measures only ONE of the components
of complexity, namely complexity of implementation.

> Assembly language is simpler than any high-order
> language, but it's lots more work to code in assembly.

Now let me guess. The last time you looked at machine
language was in the 80's, right? Yes, in those days, the
semantics of machine language was pretty simple.

I am afraid that things have changed. At this stage the
full execution semantics of a modern chip with extensive
instruction-level parallelism is remarkably complex along
ALL the dimensions I mention above. A chip like the Pentium
II, if you include efficiency issues, which are indeed not
fully documented publicly, let alone formally specified,
you have something far MORE complicated than any of the
languages we are talking about here.

>> Yet, people still use assembly.

Well barely ...

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Joe Gwinn]

Well, I can always depend on Robert for a fight...

In article <782r25$k18$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com
wrote:

> In article
> <gwinn-1801992138590001@d214.dial-2.cmb.ma.ultra.net>,
>   gwinn@ma.ultranet.com (Joe Gwinn) wrote:
> > I think the point being made was that plain vanilla C was
> > less complex than Ada (83 and 95) and also C++.
> 
> Not so fast! Complexity/Simplicity can talk about many
> things.
> 
>   Complexity of implementation
>   Complexity of formal definition
>   Complexity of informal definition
>   Complexity of learning language
>   Complexity of programs written in the language
> 
> Often these are in direct competition. For example, adding
> exceptions as a primitive feature can complicate the
> definition and implementation, but it may very well
> simplify programs written using this feature.

Hmm.  I was reminding people what the other poster said, and he didn't
talk of these details, and may not care to go that deep.


> > A data point.  In the 1980s, this same issue came up with
> > respect to K&R C and Ada83.  To avoid unresolvable
> > theological debates, I "weighed" the DEC Ada and DEC C
> > compilers on VAX/VMS.  The Ada compiler was ten times
> > larger.  This is roughly the ratio of the sizes of their
> > respective language reference manuals as well.
> 
> K&R C is NOT a reference manual, the proper comparison is
> the ANSI C standard vs the Ada standard. There is nothing
> LIKE a factor of 10 in this. By comparison with either of
> these standards, K&R is simply an informal description.
> Note that this comparison is on just one dimension, namely
> complexity of informal/formal definition.

A data point is a data point, not a universal law.  I stand by what I
said.  The K&R White Book was the sole C manual for many years, so it'll
have to do.  ANSI C is not quite the same langauge, and came many years
later.


> As for the size of the compilers, you were at that time not
> looking at modern optimizing compilers. If you repeat this
> experiment with modern optimizing compilers, you will find
> that for all the languages, the majority of the complexity,
> and weight of the compiler is in the optimizer. For
> example, even when using the GNAT front end, there are more
> lines of code in the gcc backend than in the front end. So
> you couldn't even reach a factor of 2 in that context.

Is the optimiser common to both languages?  Back in 1980s, I couldn't
isolate the parts of the two compilers, and nothing was shared anyway.

So, tell us, what are the weights of the various front ends, and the
optimiser or optimisers?  Is there still a pure "C" front end, or has it
been subsumed into the C++ front end now?  It used to be that C++ was a
preprocessor that generated C source code that was compiled by this front
end.


> And of course this also measures only ONE of the components
> of complexity, namely complexity of implementation.

Yep.  One would assume that all these complexities are more or less
proportional to each other.   In particular, complex syntax has got to
cause complex compiler code.

Have you suitable numerical metrics for the other components of complexity?


> > Assembly language is simpler than any high-order
> > language, but it's lots more work to code in assembly.
> 
> Now let me guess. The last time you looked at machine
> language was in the 80's, right?   Yes, in those days, the
> semantics of machine language was pretty simple.

No, 1998.  We do read and sometimes write PowerPC assembly code.  Many
1980s machines had more complex instruction sets than the PowerPC.


> I am afraid that things have changed. At this stage the
> full execution semantics of a modern chip with extensive
> instruction-level parallelism is remarkably complex along
> ALL the dimensions I mention above. A chip like the Pentium
> II, if you include efficiency issues, which are indeed not
> fully documented publicly, let alone formally specified,
> you have something far MORE complicated than any of the
> languages we are talking about here.

All true, but what has all this to do with the original question, the
relative complexity of C, C++, Ada83, and Ada95?


> >> Yet, people still use assembly.
> 
> Well barely ...

We try to avoid it, but don't always succeed.  Another variant is to code
in a high-order language (HOL), inspect the generated assembly, paraphrase
the HOL source trying to improve the assembly, iteratively.  This can be
very effective, but it does give a false impression that the code is in a
HOL.  It isn't really, because a new compiler will force a repeat of the
tuning steps just described.


Joe Gwinn

Re: Ada vs C++ vs Java

[dennison]

In article <gwinn-2001992141150001@d119.dial-2.cmb.ma.ultra.net>,
  gwinn@ma.ultranet.com (Joe Gwinn) wrote:
> In article <782r25$k18$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com
> wrote:
>
> > In article
> > <gwinn-1801992138590001@d214.dial-2.cmb.ma.ultra.net>,
> >   gwinn@ma.ultranet.com (Joe Gwinn) wrote:
> > > A data point.  In the 1980s, this same issue came up with
> > > respect to K&R C and Ada83.  To avoid unresolvable
> > > theological debates, I "weighed" the DEC Ada and DEC C
> > > compilers on VAX/VMS.  The Ada compiler was ten times
> > > larger.  This is roughly the ratio of the sizes of their
> > > respective language reference manuals as well.
> >
> > K&R C is NOT a reference manual, the proper comparison is
> > the ANSI C standard vs the Ada standard. There is nothing
> > LIKE a factor of 10 in this. By comparison with either of
> > these standards, K&R is simply an informal description.
> > Note that this comparison is on just one dimension, namely
> > complexity of informal/formal definition.
>
> A data point is a data point, not a universal law.  I stand by what I
> said.  The K&R White Book was the sole C manual for many years, so it'll
> have to do.  ANSI C is not quite the same langauge, and came many years

I think what Robert was getting at is that comparing the size of a guide like
the K&R white book to the size of a complete language reference manual is
silly. In fact I have seen it remarked that if a manual going into the kind
of detail on K&R C that the Ada 83 LRM goes into for Ada were written, it
would most likely be considerably *longer* than the Ada 83 LRM (my copy of
which is only about 250 pages + 75 pages of apendices and indices). But since
said mythical document does not exist, speculation based on their relative
size is silly.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[robert_dewar]

In article <787frb$k8j$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> But since
> said mythical document does not exist, speculation based
> on their relative
> size is silly.


Exactly so, on that point we are in 100% agreement :-)

Robert

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[robert_dewar]

In article
<gwinn-2001992141150001@d119.dial-2.cmb.ma.ultra.net>,

> A data point is a data point, not a universal law.
> I stand by what I said.  The K&R White Book was the sole
> C manual for many years, so it'll have to do.  ANSI C is
> not quite the same langauge, and came many years later.

That's not the point. Your "data point" is invalid because
it was an apples and oranges comparison. You cannot compare
an informal description like the K&R white book with an
ANSI standard. It is not good enough to say, well I know
I was comparing X and Y, and they are not comparable but
that's all I could find to compare, the data point is
still entirely invalid.

> > As for the size of the compilers, you were at that time
> > not looking at modern optimizing compilers. If you
> > repeat this experiment with modern optimizing
> > compilers, you will find that for all the languages,
> > the majority of the complexity,
> > and weight of the compiler is in the optimizer. xt.
>
> Is the optimiser common to both languages?  Back in
> 1980s, I couldn't isolate the parts of the two compilers,
> and nothing was shared anyway.

Again, the fact that you couldn't do the experiment
properly does not make it valid! Of course you could have
isolated the parts of the compiler back then, you just did
not know how to.

As for the optimizer being common to both languages, yes
that's typically the case now, that back end optimization
is language independent in most compilers. In any case
even if the code isn't common, both compilers have large
chunks of language independent optimization circuitry.

> So, tell us, what are the weights of the various front
> ends, and the optimiser or optimisers?  Is there still a
> pure "C" front end, or has it been subsumed into the C++
> front end now?

This varies of course from one compiler to another, I
already gave some idea for the gcc compiler.

There are of course some cases of separate C front ends
(e.g. GNU C), and some cases of integrated front ends.

But even confining your measurements to a particular front
end, or set of front ends, may say more about quality of
implementation than the language itself. For example,
comparing a C front end and an Ada front end. If you are
trying to extract accurate aliasing information (gcc does
not!) then this is far harder in C, and would take more
apparatus than in Ada.

Also, there is pretty much a free choice of where to do
certainly global optimizations, they can be done early in
the front end, or later in the backend. You need to really
know the structure of a compiler well to get any kind of
meaningful measurements.

Your attempts to "weigh" compilers cannot possibly give
anything but vague misleading results. You can "stand by"
these meaningless results if you like, but that does not
make them meaningful.

<<query about preprocessors and C++>>

You seem to confuse languages and their implementations
here (and elsewhere in the post). Yes, there was one
particular implementation of C++ that preprocessed into
C (just as there is at least one implementation of Ada 95
that preprocesses into C). It is rarely used for serious
C++ work these days, since there are many C++ compilers
around that generate efficient object code directly (the
same can be said of Ada 95 of course).

> Yep.  One would assume that all these complexities are
> more or less proportional to each other.   In particular,
> complex syntax has got to cause complex compiler code.

No, not at all. An easy mistake for someone who does not
know compiler details, but syntax is always a trivial part
of any compiler.

And it is NOT AT ALL the case that these complexities are
more or less proportional, that was the whole point of my
post (and I gave examples, please reread). Here is another
example, I can give literally hundreds of similar ones.

  A language is easier to describe, define, and use if its
  features are orthogonal. This is a well known principle,
  first clearly enunciated by the Algol-68 design.

  Let's take a particular example, in Ada 95 (same applies
  to any similar Algol style language), we have records
  with fields of whatever type we like.

  We have array types, and it is nice for these to be
  dynamically sizable.

  The above decisions, in an orthogonal design, mean that
  records can have fields whose type is a variable sized
  array. This combination causes absolutely NO increase
  in complexity of description, or use. Indeed a
  restriction that made this particular combination
  illegal would be a non-orthogonal "odd" rule, and would
  make the language more complex from these points of view.

  However, in the implementation domain, dynamic arrays are
  easy to implement, and ordinary records without dynamic
  array components are easy to implement. But the
  combination is annoying, and definitely increases the
  complexity of an implementation.

Let's take another example along a different dimension

  goto statements certainly do not significantly complicate
  the informal description or use of a language like C.
  Typically they don't much affect implementation either,
  though they do make certain optimization techniques
  harder.

  But when it comes to formal description, gotos are a
  real menace. In a denotation semantic definition, a goto
  is often far more trouble to define than say an IF or
  LOOP statement. Have a look at the original SETL sources
  for Ada to see this complication effect (the SETL
  implementation of Ada was essentially a formal definition
  that executed, so was more affected by this consideration
  than a normal implementation would be).

I can rattle on like this for a long time, there are such
trade offs between nearly every aspect of complexity.
During the Ada 95 design, we often had arguments about
complexity, and it was quite helpful when I first proposed
this more elaborate notion of complexity to realize that
very often the reason that we disagreed on the issue
was because we were arguing different dimensions.

For example, the design team often concentrated on making
things simple for the Ada programmer, sometimes at the
expense of other aspects of complexity.

What seemed at first like a disagreement ("This is far
too complex", "no it isn't", "yes it is"), turned out to
be an argument about tradeoffs between different goals, and
once we understood this clearly, it was far easier to
have a clear discussion and come to the right conclusion.

One more example, from a recent thread. The ALL keyword for
general access types in Ada 95 adds no significant
implementation complexity, or complexity in the formal
description. However, it definitely adds complexity to the
user, as noted in previous posts to this group.
>
> Have you suitable numerical metrics for the other
> components of complexity?

I don't know that anyone has tried to do this, it would
be difficult. Certainly this decomposition of the notion
of complexity makes the problem more tractable, but still
extremely difficult. But we don't have to have numerical
metrics for this to be a useful principle for discussion
(indeed bogus numerical metrics, such as your attempts to
weigh compilers, can obfuscate clear discussion -- better
no metrics than bogus ones).

> > > Assembly language is simpler than any high-order
> > > language, but it's lots more work to code in
> > > assembly.
> >
> > Now let me guess. The last time you looked at machine
> > language was in the 80's, right?   Yes, in those days,
> > the semantics of machine language was pretty simple.
>
> No, 1998.  We do read and sometimes write PowerPC
> assembly code.  Many 1980s machines had more complex
> instruction sets than the PowerPC.

I *strongly* disagree. If you are just focussing on the
functionality of the instruction set, sure, but this is
trivial in all cases. The complex part of any instruction
set is the execution efficiency semantics.

> > I am afraid that things have changed. At this stage the
> > full execution semantics of a modern chip with
> > extensive instruction-level parallelism is remarkably
> > complex along ALL the dimensions I mention above. A
> > chip like the Pentium II, if you include efficiency
> > issues, which are indeed not fully documented publicly,
> > let alone formally specified, you have something far
> > MORE complicated than any of the languages we are
> > talking about here.
>
> All true, but what has all this to do with the original
> question, the relative complexity of C, C++, Ada83, and
> Ada95?

Not sure, Why not ask Joe Gwinn, it was he who gave
assembly language as an example of a simple language :-)

> > >> Yet, people still use assembly.
> >
> > Well barely ...
>
> We try to avoid it, but don't always succeed.  Another
> variant is to code in a high-order language (HOL),
> inspect the generated assembly, paraphrase the HOL source
> trying to improve the assembly, iteratively.

That is exactly what is extremely difficult to do. To know
how to optimize the code, you have to fully understand the
scheduling and other instruction parallelism aspects of the
code. We quite often get comments on the generated code
from GNAT that show that people do not understand such
things. A little example, many people would expect in

  if (A > 4) AND [THEN] (B > 4) then

that the addition of THEN would speed things up in the
case where A is indeed greater than 4. This is of course
quite likely to be false on modern machines where jumps
can be expensive, and indeed an important optimization
on predicated machines like the Merced is to eliminate
short circuiting, and in general to convert if's to
straight line code without jumps.


> This can be very effective, but it does give a false
> impression that the code is in a HOL.  It isn't really,
> because a new compiler will force a repeat of the
> tuning steps just described.

Sounds like a highly undesirable practice to me. I would
recommend instead that you put your energy into learning
more about how to use and choose compilers effectively.
With modern machines, you are more likely to create a mess
by mucking with the generated assembly code. This may have
been a reasonable approach in the 70's but not today!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Joe Gwinn]

In article <787f4b$jl9$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com
wrote:

> In article
> <gwinn-2001992141150001@d119.dial-2.cmb.ma.ultra.net>,
> 
> > A data point is a data point, not a universal law.
> > I stand by what I said.  The K&R White Book was the sole
> > C manual for many years, so it'll have to do.  ANSI C is
> > not quite the same langauge, and came many years later.
> 
> That's not the point. Your "data point" is invalid because
> it was an apples and oranges comparison. You cannot compare
> an informal description like the K&R white book with an
> ANSI standard. It is not good enough to say, well I know
> I was comparing X and Y, and they are not comparable but
> that's all I could find to compare, the data point is
> still entirely invalid.

Had a formal C language reference been available back then, I would have
used it.

You keep trying to make it more than I ever claimed for it, an exercise in
knocking strawmen down.  I think I accurately described the data point,
and leave it to the readers to draw whatever conclusions they wish.  


> > > As for the size of the compilers, you were at that time
> > > not looking at modern optimizing compilers. If you
> > > repeat this experiment with modern optimizing
> > > compilers, you will find that for all the languages,
> > > the majority of the complexity,
> > > and weight of the compiler is in the optimizer. xt.
> >
> > Is the optimiser common to both languages?  Back in
> > 1980s, I couldn't isolate the parts of the two compilers,
> > and nothing was shared anyway.
> 
> Again, the fact that you couldn't do the experiment
> properly does not make it valid! Of course you could have
> isolated the parts of the compiler back then, you just did
> not know how to.

You keep trying to make it more than I ever claimed for it.  I think I
accurately described the data point, and leave it to the readers to draw
whatever conclusions they wish.  


> As for the optimizer being common to both languages, yes
> that's typically the case now, that back end optimization
> is language independent in most compilers. In any case
> even if the code isn't common, both compilers have large
> chunks of language independent optimization circuitry.

This was my impression, and you are certainly well-positioned to know.


> > So, tell us, what are the weights of the various front
> > ends, and the optimiser or optimisers?  Is there still a
> > pure "C" front end, or has it been subsumed into the C++
> > front end now?
> 
> This varies of course from one compiler to another, I
> already gave some idea for the gcc compiler.
> 
> There are of course some cases of separate C front ends
> (e.g. GNU C), and some cases of integrated front ends.
> 
> But even confining your measurements to a particular front
> end, or set of front ends, may say more about quality of
> implementation than the language itself. For example,
> comparing a C front end and an Ada front end. If you are
> trying to extract accurate aliasing information (gcc does
> not!) then this is far harder in C, and would take more
> apparatus than in Ada.
> 
> Also, there is pretty much a free choice of where to do
> certainly global optimizations, they can be done early in
> the front end, or later in the backend. You need to really
> know the structure of a compiler well to get any kind of
> meaningful measurements.
> 
> Your attempts to "weigh" compilers cannot possibly give
> anything but vague misleading results. You can "stand by"
> these meaningless results if you like, but that does not
> make them meaningful.

Well, I was hoping for another admittedly crude measure. As discussed
below, it may well be the only numerical metric available, for all its
sins.

You have gnu C, C++ and gnat at your fingertips.  What do the various
components weigh?  


> <<query about preprocessors and C++>>
> 
> You seem to confuse languages and their implementations
> here (and elsewhere in the post). Yes, there was one
> particular implementation of C++ that preprocessed into
> C (just as there is at least one implementation of Ada 95
> that preprocesses into C). It is rarely used for serious
> C++ work these days, since there are many C++ compilers
> around that generate efficient object code directly (the
> same can be said of Ada 95 of course).

I defer to your expertise here.


> > Yep.  One would assume that all these complexities are
> > more or less proportional to each other.   In particular,
> > complex syntax has got to cause complex compiler code.
> 
> No, not at all. An easy mistake for someone who does not
> know compiler details, but syntax is always a trivial part
> of any compiler.

I knew this would draw a jeremiad.

I agree that in theory these two complexities are not strictly
proportional.  However, in practice, one can generally find rough but
servicable proportionalities.  More complexity generally requires more
code to implement, especially on the scale of an entire compiler.  That's
why bigger problems take longer to code.


> And it is NOT AT ALL the case that these complexities are
> more or less proportional, that was the whole point of my
> post (and I gave examples, please reread). Here is another
> example, I can give literally hundreds of similar ones.
[big snip]
> I can rattle on like this for a long time, there are such
> trade offs between nearly every aspect of complexity.
> During the Ada 95 design, we often had arguments about
> complexity, and it was quite helpful when I first proposed
> this more elaborate notion of complexity to realize that
> very often the reason that we disagreed on the issue
> was because we were arguing different dimensions.

All very complex.  I've been in the same kinds of arguments about
operating system design, in POSIX standards meetings, so I can
commiserate.

But, let's get down to brass tacks, using personal experience and whatever
expertise and instincts we can muster to sort some languages into a rough
complexity ranking.  Everybody gets to vote.   Do you agree or disagree,
and why, in 25 words or less?  Note that we are not debating whether
complexity is good or bad, we are just estimating.  Complexity and
capability tend to come hand in hand, along with assumptions about how the
world works or at least should work.  Reasonable people can differ.


First, by pairs:

1.  Fortran 77 versus K&R C?  I would say that f77 was more complex than K&R C. 

2.  K&R C versus ANSI C?  ANSI C must be more complex, as it evolved from
K&R, but not greatly so.

3.  Ada83 versus K&R C?  Ada83 is a factor more complex, by all metrics,
than K&R C, by universal experience.  Actually, C was often derided as
being the moral equivalent of assembler, and not entirely without
justification.

4.  Ada83 versus Ada95?  Ada95 the language is more complex (bigger) than
Ada83, 
to support all the new features, like object orientation (OO).  

5.  ANSI C versus C++ (any flavor)?  C++ is more complex, by a large
factor.  I doubt that there is much argument on this.  It's the OO that
did it.

6.  Ada95 versus C++?  I have heard arguments in both directions, but
nothing really convincing (absent metrics). It may be that each camp
accuses the other of being the larger.  They therefore seem to be about
the same size.  


All in one ordered list, least complex first:

1.  K&R C

2.  ANSI C

3.  Fortran 77

4.  Ada83

5.  C++ and Ada95

Remember, we are doing these rankings based on experience and even
instinct, not theory.


> > Have you suitable numerical metrics for the other
> > components of complexity?
> 
> I don't know that anyone has tried to do this, it would
> be difficult. Certainly this decomposition of the notion
> of complexity makes the problem more tractable, but still
> extremely difficult. But we don't have to have numerical
> metrics for this to be a useful principle for discussion
> (indeed bogus numerical metrics, such as your attempts to
> weigh compilers, can obfuscate clear discussion -- better
> no metrics than bogus ones).

I don't know of any other metrics that work very well either.  It's a bit
like the debate about the usefulness of source lines of code (SLOC) as a
metric of the human labor required to write software.  Many complexity
measures have been tried over the years, but we always seem to come back
to SLOCs, because the more complex metrics just don't seem to predict any
better than just counting the lines.

But I cannot agree that rough metrics are useless, so we must use what's
available, but understand the limitations of the metrics we do use, as
with any tool.


> > > > Assembly language is simpler than any high-order
> > > > language, but it's lots more work to code in
> > > > assembly.
> > >
> > > Now let me guess. The last time you looked at machine
> > > language was in the 80's, right?   Yes, in those days,
> > > the semantics of machine language was pretty simple.
> >
> > No, 1998.  We do read and sometimes write PowerPC
> > assembly code.  Many 1980s machines had more complex
> > instruction sets than the PowerPC.
> 
> I *strongly* disagree. If you are just focussing on the
> functionality of the instruction set, sure, but this is
> trivial in all cases. The complex part of any instruction
> set is the execution efficiency semantics.

Huh?  I was talking about reading and writing assembly code for the
machine.  Many of the older machines had really strange architectures,
driven by the cost of hardware.  As semiconductors got cheaper and better,
the machine architectures got cleaner and simpler, and better suited to
supporting software.  Orthogonality arrived.


> > > I am afraid that things have changed. At this stage the
> > > full execution semantics of a modern chip with
> > > extensive instruction-level parallelism is remarkably
> > > complex along ALL the dimensions I mention above. A
> > > chip like the Pentium II, if you include efficiency
> > > issues, which are indeed not fully documented publicly,
> > > let alone formally specified, you have something far
> > > MORE complicated than any of the languages we are
> > > talking about here.
> >
> > All true, but what has all this to do with the original
> > question, the relative complexity of C, C++, Ada83, and
> > Ada95?
> 
> Not sure, Why not ask Joe Gwinn, it was he who gave
> assembly language as an example of a simple language :-)

Assemblers are generally simpler to write than HOL compilers, even for the
strange hardware architectures of yore, because the assembler did much
less for you than a compiler.  Assembly language was also simpler,
although the writer had to understand more of the hardware to write the
code.


> > > >> Yet, people still use assembly.
> > >
> > > Well barely ...
> >
> > We try to avoid it, but don't always succeed.  Another
> > variant is to code in a high-order language (HOL),
> > inspect the generated assembly, paraphrase the HOL source
> > trying to improve the assembly, iteratively.
> 
> That is exactly what is extremely difficult to do. To know
> how to optimize the code, you have to fully understand the
> scheduling and other instruction parallelism aspects of the
> code. We quite often get comments on the generated code
> from GNAT that show that people do not understand such
> things. A little example, many people would expect in
> 
>   if (A > 4) AND [THEN] (B > 4) then
> 
> that the addition of THEN would speed things up in the
> case where A is indeed greater than 4. This is of course
> quite likely to be false on modern machines where jumps
> can be expensive, and indeed an important optimization
> on predicated machines like the Merced is to eliminate
> short circuiting, and in general to convert if's to
> straight line code without jumps.

Yep.  All true.  Except the part about understanding the "scheduling and
other instruction parallelism".  Actually, we just measure the performance
of some code variations.  I didn't claim it was pretty.  Or that we do it
anywhere but a few critical hotspots.


> > This can be very effective, but it does give a false
> > impression that the code is in a HOL.  It isn't really,
> > because a new compiler will force a repeat of the
> > tuning steps just described.
> 
> Sounds like a highly undesirable practice to me. I would
> recommend instead that you put your energy into learning
> more about how to use and choose compilers effectively.

We don't always have our choice of compilers, and also there are lots of
non-technical issues in their selection, but we still have to get the job
done.


> With modern machines, you are more likely to create a mess
> by mucking with the generated assembly code. This may have
> been a reasonable approach in the 70's but not today!

What is described is changing the HOL source so that the compiler
generates the correct assembly code.  The generated assembly code is not
modified.


Joe Gwinn

Re: Ada vs C++ vs Java

[robert_dewar]

In article
<gwinn-2201990017500001@d5.dial-1.cmb.ma.ultra.net>,
  gwinn@ma.ultranet.com (Joe Gwinn) wrote:
> Had a formal C language reference been available back
> then, I would have used it.
>
> You keep trying to make it more than I ever claimed for
> it, an exercise in knocking strawmen down.  I think I
> accurately described the data point, and leave it to the
> readers to draw whatever conclusions they wish.

Perhaps naively most readers will expect that if you
describe such a data point, then at least you ascribe
*some* significance to it. That is certainly the
implication from your original post!

If indeed you agree that this is a nonsense comparison that
tells absolutely nothing of any value at all, then we have
no argument!

> You keep trying to make it more than I ever claimed for
> it.  I think I accurately described the data point, and
> leave it to the readers to draw whatever conclusions they
> wish.

Again, we assumed that at least *you* thought that your
observation had some value (you did after all spend some
time doing it). In fact neither of these observations says
anything at all useful about language comparisons.

Producing completely bogus comparisons, and then saying you
have accurately described these comparisons seems
disingenuous. At the very least you were trying to convey
the impression that something useful was being measured!


> You have gnu C, C++ and gnat at your fingertips.  What do
> the various components weigh?

It is not something I would spend 30 seconds looking at,
because the answer to this question would convey little of
value!
>
>
> But, let's get down to brass tacks, using personal
> experience and whatever expertise and instincts we can
> muster to sort some languages into a rough complexity
> ranking.

Gosh, it almost seems like you did not bother to read my
last note, the whole point of which was that to lump the
different aspects of complexity into a single metric does
not work.


> 3.  Ada83 versus K&R C?  Ada83 is a factor more complex,
>     by all metrics, than K&R C, by universal experience.

Since this seems to be your most obvious case for expecting
an unconditional yes vote, I will choose this one to
illustrate.

First of all K&R C is ill defined. Lack of definition
results in a lot of uncertainty of semantic details, and
this kind of uncertainty leads to significant complexity:

For example

    int a[10];
    ...
    for (p = a; p < &a[10]; p++) ...

is this valid K&R C? Difficult to say, probably the answer
is no, but on the other hand, C programmers use this
construct all the time. It is of course legal in ANSI C by
virtue of a very special (and rather odd and non-orthogonal
rule).

If we are going by the metric of ease of formal
description, I would say Ada 83 is far simpler than K&R C,
just because so much remains to be done in the latter case.
That work of course is what took the ANSI C committee so
much effort to sort out.

As for ease of use, this depends what you are doing, if you
have to write a multi-threaded application in a portable
manner, then in one sense it is impossible with K&R C, but
in pragmatic practice it means struggling with some
pthreads package. These packages are typically ill-defined
and all sorts of non-portable glitches occur. Ada 83 is by
comparison a far simpler environment. The same goes for
code that needs exceptions.

From an implementation point of view, C may be simpler,
though even there it is not quite cut and dried. For
instance extraction of good aliasing information of the
same quality can require FAR more work in C than in Ada, or
even be quite impossible. Furthermore, the need for good
aliasing information in C is much more important because of
the lack of strong typing of pointers in the Ada sense.

About the only place where I would say that C is clearly
simpler than Ada 83 is in the comparison of informal
descriptions, where K&R shows that a fairly short informal
description of C is possible.



-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Joe Gwinn]

In article <78g0oj$8sb$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com
wrote:

> In article
> <gwinn-2201990017500001@d5.dial-1.cmb.ma.ultra.net>,
>   gwinn@ma.ultranet.com (Joe Gwinn) wrote:
> > Had a formal C language reference been available back
> > then, I would have used it.
> >
> > You keep trying to make it more than I ever claimed for
> > it, an exercise in knocking strawmen down.  I think I
> > accurately described the data point, and leave it to the
> > readers to draw whatever conclusions they wish.
> 
> Perhaps naively most readers will expect that if you
> describe such a data point, then at least you ascribe
> *some* significance to it. That is certainly the
> implication from your original post!
> 
> If indeed you agree that this is a nonsense comparison that
> tells absolutely nothing of any value at all, then we have
> no argument!
> 
> > You keep trying to make it more than I ever claimed for
> > it.  I think I accurately described the data point, and
> > leave it to the readers to draw whatever conclusions they
> > wish.
> 
> Again, we assumed that at least *you* thought that your
> observation had some value (you did after all spend some
> time doing it). In fact neither of these observations says
> anything at all useful about language comparisons.
> 
> Producing completely bogus comparisons, and then saying you
> have accurately described these comparisons seems
> disingenuous. At the very least you were trying to convey
> the impression that something useful was being measured!

The evidence is what it is, and we cannot do much about it, fifteen year later.


> > You have gnu C, C++ and gnat at your fingertips.  What do
> > the various components weigh?
> 
> It is not something I would spend 30 seconds looking at,
> because the answer to this question would convey little of
> value!

If perfect metric existed, we would use them.  Absent perfection, we use
what's avaialble.  I take it the answer isn't to Ada's perceived
advantage.


> > But, let's get down to brass tacks, using personal
> > experience and whatever expertise and instincts we can
> > muster to sort some languages into a rough complexity
> > ranking.
> 
> Gosh, it almost seems like you did not bother to read my
> last note, the whole point of which was that to lump the
> different aspects of complexity into a single metric does
> not work.

Clearly, I didn't accept the argument, which boiled down to saying that
because we couldn't find a perfect metric, we should do absolutely
nothing.  I know what would happen if I tried that kind of perfectionist
argument out on my boss.  Rough measures are better than no measures at
all.


> > 3.  Ada83 versus K&R C?  Ada83 is a factor more complex,
> >     by all metrics, than K&R C, by universal experience.
> 
> Since this seems to be your most obvious case for expecting
> an unconditional yes vote, I will choose this one to
> illustrate.

Yep.  OK.


> First of all K&R C is ill defined. Lack of definition
> results in a lot of uncertainty of semantic details, and
> this kind of uncertainty leads to significant complexity:

We already agreed that Ada83 is better defined than K&R C, so further
discussion of that is beside the point.  Please answer the original
question, yes or no.  


> For example
> 
>     int a[10];
>     ...
>     for (p = a; p < &a[10]; p++) ...
> 
> is this valid K&R C? Difficult to say, probably the answer
> is no, but on the other hand, C programmers use this
> construct all the time. It is of course legal in ANSI C by
> virtue of a very special (and rather odd and non-orthogonal
> rule).

Yep.  But, beside the point.


> If we are going by the metric of ease of formal
> description, I would say Ada 83 is far simpler than K&R C,
> just because so much remains to be done in the latter case.
> That work of course is what took the ANSI C committee so
> much effort to sort out.

Yep.  But, beside the point.


> As for ease of use, this depends what you are doing, if you
> have to write a multi-threaded application in a portable
> manner, then in one sense it is impossible with K&R C, but
> in pragmatic practice it means struggling with some
> pthreads package. These packages are typically ill-defined
> and all sorts of non-portable glitches occur. Ada 83 is by
> comparison a far simpler environment. The same goes for
> code that needs exceptions.

Perhaps.  But, beside the point.


> From an implementation point of view, C may be simpler,
> though even there it is not quite cut and dried. For
> instance extraction of good aliasing information of the
> same quality can require FAR more work in C than in Ada, or
> even be quite impossible. Furthermore, the need for good
> aliasing information in C is much more important because of
> the lack of strong typing of pointers in the Ada sense.

Perhaps.  This is your area of expertise.  

I guess this is a "yes", sort of.


> About the only place where I would say that C is clearly
> simpler than Ada 83 is in the comparison of informal
> descriptions, where K&R shows that a fairly short informal
> description of C is possible.

Has anyone written such an informal description of Ada83 as well?  I never
saw such a description, simple yet possible to program from, and one has
to wonder if it's possible to write such a thing.


Joe Gwinn

Re: Ada vs C++ vs Java

[robert_dewar]

In article
<gwinn-2401991852500001@d86.dial-6.cmb.ma.ultra.net>,
  gwinn@ma.ultranet.com (Joe Gwinn) wrote:
> The evidence is what it is, and we cannot do much about
> it, fifteen year later.

meaningless evidence involving a useless comparison is not
interesting now or 15 years ago.
>
> > > You have gnu C, C++ and gnat at your fingertips.
> > > What do
> > > the various components weigh?
> >
> > It is not something I would spend 30 seconds looking
> > at, because the answer to this question would convey
> > little of value!
>
> If perfect metric existed, we would use them.  Absent
> perfection, we use what's avaialble.

Please don't use *we* here. You may be happy to produce
completely meaningless data that is almost certain to
mislead, but I won't participate in this unscientific
excercise.

> I take it the answer isn't to Ada's perceived
> advantage.

Not at all, it is just that the result is meaningless.
Anyone perceiving an advantage or disadvantage in such
comparisons is making the same mistake you make of putting
credance in useless comparisons.


> > > 3.  Ada83 versus K&R C?  Ada83 is a factor more
> > >     complex, by all metrics, than K&R C, by universal
> > >experience.
> >
> > Since this seems to be your most obvious case for
> > expecting
> > an unconditional yes vote, I will choose this one to
> > illustrate.
>
> Yep.  OK.
>
> > First of all K&R C is ill defined. Lack of definition
> > results in a lot of uncertainty of semantic details,
> > and this kind of uncertainty leads to significant
> > complexity:
>
> We already agreed that Ada83 is better defined than K&R
> C, so further discussion of that is beside the point.
> Please answer the original question, yes or no.

Please don't obfuscate with silly lawyer talk. The whole
point of my argument which you don't seem to understand
at all, but I trust others do is that this is NOT a yes/no
question!
>

<<rest snipped, since you don't seem to understand the
point I am making about multiple incompatible metrics for
complexity>>

>
> Has anyone written such an informal description of Ada83
> as well?  I never saw such a description, simple yet
> possible to program from, and one has
> to wonder if it's possible to write such a thing.

One does not have to wonder there are several elementary
Ada texts around!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Joe Gwinn]

Impasse.  Perhaps it's just as well.

In article <78gok5$pmc$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com
wrote:

> In article
> <gwinn-2401991852500001@d86.dial-6.cmb.ma.ultra.net>,
>   gwinn@ma.ultranet.com (Joe Gwinn) wrote:
> > The evidence is what it is, and we cannot do much about
> > it, fifteen year later.
> 
> meaningless evidence involving a useless comparison is not
> interesting now or 15 years ago.
> >
> > > > You have gnu C, C++ and gnat at your fingertips.
> > > > What do
> > > > the various components weigh?
> > >
> > > It is not something I would spend 30 seconds looking
> > > at, because the answer to this question would convey
> > > little of value!
> >
> > If perfect metric existed, we would use them.  Absent
> > perfection, we use what's avaialble.
> 
> Please don't use *we* here. You may be happy to produce
> completely meaningless data that is almost certain to
> mislead, but I won't participate in this unscientific
> excercise.
> 
> > I take it the answer isn't to Ada's perceived
> > advantage.
> 
> Not at all, it is just that the result is meaningless.
> Anyone perceiving an advantage or disadvantage in such
> comparisons is making the same mistake you make of putting
> credance in useless comparisons.
> 
> 
> > > > 3.  Ada83 versus K&R C?  Ada83 is a factor more
> > > >     complex, by all metrics, than K&R C, by universal
> > > >experience.
> > >
> > > Since this seems to be your most obvious case for
> > > expecting
> > > an unconditional yes vote, I will choose this one to
> > > illustrate.
> >
> > Yep.  OK.
> >
> > > First of all K&R C is ill defined. Lack of definition
> > > results in a lot of uncertainty of semantic details,
> > > and this kind of uncertainty leads to significant
> > > complexity:
> >
> > We already agreed that Ada83 is better defined than K&R
> > C, so further discussion of that is beside the point.
> > Please answer the original question, yes or no.
> 
> Please don't obfuscate with silly lawyer talk. The whole
> point of my argument which you don't seem to understand
> at all, but I trust others do is that this is NOT a yes/no
> question!
> >
> 
> <<rest snipped, since you don't seem to understand the
> point I am making about multiple incompatible metrics for
> complexity>>
> 
> >
> > Has anyone written such an informal description of Ada83
> > as well?  I never saw such a description, simple yet
> > possible to program from, and one has
> > to wonder if it's possible to write such a thing.
> 
> One does not have to wonder there are several elementary
> Ada texts around!
> 
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own

Re: Ada vs C++ vs Java

[robert_dewar]

In article
<gwinn-2001992141150001@d119.dial-2.cmb.ma.ultra.net>,
  gwinn@ma.ultranet.com (Joe Gwinn) wrote:
> Well, I can always depend on Robert for a fight...

I find it an odd habit for people to confuse an argument
with a fight. Despite having been in this country for
many years, it is hard to get used to the idea that
people regard argument as a negative word, and indeed
consider it more or less equivalent to a fight. Odd ....

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Joe Gwinn]

In article <787f6m$jnh$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com
wrote:

> In article
> <gwinn-2001992141150001@d119.dial-2.cmb.ma.ultra.net>,
>   gwinn@ma.ultranet.com (Joe Gwinn) wrote:
> > Well, I can always depend on Robert for a fight...
> 
> I find it an odd habit for people to confuse an argument
> with a fight. Despite having been in this country for
> many years, it is hard to get used to the idea that
> people regard argument as a negative word, and indeed
> consider it more or less equivalent to a fight. Odd ....

Yes, "argument" and "fight" are essentially synonyms in this context,
implying the presence of some anger, while "debate" implies a cooler, more
controlled exchange.  Debates generally lack ad-hominem arguments, as
well.

So, listen to the tone of your postings (not just the logic of the
arguments), and you may understand the reaction.

Joe Gwinn

Re: Ada vs C++ vs Java

[Ola Liljedahl]

robert_dewar@my-dejanews.com wrote:
> 
<SNIP>
> > Assembly language is simpler than any high-order
> > language, but it's lots more work to code in assembly.
> 
> Now let me guess. The last time you looked at machine
> language was in the 80's, right? Yes, in those days, the
> semantics of machine language was pretty simple.
> 
> I am afraid that things have changed. At this stage the
> full execution semantics of a modern chip with extensive
                 ^^^^^^^^^
> instruction-level parallelism is remarkably complex along
> ALL the dimensions I mention above. A chip like the Pentium
> II, if you include efficiency issues, which are indeed not
> fully documented publicly, let alone formally specified,
> you have something far MORE complicated than any of the
> languages we are talking about here.

Wrong. The semantics of the assembly level instructions is
for all CPU architectures I know of (68K, SPARC, PowerPC)
extremely simple. The semantics is that of a sequential
execution of instructions where each instruction complete
before the next is executed. That a particual implementation
is actually pre-fetching instructions, using branch prediction,
out of order issue and completion etc etc etc does NOT affect
the semantics. All these implementation details ONLY affect
the performance of the implementation, not the semantics.

The only parts of the architecture/implementation that changes
the semantics for these architectures is the delayed (imprecise)
exceptions for floating point operations and the advanced memory
models (Partial Store Order, Relaxed Memory Order) that some
implementations might have. Ok, maybe I missed some other (minor)
aspect, please correct me.
--
	Ola Liljedahl
	olli@enea.se

Instruction Set Semantics

[Nick Roberts]

I think we're getting into an argument about the finer points of terminology
here.

If you take the word 'semantics' to mean the 'meaning' of something, i.e.
'what it does', then you _could_ include the time it takes for an
instruction to execute, as well as what it actually does, to be a part of
its semantics.

I believe, purely by convention, that the word 'semantics' in this kind of
context is usually intended to mean "what the instruction does, but not how
fast it does it". But, like most computer terminology, it's a question of
loose convention, and not set in stone anywhere.

Clearly, in his post, Robert Dewar meant "what the instruction does, and how
fast it does it" when he used the word 'semantics'.

And as for the little differences in semantics (what the instruction does,
but not how fast it does it) between different versions of superscalar
processors: the 'little differences' go on and on ;-)

-------------------------------------------
Nick Roberts
-------------------------------------------

Ola Liljedahl wrote in message <36AEDCEE.23964EF7@enea.se>...
|robert_dewar@my-dejanews.com wrote:
[...]
|> I am afraid that things have changed. At this stage the
|> full execution semantics of a modern chip with extensive
|                 ^^^^^^^^^
|Wrong. The semantics of the assembly level instructions is
[...]

Re: Instruction Set Semantics

[robert_dewar]

In article <78o59b$31a$1@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> And as for the little differences in semantics (what the
> instruction does, but not how fast it does it) between
> different versions of superscalar processors: the 'little
> differences' go on and on ;-)

Indeed! As an example, we just had to work in emergency
mode to fix an important bug for SGI. It turns out that an
instruction to convert integer to float on the R10000 is
not fully implemented, and traps to the operating system if
the absolute magnitude of the integer exceeds 2**53. The
operating system correctly interprets the intent in the
trap routine.

BUT, it takes for ever to do it. Since in the real world,
people ARE concerned about how long things take (and not
just the semantics in some pure sense :-) this caused
serious performance problems, and we had to change the
compiler to avoid generating these traps.

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Scott Johnson]

Ola Liljedahl wrote:
> 
> robert_dewar@my-dejanews.com wrote:
> >
> <SNIP>
> > > Assembly language is simpler than any high-order
> > > language, but it's lots more work to code in assembly.
> >
> > Now let me guess. The last time you looked at machine
> > language was in the 80's, right? Yes, in those days, the
> > semantics of machine language was pretty simple.
> >
> > I am afraid that things have changed. At this stage the
> > full execution semantics of a modern chip with extensive
>                  ^^^^^^^^^
> > instruction-level parallelism is remarkably complex along
> > ALL the dimensions I mention above. A chip like the Pentium
> > II, if you include efficiency issues, which are indeed not
> > fully documented publicly, let alone formally specified,
> > you have something far MORE complicated than any of the
> > languages we are talking about here.
> 
> Wrong. The semantics of the assembly level instructions is
> for all CPU architectures I know of (68K, SPARC, PowerPC)
> extremely simple. The semantics is that of a sequential
> execution of instructions where each instruction complete
> before the next is executed. That a particual implementation
> is actually pre-fetching instructions, using branch prediction,
> out of order issue and completion etc etc etc does NOT affect
> the semantics. All these implementation details ONLY affect
> the performance of the implementation, not the semantics.

Not always true.

For acessing RAM, which does not suffer from out-of-order or speculative
accesses, the above is true.

However, writers of device drivers for RISC machines had BETTER know
what they are doing--a speculative fetch that is harmless when done
to RAM may crash the system (or do something else nasty) when done
to a register.  Fortunately, the processors have instructions to 
enforce in-order execution, and ways (usually via the MMU) to mark
regions of memory as guarded (to disable speculative access).

Anybody who write a device driver for the PowerPC, though, and who 
intends to have the MMU enabled, had best make LIBERAL use of the 
EIEIO instruction.   (That mnemonic is proof that SOMEONE at IBM has
a sense of humor...)

Need I mention architectures with branch delay slots and other 
"let the compiler figure it out" violations of the sequential execution
model???


Scott

Re: Ada vs C++ vs Java

[robert_dewar]

In article <36AEDCEE.23964EF7@enea.se>,
  Ola Liljedahl <olli@enea.se> wrote:

> Wrong. The semantics of the assembly level instructions
> is for all CPU architectures I know of

You are playing Humpty Dumpty here :-) [arguing about
meaning of words]

I was using semantics here to include timing as part of
the specification. Since one of the major motivations for
writing in assembly language is performance, it is
generally not very helpful to ignore timing issues.

Anyway, in saying that assembly language was a complex
programming environment, I was specifically referring to
the scenario where you are programming in assembly language
and the performance is an important part of the spec.

I see this is posted to comp.lang.ada, comp.vxworks and
comp.realtime. I would think that the notion of time being
part of the critical semantics of a program is not a
completely foreign notion to the readers of these groups
:-)



-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Bjarne Stroustrup]

johnb@invision.co.uk (John Birch) writes:

 > There are many embedded programmers who regard the concept of dynamic
 > memory allocation in an embedded system as laughable at best and a
 > terminal offence at worst.

For many embedded systems this is clearly true. For other embedded systems
some limited and controlled forms of (special purpose) dynamic allocation
are acceptable. (``embedded systems'' is a term that covers a lot of
diverse applications).


 > If you restict C++ in such a way (i.e.
 > prevented the use of dynamic memory allocation) you'd pretty much end
 > up with C anyway!

This is simply wrong. The better type checking, uses of classes for concrete
types and many forms of data abstraction, and templates do not depend on
dynamic memory. You can even use polymorphism to simplify code using
statically allocated objects of a variety of types.

Many embedded programs have been written in C++ styles that go way beyond
the styles directly supported by C.


 > > Since C is "for all practical purposes" (as Bjarne Stroustrup puts it)
 > > a subset of C++, there is no reason why C should be a better choice, 
 > > providing compilers are available for both languages. Whether certain 
 > > *features* of C++ such as templates or exceptions can be reasonably used
 > > on embedded systems is a matter of debate.

Here is the way I address the "Is C a subset of C++?" question in my FAQ:

	In the strict mathematical sense, C isn't a subset of C++.
	There are programs that are valid C but not valid C++ and even
	a few ways of writing code that has a different meaning in C
	and C++. However, C++ supports every programming technique
	supported by C. Every C program can be written in essentially
	the same way in C++ with the same run-time and space efficiency.
	It is not uncommon to be able to convert tens of thousands
	of lines of ANSI C to C-style C++ in a few hours. Thus, C++ is
	as much a superset of ANSI C as ANSI C is a superset of K&R C
	and much as ISO C++ is a superset of C++ as it existed in 1985.

(this is followed by examples).


 > Except that a perfectly valid ANSI C program need not compile or
 > execute correctly under C++. Consequently, if it's a subset, it's a
 > pretty poor one!

In the context of embedded systems, consider the two most annoying
incompatibilities when you consider C as a ``for practical purposes''
subset of C++:

	If you don't use function prototypes in C, your program won't
	compile as C++ - and most would consider the program sloppy
	for having failed to use the type safety offered by the prototypes.

	If you don't cast the result of malloc() and realloc(), your
	program won't compile as C++ - and for many/most embedded
	applications you shouldn't use malloc() anyway.

	- Bjarne
Bjarne Stroustrup - http://www.research.att.com/~bs

Re: Ada vs C++ vs Java

[John Birch]

Bjarne Stroustrup wrote in message ...

>johnb@invision.co.uk (John Birch) writes:

> > There are many embedded programmers who regard the concept of dynamic
> > memory allocation in an embedded system as laughable at best and a
> > terminal offence at worst.

>For many embedded systems this is clearly true. For other embedded systems
>some limited and controlled forms of (special purpose) dynamic allocation
>are acceptable. (``embedded systems'' is a term that covers a lot of
>diverse applications).


Indeed, but my personal experience is with small embedded hard real-time
systems. In such a problem domain the above statement I feel holds true.


> > If you restict C++ in such a way (i.e.
> > prevented the use of dynamic memory allocation) you'd pretty much end
> > up with C anyway!

>This is simply wrong. The better type checking, uses of classes for
concrete
>types and many forms of data abstraction, and templates do not depend on
>dynamic memory. You can even use polymorphism to simplify code using
>statically allocated objects of a variety of types.

The use of C++ without dynamically allocated classes will obviously provide
extra featues over C. The issue as to whether it is better to use a
'crippled' C++ is a question of debate and will surely depend on the problem
to be solved and the calibre and organisation of the team of programmers
working on it. In my experience, the restriction of language features in a
project is difficult to control.

I agree my original statement was somewhat inflamatory though <abashed
emoticon>


>Many embedded programs have been written in C++ styles that go way beyond
>the styles directly supported by C.

> > > Since C is "for all practical purposes" (as Bjarne Stroustrup puts it)
> > > a subset of C++, there is no reason why C should be a better choice,
> > > providing compilers are available for both languages. Whether certain
> > > *features* of C++ such as templates or exceptions can be reasonably
used
> > > on embedded systems is a matter of debate.

>Here is the way I address the "Is C a subset of C++?" question in my FAQ:

> In the strict mathematical sense, C isn't a subset of C++.
> There are programs that are valid C but not valid C++ and even
> a few ways of writing code that has a different meaning in C
> and C++. However, C++ supports every programming technique
> supported by C. Every C program can be written in essentially
> the same way in C++ with the same run-time and space efficiency.
> It is not uncommon to be able to convert tens of thousands
> of lines of ANSI C to C-style C++ in a few hours. Thus, C++ is
> as much a superset of ANSI C as ANSI C is a superset of K&R C
> and much as ISO C++ is a superset of C++ as it existed in 1985.

The comment I made was to pick up on the use of the term subset. Your quote
above qualifies the statement perfectly and it is perhaps a pity it was not
included in the originally post :-)

> > Except that a perfectly valid ANSI C program need not compile or
> > execute correctly under C++. Consequently, if it's a subset, it's a
> > pretty poor one!

>In the context of embedded systems, consider the two most annoying
>incompatibilities when you consider C as a ``for practical purposes''
>subset of C++:

> If you don't use function prototypes in C, your program won't
> compile as C++ - and most would consider the program sloppy
> for having failed to use the type safety offered by the prototypes.

> If you don't cast the result of malloc() and realloc(), your
> program won't compile as C++ - and for many/most embedded
> applications you shouldn't use malloc() anyway.

Agreed, any C program that would not compile with minimal changes under C++
would be one that I would not be over proud of!

Finally, It was never my intention to denigrate your efforts in the
development of the C++ language, rather I wished to emphasise that there is
a spectrum of tools and a spectrum of problems. Not all tools fit best
against all problems. Unfortunately, there seems to be a bit of 'If the only
tool in the toolbox is a hammer, then everything looks like a nail' in the
choice of languages for a project.

Re: Ada vs C++ vs Java

[James Kanze]

John Birch wrote:

|> On Thu, 14 Jan 1999 13:06:27 +0100, Gerhard Menzl
|> <gerhard.menzl@sea.ericsson.se> wrote:

|> >Erik Funkenbusch wrote:
|> >
|> >> >- be suitable for design of embedded systems
|> >>
|> >> C++ generally isn't.  There is an "embedded C++" that's in the works, and
|> >> there might even be some implementations.  C is better for embedded work
|> >> than C++.
|> >
|> >This claim is completely unfounded.

|> There are many embedded programmers who regard the concept of dynamic
|> memory allocation in an embedded system as laughable at best and a
|> terminal offence at worst. If you restict C++ in such a way (i.e.
|> prevented the use of dynamic memory allocation) you'd pretty much end
|> up with C anyway!

Not really.  I've done a lot of embedded system work in the past.  I
agree that for many applications, any use of dynamic memory is out (and
for most others, a significant part of the code is in a critical path
where use of dynamic memory is out).  But C++ without dynamic memory is
still a win.  If only because of the access controls.  (While most use
of polymorphism is based on dynamic memory, there are cases where it too
can be useful without dynamic memory.  For example, very system I've
seen emulates virtual functions in one way or another for low level
hardware access.)

|> Since I do not regard dynamic memory allocation as a _good_ thing for
|> most hard embedded systems, I find this claim well founded :-)

|> > Since C is "for all practical purposes" (as Bjarne Stroustrup puts
|> >it) a subset of C++, there is no reason why C should be a better
|> >choice, providing compilers are available for both
|> >languages. Whether certain *features* of C++ such as templates or
|> >exceptions can be reasonably used on embedded systems is a matter of
|> >debate.

Curiously enough, templates are one of the features which could be used
on an embedded system.  If anyone ever figures out how they work.

|> Except that a perfectly valid ANSI C program need not compile or
|> execute correctly under C++. Consequently, if it's a subset, it's a
|> pretty poor one!

While it is easy to conceive of valid C programs which will not compile
as C++, well written, maintainable C programs which don't compile are
the exception.

In practice, the only reason I can think of why one might prefer C over
C++ in an embedded environment is tha availability of compilers.  And of
course, for what you seem to mean by "embedded programs", Java is out,
and Ada is probably better than C++.

--
James Kanze                                           GABI Software, S�rl
Conseils en informatique orient� objet  --
                          --  Beratung in industrieller Datenverarbeitung
mailto: kanze@gabi-soft.fr          mailto: James.Kanze@dresdner-bank.com

Re: Ada vs C++ vs Java

[John Birch]

James Kanze wrote in message <369F0592.94F9DDDA@dresdner-bank.com>...

>|> On Thu, 14 Jan 1999 13:06:27 +0100, Gerhard Menzl
>|> <gerhard.menzl@sea.ericsson.se> wrote:
>|> There are many embedded programmers who regard the concept of dynamic
>|> memory allocation in an embedded system as laughable at best and a
>|> terminal offence at worst. If you restict C++ in such a way (i.e.
>|> prevented the use of dynamic memory allocation) you'd pretty much end
>|> up with C anyway!

>Not really.  I've done a lot of embedded system work in the past.  I
>agree that for many applications, any use of dynamic memory is out (and
>for most others, a significant part of the code is in a critical path
>where use of dynamic memory is out).  But C++ without dynamic memory is
>still a win.  If only because of the access controls.  (While most use
>of polymorphism is based on dynamic memory, there are cases where it too
>can be useful without dynamic memory.  For example, very system I've
>seen emulates virtual functions in one way or another for low level
>hardware access.)

I'm not sure I would like to use a cut down C++ for an embedded system if it
wasn't a supported 'standard'. I'm still looking into EC++ but for all
intents and purposes it looks as if only the size of executable issue has
been addressed rather than the restriction of features that __I__ consider
unsafe.

>|> Since I do not regard dynamic memory allocation as a _good_ thing for
>|> most hard embedded systems, I find this claim well founded :-)

>|> > Since C is "for all practical purposes" (as Bjarne Stroustrup puts
>|> >it) a subset of C++, there is no reason why C should be a better
>|> >choice, providing compilers are available for both
>|> >languages. Whether certain *features* of C++ such as templates or
>|> >exceptions can be reasonably used on embedded systems is a matter of
>|> >debate.

The reason IMHO is that C++ inherently relies upon dynamic memory
allocation! It's really as simple as that. If you can show me how to
calculate the maximum amount of memory required by a given C++ program then
I'll reconsider, until then I'll continue using C without malloc and free!

>Curiously enough, templates are one of the features which could be used
>on an embedded system.  If anyone ever figures out how they work.

>|> Except that a perfectly valid ANSI C program need not compile or
>|> execute correctly under C++. Consequently, if it's a subset, it's a
>|> pretty poor one!

>While it is easy to conceive of valid C programs which will not compile
>as C++, well written, maintainable C programs which don't compile are
>the exception.

Agreed.

>In practice, the only reason I can think of why one might prefer C over
>C++ in an embedded environment is tha availability of compilers.  And of
>course, for what you seem to mean by "embedded programs", Java is out,
>and Ada is probably better than C++.

Re: Ada vs C++ vs Java

[Matthew Heaney]

"John Birch" <johnb@invision.co.uk> writes:

> The reason IMHO is that C++ inherently relies upon dynamic memory
> allocation! It's really as simple as that. If you can show me how to
> calculate the maximum amount of memory required by a given C++ program then
> I'll reconsider, until then I'll continue using C without malloc and free!

When does C++ "inherently rely upon dynamic memory allocation"?

Re: Ada vs C++ vs Java

[phil]

On Sun, 17 Jan 1999 06:53:08 GMT, Matthew Heaney
<matthew_heaney@acm.org> wrote:

>"John Birch" <johnb@invision.co.uk> writes:
>
>> The reason IMHO is that C++ inherently relies upon dynamic memory
>> allocation! It's really as simple as that. If you can show me how to
>> calculate the maximum amount of memory required by a given C++ program then
>> I'll reconsider, until then I'll continue using C without malloc and free!
>
>When does C++ "inherently rely upon dynamic memory allocation"?
>
OK, it doesn't, but i think that one of the potential problems is that
dynamic allocation has been easily facilitated and also potentially
quite well hidden. A bigger concern i have is over the use of library
functions that either come with the compiler or are available from
third party vendors that may well get involved in their own allocation
strategies (and it is becoming difficult to police their use).

However, i also agree that unless you really know what the compiler is
up to, you may well be doing dynamic allocation on the heap or the
stack without actually being aware of the fact through any sort of
explicit indication.

My memory allocation scheme has always been to either statically
obtain the memory i need within the image map or obtain it during
system startup and fail if unsucessful if an inability to obtain the
memory at run time would lead to a critical failure. An unsuspecting
use or abuse of a string class or whatever could compromise this quite
easily, even maybe a function call where some sort of copy constructor
is involved (compromising the stack for example).

I think C++ is a really enjoyable language, but its abstractions are
certainly higher than C and it does come with an attitude.

phil.

Re: Ada vs C++ vs Java

[robert_dewar]

In article <36a1b97d.54731940@news.ricochet.net>,
  phil@ricochet.net (phil) wrote:
> However, i also agree that unless you really know what
> the compiler is up to, you may well be doing dynamic
> allocation on the heap or the stack without actually
> being aware of the fact through any sort of explicit
> indication.

Indeed this is a good point, and there is nothing in the
C++ standard that stops the compiler from generating calls
to allocate memory dynamically at any point. Of course the
same could be said of C, but we have much less reason to
think that a C compiler might be playing such games.

Ada deals with this by providing a standardized pragma:

  pragma Restrictions (No_Implicit_Heap_Allocations);

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[John Birch]

On Sun, 17 Jan 1999 06:53:08 GMT, Matthew Heaney
<matthew_heaney@acm.org> wrote:

>"John Birch" <johnb@invision.co.uk> writes:
>
>> The reason IMHO is that C++ inherently relies upon dynamic memory
>> allocation! It's really as simple as that. If you can show me how to
>> calculate the maximum amount of memory required by a given C++ program then
>> I'll reconsider, until then I'll continue using C without malloc and free!
>
>When does C++ "inherently rely upon dynamic memory allocation"?
>
OK, say I have the following;

Complex one (1), Complex two (2), Complex three (3), Complex four (4);

Complex Sum;

Sum = one + two + three + four;

If Complex is a class with an overloaded + operator, I get temporary
objects generated (possibly at the compiler's option) in the above
statement. Since it can be written as;

Sum = operator + (operator + (operator +(one, two), three), four);

Now where do these temporary objects get created? On the stack, or on
the heap.

In C the stack size (without recursion) can never grow beyond the
maximum of the total of the stack requirements of all of the functions
defined.

How do I calculate the potential stack size in C++?

There is inherent dynamic memory allocation going on here, it is
irrelevant whether it is satck or heap. I (the coder) did not
explicitly allocate memory, the language (or rather the implementation
of the language) did.

regards John B.

Re: Ada vs C++ vs Java

[robert_dewar]

In article <36a3281a.11980677@news.demon.co.uk>,
  johnb<nospam>@invision.co.uk wrote:
> If Complex is a class with an overloaded + operator, I
> get temporary objects generated (possibly at the
> compiler's option) in the above statement.

> Now where do these temporary objects get created? On the
> stack, or on the heap.

It is hard to imagine a compiler so incompetent as to
generate such temporaries on the heap. Of course there is
no guarantee of this from the standard, which is not at
this kind of implementation level.
>
> In C the stack size (without recursion) can never grow
> beyond the maximum of the total of the stack requirements
> of all of the functions defined.

That is of course true in C++ (and for that matter all
stack based languages) as well.


> How do I calculate the potential stack size in C++?

The same way you do in C, you have to find out how much
stack each function is using. I hope you don't think that
in C you can know this at the source level by looking at
the number of local variables. It is hard to believe that
any programmer would be so oblivious of what is going on
at code generation time to believe this, but apparently
you do from what you right. There are many reasons a C
compiler might generate temporary locations on the stack,
e.g. for register spill.

You have to either read the assembly language to see what
the compiler is generating, or use some tool to get this
information. Getting the information from the source
program is not possible for C or C++.

> There is inherent dynamic memory allocation going on
> here, it is irrelevant whether it is satck or heap. I
> (the coder) did not explicitly allocate memory, the
> language (or rather the implementation of the language)
> did.

You have a model of computation that is just plain wrong,
probably because you don't know enough about computer
architecture.

(start of plug)
A good reference for you might be my book
on Microprocessors, since this addressed to programmers.
McGraw Hill, 1990, "Microprocessors: A Programmer's View"
Look for the soft cover version, the hard cover version is
out of print
(end of plug)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Dynamic memory? (was Re: Ada vs C++ vs Java)

[Martijn Lievaart]

John Birch wrote in message <36a3281a.11980677@news.demon.co.uk>...
>On Sun, 17 Jan 1999 06:53:08 GMT, Matthew Heaney
><matthew_heaney@acm.org> wrote:
>
>>"John Birch" <johnb@invision.co.uk> writes:
>>
>>> The reason IMHO is that C++ inherently relies upon dynamic memory
>>> allocation! It's really as simple as that. If you can show me how to
>>> calculate the maximum amount of memory required by a given C++ program
then
>>> I'll reconsider, until then I'll continue using C without malloc and
free!
>>
>>When does C++ "inherently rely upon dynamic memory allocation"?
>>
>OK, say I have the following;
>
>Complex one (1), Complex two (2), Complex three (3), Complex four (4);
>
>Complex Sum;
>
>Sum = one + two + three + four;
>
>If Complex is a class with an overloaded + operator, I get temporary
>objects generated (possibly at the compiler's option) in the above
>statement. Since it can be written as;
>
>Sum = operator + (operator + (operator +(one, two), three), four);
>
>Now where do these temporary objects get created? On the stack, or on
>the heap.
>
>In C the stack size (without recursion) can never grow beyond the
>maximum of the total of the stack requirements of all of the functions
>defined.
>
>How do I calculate the potential stack size in C++?
>
>There is inherent dynamic memory allocation going on here, it is
>irrelevant whether it is satck or heap. I (the coder) did not
>explicitly allocate memory, the language (or rather the implementation
>of the language) did.
>


Well, you can take it to far! If you count this as dynamic memory
allocation, you cannot use any one function as it will dynamically allocate
a stackframe (hint: the "allocated memory" refered to above is also in the
stack frame). Gets kinda hard to write a C program without any function!

Martijn
--
My reply-to address is intentionally set to /dev/null
reply to mlievaart at orion in nl

Re: Dynamic memory? (was Re: Ada vs C++ vs Java)

[John Birch]

On 18 Jan 1999 13:24:09 GMT, "Martijn Lievaart" <nobody@orion.nl>
wrote:


>>There is inherent dynamic memory allocation going on here, it is
>>irrelevant whether it is satck or heap. I (the coder) did not
>>explicitly allocate memory, the language (or rather the implementation
>>of the language) did.

>Well, you can take it to far! If you count this as dynamic memory
>allocation, you cannot use any one function as it will dynamically allocate
>a stackframe (hint: the "allocated memory" refered to above is also in the
>stack frame). Gets kinda hard to write a C program without any function!

What would you call it then? It's not statically allocated, it's
allocated dynamically at run-time from the stack or the heap. It's
certainly memory, so it seems reasonable to call this dynamically
allocated memory.

Now of course a function call involves the stack and results in
dynamic memory allocation,

BUT....

With no recursion,

In C the stack size can never be larger the maximum of the total of
the stack requirements of all of the functions defined.

In other words, the worst case stack usage is if main called a
function, which called a function, which called a function .......

...... until all the functions in the program had been called.

This value is easy to determine, indeed many embedded C compilers
calculate it for you. If you know what the maximum stack size your
program uses is, then you can guarantee, barring bugs, that your
program will run on target machine with that amount (or more) of free 
memory.

Now try telling me how to calculate a worst case C++ memory
requirement.


regards John B.

Re: Dynamic memory? (was Re: Ada vs C++ vs Java)

[Ken Keys]

John Birch wrote:

> In C the stack size can never be larger the maximum of the total of
> the stack requirements of all of the functions defined.

And the heap requirements can never be larger than the maximum of the
total of the heap requirements of all of the functions defined. Indeed
in that case even fragmentation is not an issue because you can assume
that memory is never freed and just add up all the allocations.


> Now try telling me how to calculate a worst case C++ memory
> requirement.

I don't see how the equation would be any different in C++ than in C
except that there is a tendency to use the heap more in C++. 

In C it is considered bad form to allocate really big data structures on
the stack but there is nothing in the language that prevents it. If you
limit the stack usage to the most benign objects and put the big stuff
on the heap, it makes your worst case stack look better. 

The only problem is that if you extend the analysis to all types of
memory allocations and you use some big objects, your worst case figure
can be much larger than what the system would reasonably need. 

KLK

Re: Dynamic memory? (was Re: Ada vs C++ vs Java)

[Scott Johnson]

Ken Keys wrote:
> 
> John Birch wrote:
> 
> > In C the stack size can never be larger the maximum of the total of
> > the stack requirements of all of the functions defined.
> 
> And the heap requirements can never be larger than the maximum of the
> total of the heap requirements of all of the functions defined. Indeed
> in that case even fragmentation is not an issue because you can assume
> that memory is never freed and just add up all the allocations.

Except for one thing:

Consider the following function:

int *get_an_array_of_ints (int size) {
    int *retval;

    retval = (int *) malloc (size * sizeof(int)); 
    if (!retval)
	printf ("Oh shit.  Out of memory.\n");

    return retval;
}

The amount of stack space this needs can be determined at compile time--
and is likely very small for this function.  (Little more than a frame
pointer; all of the variables can likely fit in registers if the
optimizer is turned on, and you are not using certain brain-dead
processors, commonly found "inside").  :)

The amount of heap needed by this function depends on the input
parameter, and is unbounded.

At any rate, trying to statically analyze a program (in the general
case) for heap requirements is, as CS profs like to put it,
"computationally equivalent to the halting problem."

In other words, mathematically impossible.  (At least its impossible
to do so in a finite amount of time; most project managers I know 
would be rather unhappy were the schedule to slip to the Apocolypse and
beyond while dynamic memory requirements were being analyzed.)
 
> > Now try telling me how to calculate a worst case C++ memory
> > requirement.
 
> I don't see how the equation would be any different in C++ than in C
> except that there is a tendency to use the heap more in C++.

'Tis the only real difference.  Outside possibly of exceptions, I
cannot think of any language feature that results in new() or delete()
being called behind the scenes (or that needs to, at least.)
 
> In C it is considered bad form to allocate really big data structures > on the stack but there is nothing in the language that prevents it. If > you limit the stack usage to the most benign objects and put the big 
> stuff on the heap, it makes your worst case stack look better.

Of course, 'tis doesn't matter if you run out of stack or out of heap.

Running out of either is fatal for many an embedded system.
 

Scott

Re: Dynamic memory? (was Re: Ada vs C++ vs Java)

[Martijn Lievaart]

John Birch wrote in message <36a34176.18473393@news.demon.co.uk>...
>On 18 Jan 1999 13:24:09 GMT, "Martijn Lievaart" <nobody@orion.nl>
>wrote:
>
>
>>>There is inherent dynamic memory allocation going on here, it is
>>>irrelevant whether it is satck or heap. I (the coder) did not
>>>explicitly allocate memory, the language (or rather the implementation
>>>of the language) did.
>
>>Well, you can take it to far! If you count this as dynamic memory
>>allocation, you cannot use any one function as it will dynamically
allocate
>>a stackframe (hint: the "allocated memory" refered to above is also in the
>>stack frame). Gets kinda hard to write a C program without any function!
>
>What would you call it then? It's not statically allocated, it's
>allocated dynamically at run-time from the stack or the heap. It's
>certainly memory, so it seems reasonable to call this dynamically
>allocated memory.
>
>Now of course a function call involves the stack and results in
>dynamic memory allocation,
>
>BUT....
>
>With no recursion,
>
>In C the stack size can never be larger the maximum of the total of
>the stack requirements of all of the functions defined.
>
>In other words, the worst case stack usage is if main called a
>function, which called a function, which called a function .......
>
>...... until all the functions in the program had been called.
>
>This value is easy to determine, indeed many embedded C compilers
>calculate it for you. If you know what the maximum stack size your
>program uses is, then you can guarantee, barring bugs, that your
>program will run on target machine with that amount (or more) of free
>memory.
>
>Now try telling me how to calculate a worst case C++ memory
>requirement.
>


It is more difficult, but the temporaries in the example above are also
allocated on the stack, so the same argument as in the C case still holds.
In fact, the C compiler is also free to generate temporaries on the stack
and often does so. I think that the main reason why the compiler/linker will
calculate the maximum stacksize for you (the embedded scenario you
described) is not as a convenience to users, but because the user cannot
know in advance what stack usage his program has. Only the compiler knows
this.

Let me repeat, this is exactly the same as a C compiler. F.i. take the
following code.

int f(int i1, int i2, int i3)
{
    return i1+i2+i3;
}

On a register poor machine (not likely, but it might) this certainly will
allocate temporaries on the stack. This is exactly the same as the example
that started this thread, only no function calls to an user defined operator
but a hardcore integer-add instruction. But *no more* dynamic memory
allocation than in this C example. (yeah, user defined operators are
function calls, so these take a stack frame, but that is the same as you
calling a function in C, i.e. predictable and reportable by the compiler).
Not even mentioning the fact that a good (embedded) C++ compiler might even
only use registers in most cases.

In fact, C++ will *never* dynamically allocate memory on your behalf if you
don't explicitly tell it to. The RTL, maybe, will ask specificly, but not
the language itself. And that is *exactly* the same as C. I remember
Stroustrup commenting on this as one of the myths hardcore C programmers
have against C++, but I'm to lazy to look it up right now so don't quote me
on it (yet).

Mind you, I'm not saying C++ is a better or even viable alternative, but I
do want to get these myths out of the way.

HTH
Martijn
--
My reply-to address is intentionally set to /dev/null
reply to mlievaart at orion in nl

Re: Dynamic memory? (was Re: Ada vs C++ vs Java)

[John Birch]

On 18 Jan 1999 14:59:46 GMT, "Martijn Lievaart" <nobody@orion.nl>
wrote:


>>Complex one (1), Complex two (2), Complex three (3), Complex four (4);

>>Complex Sum;

>>Sum = one + two + three + four;

>>If Complex is a class with an overloaded + operator, I get temporary
>>objects generated (possibly at the compiler's option) in the above
>>statement. Since it can be written as;

>>Sum = operator + (operator + (operator +(one, two), three), four);

>>Now try telling me how to calculate a worst case C++ memory
>>requirement.

>It is more difficult, but the temporaries in the example above are also
>allocated on the stack, so the same argument as in the C case still holds.

No, it does not! The temporary objects created above are as a result
of calls to an object constructor. There is no parallel in C to a
constructor. The only stack usage in C results from function calling.

>In fact, the C compiler is also free to generate temporaries on the stack
>and often does so.

Whilst it may use the stack space for temporary values, this space is
pre-allocated in the stack requirements for any given function call. A
C compiler AFAIK will never extend the size of the stack frame within
a given function.

> I think that the main reason why the compiler/linker will
>calculate the maximum stacksize for you (the embedded scenario you
>described) is not as a convenience to users, but because the user cannot
>know in advance what stack usage his program has. Only the compiler knows
>this.

No, the main reason is exactly as I stated it, it is to tell embedded
programmers how much stack space a program will use. The value of the
stack space as calculated by the compiler is used by the linker to
locate various portions of the code generated by the compiler and to
check that heap, initialised data and stack space do not overflow
available memory. 

>Let me repeat, this is exactly the same as a C compiler. F.i. take the
>following code.

>int f(int i1, int i2, int i3)
>{
>    return i1+i2+i3;
>}

>On a register poor machine (not likely, but it might) this certainly will
>allocate temporaries on the stack.

Yes it might, but the compiler will include any stack space it is
using as registers into the stack requirements for function f(). In
the C++ example the compiler may not know how big the temporary
objects are going to be.

> This is exactly the same as the example
>that started this thread, only no function calls to an user defined operator
>but a hardcore integer-add instruction.

As I've shown it is in fact different!

> But *no more* dynamic memory
>allocation than in this C example. (yeah, user defined operators are
>function calls, so these take a stack frame, but that is the same as you
>calling a function in C, i.e. predictable and reportable by the compiler).
>Not even mentioning the fact that a good (embedded) C++ compiler might even
>only use registers in most cases.

>In fact, C++ will *never* dynamically allocate memory on your behalf if you
>don't explicitly tell it to. 

This depends on your definition of explicit. In order to code the
above example, the operator + function has to call operator new
(indeed it has to be a friend function too). So there is an explicit
call to allocate memory. The point I am trying to make is how do you
work out how much memory is used by a C++ program?

>The RTL, maybe, will ask specificly, but not
>the language itself. And that is *exactly* the same as C.

It is a language feature (operator overloading) that creates the
problem in the first place by encouraging such coding styles. One of
the core tenets of C programming is the 'nothing up my sleeve'
approach, C++ does not have this requirement that the programmer has
visibility of every action taken by the code. This I feel is a major
disadvantage when coding for resource limited hardware. 

> I remember
>Stroustrup commenting on this as one of the myths hardcore C programmers
>have against C++, but I'm to lazy to look it up right now so don't quote me
>on it (yet).

I'd love to see it if you can find it.

>Mind you, I'm not saying C++ is a better or even viable alternative, but I
>do want to get these myths out of the way.

Calling it a myth does not make it go away ;-)


regards John B.

Re: Dynamic memory? (was Re: Ada vs C++ vs Java)

[James Kanze]

John Birch wrote:
|> On 18 Jan 1999 14:59:46 GMT, "Martijn Lievaart" <nobody@orion.nl>
|> wrote:


|> >>Complex one (1), Complex two (2), Complex three (3), Complex four (4);

|> >>Complex Sum;

|> >>Sum = one + two + three + four;

|> >>If Complex is a class with an overloaded + operator, I get temporary
|> >>objects generated (possibly at the compiler's option) in the above
|> >>statement. Since it can be written as;

|> >>Sum = operator + (operator + (operator +(one, two), three), four);

|> >>Now try telling me how to calculate a worst case C++ memory
|> >>requirement.

|> >It is more difficult, but the temporaries in the example above are also
|> >allocated on the stack, so the same argument as in the C case still holds.

|> No, it does not! The temporary objects created above are as a result
|> of calls to an object constructor.

The temporary objects are allocated on the stack by the compiler.  The
constructor has nothing to do with allocating the object itself.  It is
just another function that is called on the "object" (with the
difference that if it exists, it is the first function called, and so
must be able to deal with raw memory).

|> There is no parallel in C to a
|> constructor. The only stack usage in C results from function calling.

The constructor is a function; the only stack usage in C++ results from
function calling.

|> >In fact, the C compiler is also free to generate temporaries on the stack
|> >and often does so.

|> Whilst it may use the stack space for temporary values, this space is
|> pre-allocated in the stack requirements for any given function call. A
|> C compiler AFAIK will never extend the size of the stack frame within
|> a given function.

It depends on what you mean by extending the size of the stack frame.
Every C compiler I've seen pushes arguments onto the stack, which is
effectively increasing the size of the stack frame.  These arguments are
removed when the function returns.  Every C++ compiler I've seen does
likewise.  No C compiler I've seen changes the size of the stack other
than this (at least when compiling C90 conformant code).  No C++
compiler I've seen either.

The only exception I've seen is to support variable length arrays.
Which only exist in C, and then, only in the current committee draft
(the basis of C99 or C20, depending on ISO paperwork).

|> > I think that the main reason why the compiler/linker will
|> >calculate the maximum stacksize for you (the embedded scenario you
|> >described) is not as a convenience to users, but because the user cannot
|> >know in advance what stack usage his program has. Only the compiler knows
|> >this.

|> No, the main reason is exactly as I stated it, it is to tell embedded
|> programmers how much stack space a program will use. The value of the
|> stack space as calculated by the compiler is used by the linker to
|> locate various portions of the code generated by the compiler and to
|> check that heap, initialised data and stack space do not overflow
|> available memory.

There is absolutely no reason why a C++ compiler could not do the same.
Perhaps they do; I've not used C or C++ on systems where it mattered.

|> >Let me repeat, this is exactly the same as a C compiler. F.i. take the
|> >following code.

|> >int f(int i1, int i2, int i3)
|> >{
|> >    return i1+i2+i3;
|> >}

|> >On a register poor machine (not likely, but it might) this certainly will
|> >allocate temporaries on the stack.

Very unliky, since you don't need any temporaries.  You need
sub-expressions to trigger spilling, e.g. (i1 + i2) * (i3 + i4).  The
compiler needs to save the results of one of the sub-expressions while
it calculates the other.

|> Yes it might, but the compiler will include any stack space it is
|> using as registers into the stack requirements for function f(). In
|> the C++ example the compiler may not know how big the temporary
|> objects are going to be.

The expression sizeof(T) is still a compile time constant in C++.  As it
used to be in C.

|> > This is exactly the same as the example that started this thread,
|> >only no function calls to an user defined operator but a hardcore
|> >integer-add instruction.

|> As I've shown it is in fact different!

Where have you shown this?

|> > But *no more* dynamic memory
|> >allocation than in this C example. (yeah, user defined operators are
|> >function calls, so these take a stack frame, but that is the same as you
|> >calling a function in C, i.e. predictable and reportable by the compiler).
|> >Not even mentioning the fact that a good (embedded) C++ compiler might even
|> >only use registers in most cases.

|> >In fact, C++ will *never* dynamically allocate memory on your behalf if you
|> >don't explicitly tell it to.

|> This depends on your definition of explicit. In order to code the
|> above example, the operator + function has to call operator new
|> (indeed it has to be a friend function too).

Why?  I've written plenty of such classes in C++, and they've never
called new.  And the C++ language *never* allows a call to new unless
the programmer has written one (or called a library function which is
allowed to call new).

The normal way of implementing return of a complex type in C++ is
exactly the same as the normal way of implementing return of a struct in
C: the calling function reserves the space (of a constant size) on the
stack, and passes an extra, hidden parameter to the called function, to
tell it where to put the return value.

|> So there is an explicit
|> call to allocate memory.

Where?  A typical implementation of operator+( Complex , Complex ) will
simply be:

    return Complex( op1.real + op2.real , op1.imag + op2.imag ) ;

No new anywhere.

|> The point I am trying to make is how do you
|> work out how much memory is used by a C++ program?

Exactly the same way you work out how much memory is used by a C
program.

|> >The RTL, maybe, will ask specificly, but not
|> >the language itself. And that is *exactly* the same as C.

|> It is a language feature (operator overloading) that creates the
|> problem in the first place by encouraging such coding styles. One of
|> the core tenets of C programming is the 'nothing up my sleeve'
|> approach, C++ does not have this requirement that the programmer has
|> visibility of every action taken by the code. This I feel is a major
|> disadvantage when coding for resource limited hardware.

This is a separate argument.  Not totally true, of course -- the first C
implementations I used regularly generated hidden function calls for
arithmetic on longs or any floating point.  Operator overloading does
mean one more thing to pay attention to, and should be used very
sparingly.  But what is the difference between C++, where Complex is a
class defined in the library, and C, where it is a built-in type (which
no doubt generates calls to library functions for multiplication or
divide)?

--
James Kanze                                           GABI Software, S�rl
Conseils en informatique orient� objet  --
                          --  Beratung in industrieller Datenverarbeitung
mailto: kanze@gabi-soft.fr          mailto: James.Kanze@dresdner-bank.com

Re: Dynamic memory? (was Re: Ada vs C++ vs Java)

[robert_dewar]

In article <36a357bb.24173519@news.demon.co.uk>,
  johnb<nospam>@invision.co.uk wrote:

> No, it does not! The temporary objects created above are
> as a result of calls to an object constructor. There is
> no parallel in C to a constructor. The only stack usage
> in C results from function calling.

This is complete nonsense, and your insistence on this
completely wrong model just emphasizes that you do not
know what is going on here. The stack is used for many
things, including alloca calls, function local variables,
block local variables, register spill, saving of
non-volatile registers, including the frame pointer ...

You really should (a) learn assembly language and (b) study
the assembler output from a C compiler.

It amazes me how many people today write in a high level
language and haven't the foggiest idea what is going on
at the code generation level!


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Dynamic memory? (was Re: Ada vs C++ vs Java)

[dennison]

In article <7803e9$825$1@nnrp1.dejanews.com>,
  robert_dewar@my-dejanews.com wrote:

> It amazes me how many people today write in a high level
> language and haven't the foggiest idea what is going on
> at the code generation level!

It probably shouldn't. Compiler courses are not *required* at any of the
accredited CS universities that I have seen. Additionally the vast majority
of my coworkers my entire carreer didn't even have a university-level CS
education.


T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Dynamic memory? (was Re: Ada vs C++ vs Java)

[robert_dewar]

In article <78069o$anf$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:

> It probably shouldn't. Compiler courses are not
> *required* at any of the accredited CS universities that
> I have seen. Additionally the vast majority of my
> coworkers my entire carreer didn't even have a
> university-level CS education.

As a university professor perhaps I should not reveal
this secret information, but amazingly it is NOT necessary
to take a compiler course, or even to have a university
level CS education to know what is going on. There are
may ways to learn critical information.

P.S. I have neither taken a compiler course nor have a
university-level CS education myself, and I think I know
*something* about compilers anyway :-)

P.P.S. At NYU, we typically expect all students to take the
compiler course, and most do.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Dynamic memory? (was Re: Ada vs C++ vs Java)

[news.oxy.com]

Generally everything is very simple.

Almost any compiler has the option of producing Assemler listing.
Anyone who wants to know what is really happening can turn on this option
and to study assembler code which will answer all the questions. This is
very interesting.
Moreover if anyone really interested to know his/her tool then he/she will
do this occasionally.
Complains that he/she does not have University education in CS are not
serious regarding this issue.
Any professional educates himself/herself when needed. University education
is only a starting point.
Any professional should be able to learn things without any coursers and to
find any needed information.
Of course I admit that there are some things that difficult to grasp without
someone help (some abstract theories that difficult to understand without
help of teacher) but  assembler is not abstract theory and there are a lot
of excellent books. I can tell that there are a lot of things that much more
complicated than simple assembler.
So if one wants to know something just go ahead and spend some time learning
new things.
I think that everything depends only on personal mentality.
Some people like to learn new things some others not.
Some people do not like to strain themselves.

Probably company that produce particular compiler should pay more attention
to this aspect and provide some manuals or help files about using assembler
with that system. Even if person will not develop any assembler code it will
help to better understand compiler itself (for those who want).
I found that GNAT , Aonix do  not provide clear, good information regarding
this issue.
A good example is a Borland Delphi RAD which has comprehensive assembler
section and it takes less then hour to understand assembler within Delhi.
In Win NT world Delphi is the best example how things should be done.
If any company will produce something close to Delphi based on ADA95  this
can have great success.
RR Software with CLAW product is making steps in right direction but may be
ACT  or Averstar also will think about this ?


Regards to all.

Vladimir Olensky ( Vladimir_Olensky@oxy.com )
Telecommunication specialist,
Occidental C.I.S. Services, Inc. (www.oxy.com )
Moscow, Russia






robert_dewar@my-dejanews.com wrote in message
<780a5t$eaj$1@nnrp1.dejanews.com>...
>In article <78069o$anf$1@nnrp1.dejanews.com>,
>  dennison@telepath.com wrote:
>
>> It probably shouldn't. Compiler courses are not
>> *required* at any of the accredited CS universities that
>> I have seen. Additionally the vast majority of my
>> coworkers my entire carreer didn't even have a
>> university-level CS education.
>
>As a university professor perhaps I should not reveal
>this secret information, but amazingly it is NOT necessary
>to take a compiler course, or even to have a university
>level CS education to know what is going on. There are
>may ways to learn critical information.
>
>P.S. I have neither taken a compiler course nor have a
>university-level CS education myself, and I think I know
>*something* about compilers anyway :-)
>
>P.P.S. At NYU, we typically expect all students to take the
>compiler course, and most do.
>
>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own

Re: Dynamic memory? (was Re: Ada vs C++ vs Java)

[Nick Roberts]

robert_dewar@my-dejanews.com wrote in message
<780a5t$eaj$1@nnrp1.dejanews.com>...
[...]
|P.S. I have neither taken a compiler course nor have a
|university-level CS education myself, and I think I know
|*something* about compilers anyway :-)


That's a bit like Michaelangelo saying he reckons he knows a bit about
painting! Dr Dewar, folks, wrote a large part of the book (THE book) on
compilers.

|P.P.S. At NYU, we typically expect all students to take the
|compiler course, and most do.


I'm very, very pleased to hear that. It's just like a person learning a
little about car mechanics whilst learning to drive a car. The day is almost
certain to come, sooner or later, when that extra knowledge comes in very
handy. And besides which, knowing how a car basically works is bound to help
you understand how to drive it better.

-------------------------------------------
Nick Roberts
-------------------------------------------

Re: Dynamic memory? (was Re: Ada vs C++ vs Java)

[robert_dewar]

In article <78j2cg$72f$1@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> I'm very, very pleased to hear that. It's just like
> a person learning a little about car mechanics whilst
> learning to drive a car. The day is almost certain to
> come, sooner or later, when that extra knowledge comes in
> very handy. And besides which, knowing how a car
> basically works is bound to help
> you understand how to drive it better.

Off topic, I know, but recently I read that if you ask
people who have bought a new car in the last 12 months
whether they have ABS or not, then the percentage of people
who say yes compared to the actual percentage of cars with
ABS differs by about 10%. That means AT LEAST 1 in 10
drivers think they have ABS when they do not, or think they
do not have it when they do. Both misconceptions are of
course extremely dangerous in hazardous situations.

I use this example in my compiler class, so it is not
completely irrelevant to this thread :-)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Dynamic memory? (was Re: Ada vs C++ vs Java)

[Laurent Safa]

robert_dewar@my-dejanews.com wrote:
> 
> In article <36a357bb.24173519@news.demon.co.uk>,
>   johnb<nospam>@invision.co.uk wrote:
> 
> > No, it does not! The temporary objects created above are
> > as a result of calls to an object constructor. There is
> > no parallel in C to a constructor. The only stack usage
> > in C results from function calling.
> 
> This is complete nonsense, and your insistence on this
> completely wrong model just emphasizes that you do not
> know what is going on here. The stack is used for many
> things, including alloca calls, function local variables,
> block local variables, register spill, saving of
> non-volatile registers, including the frame pointer ...
> 
> You really should (a) learn assembly language and (b) study
> the assembler output from a C compiler.
> 
> It amazes me how many people today write in a high level
> language and haven't the foggiest idea what is going on
> at the code generation level!

Don't be so rude to today's people ;-). Albeit I am aware of low level
generation matters (I first used Z80 assemby 17 years ago, then Pascal,
C, C++ and today C++/Java), I think it's only natural to have more and
more people ignoring these. That's only the result and purpose of high
level languages and software development means: to accumulate experience
and provide ever more powerful tools to avoid re-implementing the same
things ever and ever. That's the way C++ goes with STL: C-arrays and
loops are now almost obsolete ; in many cases you don't need to know how
things go on, you just do it and rely on the language and compiler to
implement it in a nice way. For example I was amazed to see how fast a
colleague of mine developed a nice windowing application with Visual
Basic. I wouldn't have done it that fast with C++ for example (thought
maybe with Java).

Well, unfortunately real life isn't that beautiful so I still have to
look at assembly to check the actual code generation in some cases (only
parts of embedded softwares that are worthy to optimize), but I hope I
will get rid of this sometimes.


-- 
Laurent Safa
Matsushita Electric Works, Ltd.

Re: Dynamic memory? (was Re: Ada vs C++ vs Java)

[Michael J. Tobler]

In article <36A3F46A.5CE62C90@icrl.mew.co.jp>, safa@icrl.mew.co.jp says...
[snip]
> implement it in a nice way. For example I was amazed to see how fast a
> colleague of mine developed a nice windowing application with Visual
> Basic. I wouldn't have done it that fast with C++ for example (thought
> maybe with Java).

Dont bet on it - I have been on C++/Java teams that can build complete 
applications (let's say three tiers) WAY faster than the VB people. It all 
depends on the tools and the talent that knows how to use those tools.


-- 
<<<<<<<<<<<<<<<<  Blue Skies  >>>>>>>>>>>>>>>>
< Michael J. Tobler: mtobler@no-spam-ibm.net >
<   **remove "no-spam-" when replying**      >
<     http://www.webbrew.com/toblermj        >
< MJTobler:Instant Messenger;  28038932:ICQ  >
<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>

Re: Dynamic memory? (was Re: Ada vs C++ vs Java)

[Richard Kenner]

In article <36A3F46A.5CE62C90@icrl.mew.co.jp> Laurent Safa <safa@icrl.mew.co.jp> writes:
>Don't be so rude to today's people ;-). Albeit I am aware of low level
>generation matters (I first used Z80 assemby 17 years ago, then Pascal,
>C, C++ and today C++/Java), I think it's only natural to have more and
>more people ignoring these.

While working in these high-level languages, sure.  But that's very
different from never having learned them in the first place!

When you learn a science, you always start with the low-level details
and work upwards from there, despite the fact that you'll almost never
use that level in your work.  Physicians spend a lot of time on
organic chemistry, but that's something that's needed for only a very
small number of specialities.

Getting back to programming, you have to deal with the fact that all
compilers have code generation bus.  If your program doesn't do what
you expect it to, you may have to delve to the assembly level to debug
it.  Sure, you can try to get your compiler vendor to do that for you,
but they will first have to understand your program, which can often take
quite a while.

Re: Dynamic memory? (was Re: Ada vs C++ vs Java)

[bourguet]

In article <7803e9$825$1@nnrp1.dejanews.com>,
  robert_dewar@my-dejanews.com wrote:

> It amazes me how many people today write in a high level
> language and haven't the foggiest idea what is going on
> at the code generation level!

I doesn't amaze me they don't know what is going on at this
level, it scare me that they think they know what is going on.

-- Jean-Marc

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Dynamic memory? (was Re: Ada vs C++ vs Java)

[Georg Bauhaus]

robert_dewar@my-dejanews.com wrote:
: In article <36a357bb.24173519@news.demon.co.uk>,
:   johnb<nospam>@invision.co.uk wrote:

: It amazes me how many people today write in a high level
: language and haven't the foggiest idea what is going on
: at the code generation level!

Then what about this:

It amazes me how many people today drive taxis and 
buses and haven't the foggiest idea what is going on
under the hood!

Can we really expect every programmer to be a ``computer
scientist'', to some extent? I'm not saying that this
wouldn't be desireable. (I've chosen the term ``computer
scientist'' here to mean someone who knows about the
inner workings of compilers.  This might be considered
inappropriate because there is much more to computer
science, but think of a dummie who does not know admiring
the wise guy who does. He/she will certainly see him as
a computer scientist. See below.)

I've found it very helpful to learn a few things
about Perl's internal data structures, e.g.. This
clarifies a lot, but then I am aware that most Perl
programmers-on-the-road, meaning people who just write
Perl scripts, are quite unaware of Perl related things
that others find indispensable to know. I cannot really
judge whether this holds for other languages, too.

May I ask a question then? Given it is so helpful to know
what is going on at lower levels (I think it is!), given
further that an unknown number of programmers does not
know these things, and that it possibly means the higher
level to them knowing assembly languages, what can be
done to reverse or rearrange the learning process and to
help these persons not to get lost in an arcane djungle of
complex abstract words and symbols of high level languages
without getting to know computing machinery, mathematics
and data structures and algorithms? Whats your estimate
of the number of skilled programmers versus the number
of needed programmers?

regards,
  Georg Bauhaus

P.S.: This is not a question to be answered in language
specifications, say, but I think that masters should not only
discuss languages but also how they are used and taught,
because otherwise education, skill, and wit will get lost -
which are so important in evoking the enthusiasm that
makes you go on.

Re: Dynamic memory? (was Re: Ada vs C++ vs Java)

[robert_dewar]

In article <7866s8$apa$1@news-hrz.uni-duisburg.de>,
  sb463ba@d250-hrz.uni-duisburg.de (Georg Bauhaus) wrote:
> robert_dewar@my-dejanews.com wrote:
> Then what about this:
>
> It amazes me how many people today drive taxis and
> buses and haven't the foggiest idea what is going on
> under the hood!

That's fun! When I teach our assembly language course. I
give a lecture at the start on why it is valuable to learn
low level stuff like this, and one of the anologies I use
is that even though few of us will be auto-mechanics, it
is helpful in driving a car to understand the basic
principles of how it works. This helps you trouble shoot
in some situations, and also adds a safety margin, since
you better understand the technical limitations of a car!

Robert Dewar
(with my New York Univeristy hat on :-)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Dynamic memory? (was Re: Ada vs C++ vs Java)

[John Birch]

On Mon, 18 Jan 1999 16:10:58 GMT, johnb@invision.co.uk (John Birch)
wrote:

I wrote (erroneously)

>This depends on your definition of explicit. In order to code the
>above example, the operator + function has to call operator new
>(indeed it has to be a friend function too). So there is an explicit
>call to allocate memory. The point I am trying to make is how do you
>work out how much memory is used by a C++ program?

I just realised what I wrote here, and it's wrong. There is no need to
code operator + as calling new, indeed to do so would be to create a
memory leak in the above example! I apologise unreervedly for any
confusion caused. However, there is still a requirement to allocate
memory on the stack so that operator + can return a value rather than
a reference to a local variable. The point is, does, and can the
compiler tell me the programmer how much memory each function is going
to need to execute, and can I rely upon tricks like adding the numbers
up to give me the overall footprint.

>It is a language feature (operator overloading) that creates the
>problem in the first place by encouraging such coding styles. One of
>the core tenets of C programming is the 'nothing up my sleeve'
>approach, C++ does not have this requirement that the programmer has
>visibility of every action taken by the code. This I feel is a major
>disadvantage when coding for resource limited hardware. 

In a sense my point is proven. It is these kind of complexities that
make it difficult to use C++ in a hard embedded environment, where you
need to have a real grasp of what the code is going to do.

Maybe I'm just to dyed in the wool tho' :-)


regards John B.

Re: Dynamic memory? (was Re: Ada vs C++ vs Java)

[robert_dewar]

In article <36a37125.30679685@news.demon.co.uk>,
  johnb<nospam>@invision.co.uk wrote:

> The point is, does, and can the compiler tell me the
> programmer how much memory each function is going
> to need to execute, and can I rely upon tricks like
> adding the numbers up to give me the overall footprint.

At least at this point I trust it is clear that your
question is about implementations and applies equally well
to C and C++, and not about languages.

"can" a compiler provide this information? of course!

"does" your compiler provide it? You should know! Consult
your documentation if you don't know, or ask the vendor.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Dynamic memory? (was Re: Ada vs C++ vs Java)

[James Kanze]

John Birch wrote:
|> On Mon, 18 Jan 1999 16:10:58 GMT, johnb@invision.co.uk (John Birch)
|> wrote:

|> I wrote (erroneously)

|> >This depends on your definition of explicit. In order to code the
|> >above example, the operator + function has to call operator new
|> >(indeed it has to be a friend function too). So there is an explicit
|> >call to allocate memory. The point I am trying to make is how do you
|> >work out how much memory is used by a C++ program?

|> I just realised what I wrote here, and it's wrong. There is no need to
|> code operator + as calling new, indeed to do so would be to create a
|> memory leak in the above example! I apologise unreervedly for any
|> confusion caused. However, there is still a requirement to allocate
|> memory on the stack so that operator + can return a value rather than
|> a reference to a local variable. The point is, does, and can the
|> compiler tell me the programmer how much memory each function is going
|> to need to execute, and can I rely upon tricks like adding the numbers
|> up to give me the overall footprint.

No different than returning a struct from a C function.  In most cases,
the same techniques are used.

On the only compiler I used which calculated stack use, the amount of
stack needed for function arguments and return values was included in
the calling function.

I do agree that if you need to know the stack use, then you need the
compiler to calculate it for you, since you cannot really know what the
compiler generates for temporaries.  This is, however, true of *all*
languages which support expressions.

|> >It is a language feature (operator overloading) that creates the
|> >problem in the first place by encouraging such coding styles. One of
|> >the core tenets of C programming is the 'nothing up my sleeve'
|> >approach, C++ does not have this requirement that the programmer has
|> >visibility of every action taken by the code. This I feel is a major
|> >disadvantage when coding for resource limited hardware.

|> In a sense my point is proven. It is these kind of complexities that
|> make it difficult to use C++ in a hard embedded environment, where you
|> need to have a real grasp of what the code is going to do.

Strictly speaking, I find it a good idea to know what the code is going
to do in any environment:-).

I understand what you are saying, however: you fear that too much is
going on under the hood in C++.  If you have people overloading
operators when they shouldn't, etc., then this will be a problem.  But
it doesn't have to be.  In both C and C++, you need a good dose of
programmer discipline if you want to write working software.

--
James Kanze                                           GABI Software, S�rl
Conseils en informatique orient� objet  --
                          --  Beratung in industrieller Datenverarbeitung
mailto: kanze@gabi-soft.fr          mailto: James.Kanze@dresdner-bank.com

Re: Dynamic memory? (was Re: Ada vs C++ vs Java)

[Martijn Lievaart]

John Birch wrote in message <36a357bb.24173519@news.demon.co.uk>...
>On 18 Jan 1999 14:59:46 GMT, "Martijn Lievaart" <nobody@orion.nl>
>wrote:
>
>
>>>Complex one (1), Complex two (2), Complex three (3), Complex four (4);
>
>>>Complex Sum;
>
>>>Sum = one + two + three + four;
>
>>>If Complex is a class with an overloaded + operator, I get temporary
>>>objects generated (possibly at the compiler's option) in the above
>>>statement. Since it can be written as;
>
>>>Sum = operator + (operator + (operator +(one, two), three), four);
>
>>>Now try telling me how to calculate a worst case C++ memory
>>>requirement.
>
>>It is more difficult, but the temporaries in the example above are also
>>allocated on the stack, so the same argument as in the C case still holds.
>
>No, it does not! The temporary objects created above are as a result
>of calls to an object constructor. There is no parallel in C to a
>constructor. The only stack usage in C results from function calling.
>

[ I'll respond to your points in order thay are made, however it seems the
main stumbling block is that you assume a compiler cannot know the size of
an object in advance. We'll come to that so please read all before
responding to the first parts. ]

You confuse calling a constructor and allocating memory for an object. The
objects are allocated on the stack, just the same as a struct in C. After
that the constructor is called, on these raw memory bytes. *No* dynamic
allocation, it is known in advance. And yes, operator overloading can result
in more stack usage then doing it another way, but it is still stack memory
and known in advance.

You say that the temporaries are created as a result of call to a
constructor. That is correct. However, constructing and allocating an object
are very different things. An object is only created on the heap if someone
calls new. And that someone is *not* the compiler. Why would it? It knows
what object to allocate, knows the size. Stack is so much faster than heap,
no reason to call new.

(To be honest, the temporaries might be allocated on the heap, the standard
doesn't forbid it. Just any compiler that does so will have a very limited
life span. Would be the same as a C compiler that allocated all automatic
variables on the heap. C-standard allows that too.)

>>In fact, the C compiler is also free to generate temporaries on the stack
>>and often does so.
>
>Whilst it may use the stack space for temporary values, this space is
>pre-allocated in the stack requirements for any given function call. A
>C compiler AFAIK will never extend the size of the stack frame within
>a given function.
>

And the same holds for C++. It is *exactly* the same as C, except for a
constructor call. And that is an ordinary function call "under the hood".

Think of it as the following C code.

struct S
{
    int i;
};

void f()
{
    struct S s;
    init_S(&s);
    /* do something with s */
}

init_S is the constructor call. The equivalent C++ is really equivalent. The
space for the object in C++ is allocated on the stack in *exactly* the same
way as the struct above in C, the the constructor is called. There is
nothing magical here. Temporaries are handled in *exactly* the same way,
they are just unnamed, as are temporaries in C.

You may say, but the object is returned! It cannot be allocated the same as
struct S as it originates in another function.... Read on, it'll become
clear.

>> I think that the main reason why the compiler/linker will
>>calculate the maximum stacksize for you (the embedded scenario you
>>described) is not as a convenience to users, but because the user cannot
>>know in advance what stack usage his program has. Only the compiler knows
>>this.
>
>No, the main reason is exactly as I stated it, it is to tell embedded
>programmers how much stack space a program will use. The value of the
>stack space as calculated by the compiler is used by the linker to
>locate various portions of the code generated by the compiler and to
>check that heap, initialised data and stack space do not overflow
>available memory.
>

You misread me. The fact that the compiler tells you this is not a
convenience, but *you* cannot know by examining the source as the C compiler
may have to generate temporaries. So the compiler has to tell you (or the
linker). So it is not an automation to relieve the programmer from
calculating it, you just cannot tell. Of course you have to know your
program will fit and have to allocate stack accordingly. (hey I did dos once
to long ago. There was no compiler support to figure out how big the stack
had to be, I'ld have died for a compiler that told me).

>>Let me repeat, this is exactly the same as a C compiler. F.i. take the
>>following code.
>
>>int f(int i1, int i2, int i3)
>>{
>>    return i1+i2+i3;
>>}
>
>>On a register poor machine (not likely, but it might) this certainly will
>>allocate temporaries on the stack.
>
>Yes it might, but the compiler will include any stack space it is
>using as registers into the stack requirements for function f(). In
>the C++ example the compiler may not know how big the temporary
>objects are going to be.
>

Yes it does. It always does. It knows the type of the object, thus knows
it's size, thus it knows how many bytes to pre-allocate in the stackframe.
Try it, write a C++ program that does this and look at the assembly. It
might be enlightning.

Why do you think it doesn't know the size in advance? It's a Complex.
Presumably that is a struct (class) with two doubles in it. Double is (say)
8 bytes. Complex is 16 bytes. Simple.

Overloaded operators have to return something. The sizeof() this "something"
is what is allocated on the stack as a temporary. It is stated in the source
what this "something" is. In the example we're talking about, it is an
object of type Complex.

Remember, objects in C++ are just structs with a funny syntax, nothing
magical going on here. You know the size of a struct in advance, don't you?
Well the same with classes.

Maybe you should look at a C function that returns a struct. How does the C
compiler manage that? The return value (assuming it doesn't fit registers)
must have some storage allocated for it. Commonly it is done on the stack
(thread-safe) and a hidden parameter is passed to the function or it is
pre-allocated as a global (thread-unsafe) and the return value is actually a
pointer to this pre-allocated struct. This is equivalent to what happens in
C++. Actually, it is exactly the same!

>> This is exactly the same as the example
>>that started this thread, only no function calls to an user defined
operator
>>but a hardcore integer-add instruction.
>
>As I've shown it is in fact different!
>

No you haven't. You keep repeating operator new is called as a result of
operator overloading, but you fail to see this is not necessery to do so and
therefore isn't done. You obviously haven't tried any of this stuff because
simple experiments will show that operator new isn't called and looking at
the assembly output will show that it is allocated in advance in the
stackframe. No magic here, just simple assembly.

>> But *no more* dynamic memory
>>allocation than in this C example. (yeah, user defined operators are
>>function calls, so these take a stack frame, but that is the same as you
>>calling a function in C, i.e. predictable and reportable by the compiler).
>>Not even mentioning the fact that a good (embedded) C++ compiler might
even
>>only use registers in most cases.
>
>>In fact, C++ will *never* dynamically allocate memory on your behalf if
you
>>don't explicitly tell it to.
>
>This depends on your definition of explicit. In order to code the
>above example, the operator + function has to call operator new
>(indeed it has to be a friend function too). So there is an explicit
>call to allocate memory. The point I am trying to make is how do you
>work out how much memory is used by a C++ program?
>

Explicit as in calling malloc or using new and doing it yourself explicitly.
The operator + doesn't have to call new, nor does it do it. The point I'm
trying to make is that you are telling that C++ calls operator new behind
your back and I'm trying to show that it doesn't nor has to (and even
cannot, but that's a whole other issue we had better not get into).

What is it with the friend? I don't get that. No Complex class I've ever
seen had to be friends with new. In fact no class I've ever seen except
classes related to memory management itself (and these are hairy, an
advanced topic and generally a bad idea). Nothing in C++ requires this
afaik. Or do you mean that the operator has to be a friend of Complex if it
is not a member? That is only to access Complexes private parts and has
nothing to do with memory management at all. (Indeed I argue that the friend
keyword be replaced by lover, as it allows access to the private parts ;^>).

So how do you work out how much memory your program uses? Exactly the same
as in C. Except that C++ compilers are not as mature and may not do the
calculations required to tell the linker how many stack to put aside. But
there is no reason it cannot be done. In fact I have done it in embedded
(C++) programming, but by hand. (What a satisfying sight to see something
you programmed on a lot of counters all over the Netherlands. I couldn't
resist. Nope they didn't change the debug passwords. Fun!).

>>The RTL, maybe, will ask specificly, but not
>>the language itself. And that is *exactly* the same as C.
>
>It is a language feature (operator overloading) that creates the
>problem in the first place by encouraging such coding styles. One of
>the core tenets of C programming is the 'nothing up my sleeve'
>approach, C++ does not have this requirement that the programmer has
>visibility of every action taken by the code. This I feel is a major
>disadvantage when coding for resource limited hardware.
>

You are confused about what C++ will "do for you". It does not do any of
these magical things you atribute it with. In fact, it is all very simple.
Operator overloading has problems because it will generate temporaries on
bad compilers. Even on these bad compilers, these temporaries are placed on
the stack as any other temporary. The current standard has some expilicit
stuff about optimizing these temporaries away (see also comp.std.c++, thread
" Optimization questions (was Re: Returning locally created variables)").

And yes, C++ allows you to create code that will do a lot of things behind
your back. That's the beauty of it. It may also allocate temporaries, but
always on the stack. It may do some other surprising things. But a
programmer who doesn't know these is not a good C++ programmer. A C++
programmer has to know as much what his program does in terms of assembly as
a C programmer does (which may be very little for most of us and a lot upto
exactly for others).

And again the same goes for C. If you don't know that passing a struct to a
function will allocate a copy, you are in for some nasty surprises. Nothing
magical here, just the basic stuff. If you think that allocating a pointer
will automatically allocate memory (an error I see daily on c.l.l.c-c++) you
are in for some rude surprises. Same with C++. If you think the C++ compiler
will automagically call new for you, you are in for some nice(?) surprises.
You seem not to know C++ and operate on lore. Where did you get this info?

A good C++ programmer knows what his code does, and knows when he has to
know it to-the-byte. Embedded programming generally means you've got to know
to-the-byte so if you do Embedded-C++, you have to know and you can. C++
doesn't hide these things from you, although it takes some time to learn
exactly what the language does. And yes, there is room for a compiler to
implement some stuff the way it sees fit. That may not be acceptable for an
embedded system. I know, I've programmed embedded systems in C++. However,
the things you are objecting to are exactly the same in C as in C++, just
different syntax and possibly some extra temporaries because the compiler is
not smart enough to optimize them away. (Of course there are a lot of bad
C++ programmers..... well there where a lot of bad C programmers before C++
got hot. I know, I was one back then ;^>).

I don't think C++ encourages such coding styles, btw. Operator overloading
is a tool. Malloc is a tool. Use it when apropriate. Hey even VB is a tool
;^>! Using it when not apropriate is a telltale sign of an inexperienced or
bad programmer. I used it once in the preceding year.

>> I remember
>>Stroustrup commenting on this as one of the myths hardcore C programmers
>>have against C++, but I'm to lazy to look it up right now so don't quote
me
>>on it (yet).
>
>I'd love to see it if you can find it.

I'll try to find it....

>
>>Mind you, I'm not saying C++ is a better or even viable alternative, but I
>>do want to get these myths out of the way.
>
>Calling it a myth does not make it go away ;-)
>


It's not there, so it must be a myth ;^>

Martijn
--
My reply-to address is intentionally set to /dev/null
reply to mlievaart at orion in nl

Re: Dynamic memory? (was Re: Ada vs C++ vs Java)

[Stanley Friesen [Contractor]]

In article <36a357bb.24173519@news.demon.co.uk>, John Birch <nospam> wrote:
>No, it does not! The temporary objects created above are as a result
>of calls to an object constructor. There is no parallel in C to a
>constructor. The only stack usage in C results from function calling.

This depends on the C compiler and the input soruce code.

Having disassembled a fair number of compiled C programs, I can attest
that C compiler may generate tempraries on the stack for intermediate
results in a complex expression.  The fewer registers on a given machine,
the more likely it is to do so.  One one machine I used an expression
like (a * b) + (c * d) would use a stack temp.
>
>>In fact, the C compiler is also free to generate temporaries on the stack
>>and often does so.
>
>Whilst it may use the stack space for temporary values, this space is
>pre-allocated in the stack requirements for any given function call. A
>C compiler AFAIK will never extend the size of the stack frame within
>a given function.

Well, block-local variables can do something akin to that. While
many compilers precalculate the maximum size required for all block-locals
and set the stack size that, some treat the stack size as varying.
>Yes it might, but the compiler will include any stack space it is

>using as registers into the stack requirements for function f(). In
>the C++ example the compiler may not know how big the temporary
>objects are going to be.

Umm, how not?  The standard explicitly forbids passing incomplete types
to a function (such as an operator), which means the C++ compiler *does*
know how big they are.  (Even if the class uses new() internally, that
doesn't allocate on the stack anyhow).

[Check it out: both the lvalue-to-rvalue conversion and binding to a reference
require a complete type, and those are the only two ways to pass something
to an operator function].

Re: Dynamic memory? (was Re: Ada vs C++ vs Java)

[robert_dewar]

In article <77vi92$944@news3.euro.net>,
  "Martijn Lievaart" <nobody@orion.nl> wrote:
> In fact, C++ will *never* dynamically allocate memory on
> your behalf if you don't explicitly tell it to. The RTL,
> maybe, will ask specificly, but not the language itself.

No, that's going *too* far, you are making statements about
typical C++ implementations, not about the language. For
example, a C++ to JVM implementation might well decide to
use dynamic allocation for everything and depend on the JVM
garbage collector (A C to JVM implementation would probably
make the same choice, you really have no other way of doing
things in this particular environment).

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[James Kanze]

John Birch wrote:
|> On Sun, 17 Jan 1999 06:53:08 GMT, Matthew Heaney
|> <matthew_heaney@acm.org> wrote:

|> >"John Birch" <johnb@invision.co.uk> writes:
|> >
|> >> The reason IMHO is that C++ inherently relies upon dynamic memory
|> >> allocation! It's really as simple as that. If you can show me how to
|> >> calculate the maximum amount of memory required by a given C++ program then
|> >> I'll reconsider, until then I'll continue using C without malloc and free!
|> >
|> >When does C++ "inherently rely upon dynamic memory allocation"?
|> >
|> OK, say I have the following;

|> Complex one (1), Complex two (2), Complex three (3), Complex four (4);

|> Complex Sum;

|> Sum = one + two + three + four;

|> If Complex is a class with an overloaded + operator, I get temporary
|> objects generated (possibly at the compiler's option) in the above
|> statement. Since it can be written as;

|> Sum = operator + (operator + (operator +(one, two), three), four);

|> Now where do these temporary objects get created? On the stack, or on
|> the heap.

On the stack.

|> In C the stack size (without recursion) can never grow beyond the
|> maximum of the total of the stack requirements of all of the functions
|> defined.

The rules concerning the growth of stack size are the same in both C and
C++.  In particular, change the name of the function in the above to
addComplex, and there is really no difference in this case between C and
C++. The expression:

    Sum = addComplex( addComplex( addComplex( one , two ) , three ) , four ) ;

in C will require at least three instances of Complex as temporaries on
the stack.

|> How do I calculate the potential stack size in C++?

Exactly like you do in C.

|> There is inherent dynamic memory allocation going on here, it is
|> irrelevant whether it is satck or heap. I (the coder) did not
|> explicitly allocate memory, the language (or rather the implementation
|> of the language) did.

Which it does in any language.  There are only a limited number of
registers available -- on Intel architecture, a *very* limited number.
Once the compiler has used all of these for its temporaries, it will
spill to memory.  Which it allocates on the stack.  In addition, I know
of no compiler in C or C++ which will try and keep a struct or class
temporary in a register, even if it fits and none of the operations on
it really require an address.

--
James Kanze                                           GABI Software, S�rl
Conseils en informatique orient� objet  --
                          --  Beratung in industrieller Datenverarbeitung
mailto: kanze@gabi-soft.fr          mailto: James.Kanze@dresdner-bank.com

Re: Ada vs C++ vs Java

[John Birch]

On Mon, 18 Jan 1999 17:12:23 +0100, James Kanze
<James.Kanze@dresdner-bank.com> wrote:

>|> OK, say I have the following;

>|> Complex one (1), Complex two (2), Complex three (3), Complex four (4);

>|> Complex Sum;

>|> Sum = one + two + three + four;

>|> If Complex is a class with an overloaded + operator, I get temporary
>|> objects generated (possibly at the compiler's option) in the above
>|> statement. Since it can be written as;

>|> Sum = operator + (operator + (operator +(one, two), three), four);

>|> Now where do these temporary objects get created? On the stack, or on
>|> the heap.

>On the stack.

>|> In C the stack size (without recursion) can never grow beyond the
>|> maximum of the total of the stack requirements of all of the functions
>|> defined.

>The rules concerning the growth of stack size are the same in both C and
>C++.  In particular, change the name of the function in the above to
>addComplex, and there is really no difference in this case between C and
>C++. The expression:

>    Sum = addComplex( addComplex( addComplex( one , two ) , three ) , four ) ;

>in C will require at least three instances of Complex as temporaries on
>the stack.

In a C compiler, addComplex would return a struct (as a value) and
take two structs as values. However they would be passed by reference
(by the compiler). But in C the calling function would create the
necessary stack space and pass addComplex a 'pointer' to where it
wanted the answer put. Usually using a register specifically dedicated
for such a purpose.

So the routine that included 
Sum = addComplex(addComplex(addComplex(one , two) , three) , four) ;

when compiled would report a stack requirement that included the space
necessary for any temporary variables (because the size of the return
type is known).

In C++ the Complex operator + function must return an object by value
since a local reference can't be returned (and it has to be a friend
function as well!). Are you saying this goes on the stack? 

>|> How do I calculate the potential stack size in C++?

>Exactly like you do in C.

So are you saying that a C++ compiler will report the stack and heap
requirements of any function in a way that I can use to determine
memory usage of a program?

<snip>

regards John B.

Re: Ada vs C++ vs Java

[robert_dewar]

In article <36a36bc1.29299700@news.demon.co.uk>,
  johnb<nospam>@invision.co.uk wrote:

> In a C compiler, addComplex would return a struct (as a
> value) and take two structs as values. However they would
> be passed by reference (by the compiler).

No, not at all. C passes never passes anything by
reference. You are using incorrect and confusing
terminology.

You meant to say that C works by passing a pointer to (a
copy of) the value.

But that is also wrong. There is nothing in the C standard
that requires structures to be passed in this way, and on
many, but not all, ABI's, small structures can be passed
in registers.


> But in C the calling function would create the
> necessary stack space and pass addComplex a 'pointer' to
> where it wanted the answer put. Usually using a register
> specifically dedicated for such a purpose.

Again, that is just plain wrong. No such register is used
for example in the x86 calling sequence (there are just not
enough registers).

Really you are producing a LOT of misinformation in this
thread. You should study compilers and ABI's in more
detail.



-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[James Kanze]

John Birch wrote:

|> On Mon, 18 Jan 1999 17:12:23 +0100, James Kanze
|> <James.Kanze@dresdner-bank.com> wrote:

|> >|> OK, say I have the following;

|> >|> Complex one (1), Complex two (2), Complex three (3), Complex four (4);

|> >|> Complex Sum;

|> >|> Sum = one + two + three + four;

|> >|> If Complex is a class with an overloaded + operator, I get temporary
|> >|> objects generated (possibly at the compiler's option) in the above
|> >|> statement. Since it can be written as;

|> >|> Sum = operator + (operator + (operator +(one, two), three), four);

|> >|> Now where do these temporary objects get created? On the stack, or on
|> >|> the heap.

|> >On the stack.

|> >|> In C the stack size (without recursion) can never grow beyond the
|> >|> maximum of the total of the stack requirements of all of the functions
|> >|> defined.

|> >The rules concerning the growth of stack size are the same in both C and
|> >C++.  In particular, change the name of the function in the above to
|> >addComplex, and there is really no difference in this case between C and
|> >C++. The expression:

|> >    Sum = addComplex( addComplex( addComplex( one , two ) , three ) , four ) ;

|> >in C will require at least three instances of Complex as temporaries on
|> >the stack.

|> In a C compiler, addComplex would return a struct (as a value) and
|> take two structs as values. However they would be passed by reference
|> (by the compiler).

The C standard does not allow the compiler to pass by reference when you
write pass by value.  Nor does the C++ compiler.  On the other hand, C++
supports references, in addition to pointers, and can bind a temporary
to a const reference.  So that in cases like addComplex, a C++
programmer will almost certainly pass by reference, and not by value,
whereas a C programmer might not, since it would mean that he could not
pass the return value of an earlier call.

|> But in C the calling function would create the
|> necessary stack space and pass addComplex a 'pointer' to where it
|> wanted the answer put. Usually using a register specifically dedicated
|> for such a purpose.

This is very compiler dependant.  None of the C compilers I've seen for
Intel would pass this hidden argument in a special register.

Anyway, this is exactly the same situation as in C++.  Except that at
least one compiler for Intel does pass the this pointer by register,
rather than on the stack.

|> So the routine that included
|> Sum = addComplex(addComplex(addComplex(one , two) , three) , four) ;

|> when compiled would report a stack requirement that included the space
|> necessary for any temporary variables (because the size of the return
|> type is known).

|> In C++ the Complex operator + function must return an object by value
|> since a local reference can't be returned (and it has to be a friend
|> function as well!). Are you saying this goes on the stack?

Yes.  The solution is almost always the same for C and C++.  (For that
matter, in many cases C and C++ share the same back end.  So the
generated code will be exactly the same.)

|> >|> How do I calculate the potential stack size in C++?

|> >Exactly like you do in C.

|> So are you saying that a C++ compiler will report the stack and heap
|> requirements of any function in a way that I can use to determine
|> memory usage of a program?

Why not?  None of the C++ compilers I use do, but then, nor do any of
the C compilers.  Not because it is impossible, but because no one
cares: I currently work on big systems.  I would expect a C++ to report
this information in exactly the same cases a C compiler would.

--
James Kanze                                           GABI Software, S�rl
Conseils en informatique orient� objet  --
                          --  Beratung in industrieller Datenverarbeitung
mailto: kanze@gabi-soft.fr          mailto: James.Kanze@dresdner-bank.com

Re: Ada vs C++ vs Java

[James Kanze]

John Birch wrote:
|> The reason IMHO is that C++ inherently relies upon dynamic memory
|> allocation!

I'm curious as to what makes you say this.  It's probably true that most
C++ programs do make extensive use of dynamic memory, but then, it's
probably ture that most C programs also make extensive use of dynamic
memory.  It's also true that the standard IO libraries in *both*
languages normally use dynamic memory.  The containers in C++ do use
dynamic memory extensively -- in a real time environment, you can either
avoid them completely, or initialize them in such a way that all
allocations occur on start-up.

Typically, in an environment where there are no restrictions on using
dynamic memory, a C++ programmer will use it more freely than a C
programmer, because destructors make it easier to manage.  But making
dynamic memory easier to manage is a far cry from relying on dynamic
memory.

--
James Kanze                                           GABI Software, S�rl
Conseils en informatique orient� objet  --
                          --  Beratung in industrieller Datenverarbeitung
mailto: kanze@gabi-soft.fr          mailto: James.Kanze@dresdner-bank.com

Re: Ada vs C++ vs Java

[John Birch]

On Mon, 18 Jan 1999 17:03:21 +0100, James Kanze
<James.Kanze@dresdner-bank.com> wrote:

>John Birch wrote:
>|> The reason IMHO is that C++ inherently relies upon dynamic memory
>|> allocation!
>
>I'm curious as to what makes you say this.

Simple, every creation of a non static object in C++ causes a dynamic
memory allocation, whether by explicitly calling new, or by the
creation of temporary objects as a side effect of operator calls. This
memory is allocated from the stack or the heap (makes no difference
really, it's still memory).

>  It's probably true that most
>C++ programs do make extensive use of dynamic memory, but then, it's
>probably ture that most C programs also make extensive use of dynamic
>memory.

Only if dynamic memory is present. It usually requires an OS to
support it, although I have seen people develop their own heap
management software for hard embedded stuff (they're still working on
why their software falls over after x hours ;-).

The reasons I dislike dynamic memory management are two-fold, first,
it encourages a never, never approach to coding (ie. there is a
tendency to write for the general case, rather than explicitly
calculating and coding for the appropriate limitations), and secondly,
what do you do to prevent heap fragmentation. Please don't suggest
garbage collection because you can't guarantee that it has run when
you need to create that big object that would have fitted into the
heap ten seconds ago, and would now if the memory wasn't fragmented
and how do I tell the code that the pointer I gave it has moved and Oh
Ohh Hello ground....... 

<snip>
regards John B.

Re: Ada vs C++ vs Java

[James Kanze]

John Birch wrote:
|> On Mon, 18 Jan 1999 17:03:21 +0100, James Kanze
|> <James.Kanze@dresdner-bank.com> wrote:

|> >John Birch wrote:
|> >|> The reason IMHO is that C++ inherently relies upon dynamic memory
|> >|> allocation!
|> >
|> >I'm curious as to what makes you say this.

|> Simple, every creation of a non static object in C++ causes a dynamic
|> memory allocation, whether by explicitly calling new, or by the
|> creation of temporary objects as a side effect of operator calls. This
|> memory is allocated from the stack or the heap (makes no difference
|> really, it's still memory).

Obviously.  This is true of C as well, and of any other language you can
name.  If you create an object, you must have some where to put it.  And
if the language supports recursion (whether your program recurses or
not), then that somewhere is, almost by definition, on the stack.

|> >  It's probably true that most
|> >C++ programs do make extensive use of dynamic memory, but then, it's
|> >probably ture that most C programs also make extensive use of dynamic
|> >memory.

|> Only if dynamic memory is present. It usually requires an OS to
|> support it, although I have seen people develop their own heap
|> management software for hard embedded stuff (they're still working on
|> why their software falls over after x hours ;-).

OK.  You're talking about a non-hosted environment, not the C that most
people use.  And even a non-hosted environment is required to support
recursion, so there will at least be a stack.

|> The reasons I dislike dynamic memory management are two-fold, first,
|> it encourages a never, never approach to coding (ie. there is a
|> tendency to write for the general case, rather than explicitly
|> calculating and coding for the appropriate limitations), and secondly,
|> what do you do to prevent heap fragmentation. Please don't suggest
|> garbage collection because you can't guarantee that it has run when
|> you need to create that big object that would have fitted into the
|> heap ten seconds ago, and would now if the memory wasn't fragmented
|> and how do I tell the code that the pointer I gave it has moved and Oh
|> Ohh Hello ground.......

There are places where dynamic memory management is inappropriate.  I
never said anything else.  But the rules for when and where dynamic
memory will be used in a program are basically the same in C and C++:
both are required by the standard to have some sort of a stack, both are
required to have some sort of a heap (at least in a hosted environment),
and neither is allowed to use the heap *unless* the programmer either
explicitly asks for it, or calls a library function which is allowed to
dynamically allocate memory (which means just about any function in the
standard library).

Having worked on processors with as little as 64 bytes of memory, I can
imagine that compilers for such processors may offer compromises with
the standard, even to the degree of forgoing support for a stack.  But
there is nothing to prevent a C++ compiler from making the same
compromises.

--
James Kanze                                           GABI Software, S�rl
Conseils en informatique orient� objet  --
                          --  Beratung in industrieller Datenverarbeitung
mailto: kanze@gabi-soft.fr          mailto: James.Kanze@dresdner-bank.com

Re: Ada vs C++ vs Java

[Matthew Heaney]

johnb@invision.co.uk (John Birch) writes:

> On Mon, 18 Jan 1999 17:03:21 +0100, James Kanze
> <James.Kanze@dresdner-bank.com> wrote:
> 
> >John Birch wrote:
> >|> The reason IMHO is that C++ inherently relies upon dynamic memory
> >|> allocation!
> >
> >I'm curious as to what makes you say this.
> 
> Simple, every creation of a non static object in C++ causes a dynamic
> memory allocation, whether by explicitly calling new, or by the
> creation of temporary objects as a side effect of operator calls. This
> memory is allocated from the stack or the heap (makes no difference
> really, it's still memory).

You seem to be using the term "dynamic memory allocation" to refer to
objects allocated on either the stack or the heap.  Please don't do
this, because it is very confusing.

Use the term "dynamic memory allocation" only to refer to memory
allocated off the heap.

Re: Ada vs C++ vs Java

[Gerhard Menzl]

John Birch wrote:

> There are many embedded programmers who regard the concept of dynamic
> memory allocation in an embedded system as laughable at best and a
> terminal offence at worst. If you restict C++ in such a way (i.e.
> prevented the use of dynamic memory allocation) you'd pretty much end
> up with C anyway!

You would end up with a better C that gives you stronger type checking, const
correctness etc. It would still be C++, which is a multi-paradigm programming
language.

> Since I do not regard dynamic memory allocation as a _good_ thing for
> most hard embedded systems, I find this claim well founded :-)

That depends entirely on the allocation mechanism, I would say. C++ allows the
programmer to overload operators new and delete to define any form of allocation,
such as distributing chunks of memory from a preallocated pool. There are RTOSes
which have such mechanisms built in.

> Except that a perfectly valid ANSI C program need not compile or
> execute correctly under C++. Consequently, if it's a subset, it's a
> pretty poor one!

C code that does not compile under C++ is either very obscure, or it fails to comply
with the stronger type checking requirements of C++. Neither case can be considered
as essential to embedded systems programming. Or would you claim that embedded
systems code has to be obscure or requires weak type checking? "*Good* C programs
tend to be C++ programs." (B. Stroustrup: The C++ Programming Language, 3rd ed., p.
13).

Gerhard Menzl

Re: Ada vs C++ vs Java

[John Birch]

On Fri, 15 Jan 1999 11:49:29 +0100, Gerhard Menzl
<gerhard.menzl@sea.ericsson.se> wrote:

I originally wrote:

>> There are many embedded programmers who regard the concept of dynamic
>> memory allocation in an embedded system as laughable at best and a
>> terminal offence at worst. If you restict C++ in such a way (i.e.
>> prevented the use of dynamic memory allocation) you'd pretty much end
>> up with C anyway!

>You would end up with a better C that gives you stronger type checking, const
>correctness etc. It would still be C++, which is a multi-paradigm programming
>language.

Yes you would certainly gain some features that were not present in C.
Whether it made sense to use a crippled C++ in this way is a much more
debatable issue. In my experience you should either take it all or
leave it. If you start telling developers that "We're using C++ but we
don't use X, Y, Z", you are constraining the number of paradigms that
they are used to working in. Further you are now creating a
non-standard language that looks like C++ but isn't. The possibility
would then be open for subsequent maintenance or post design
programmers to start using forbidden features out of ignorance. This
obviously increases the possibility of errors in the code, especially
when the forbidden features are forbidden for 'subtle' reasons.

>> Since I do not regard dynamic memory allocation as a _good_ thing for
>> most hard embedded systems, I find this claim well founded :-)

>That depends entirely on the allocation mechanism, I would say. C++ allows the
>programmer to overload operators new and delete to define any form of allocation,
>such as distributing chunks of memory from a preallocated pool. There are RTOSes
>which have such mechanisms built in.

My biggest problem with dynamic memory allocation in embedded systems
is the fact that an indeterminate allocation mechanism exists!
If dynamic memory allocation is used the resulting program is
non-deterministic in the sense that it is impossible to guarantee that
there is enough memory resource to complete execution of the program
(under all paths for the program). C++ allocates memory for new
objects. New objects in C++ can be allocated as temporary objects
(i.e. out of the immediate awareness of the code writer). If I do not
have a hard disk or operating system in my embedded PC, how can I
write a C++ program, (where it is the compiler in cohorts with the OS
that allocates memory for objects) and know that my program will
execute without exhausting resources.

Besides which, the use of dynamic memory allocation seems to insipre a
kind of lazy attitude on software developers.I have seen serial port
processing routines that just increase their buffer sizes when they
fall behind in processing characters (and this in systems where the
processing of the characters is the core task!)

Granted that a large number of "real time" problems can be solved with
fast embedded PCs, but many of them could equally well (or better) be
solved with a microprocessor some RAM and an EPROM / FLASH program
store. When a programmer is faced with limited RAM, the unnecessary
use of dynamic memory allocation is a hinderance. Further, if the use
of dynamic memory allocation is prevented, the resulting code must be
written in a way such that memory resource requirments can be
calculated from examination of the source code and map file.

>> Except that a perfectly valid ANSI C program need not compile or
>> execute correctly under C++. Consequently, if it's a subset, it's a
>> pretty poor one!

>C code that does not compile under C++ is either very obscure, or it fails to comply
>with the stronger type checking requirements of C++. Neither case can be considered
>as essential to embedded systems programming. Or would you claim that embedded
>systems code has to be obscure or requires weak type checking?

My statement here rests upon the interpretation of 'subset'. I think a
perfectly good mathematical definition exists. Using that definition C
is not a subset of C++. I grant however that any C program that does
not compile under C++ is probably weak ;-)
 

regards John B.

Re: Ada vs C++ vs Java

[robert_dewar]

In article <369f81a9.31040093@news.demon.co.uk>,
  johnb<nospam>@invision.co.uk wrote:
> Yes you would certainly gain some features that were not
> present in C. Whether it made sense to use a crippled C++
> in this way is a much more debatable issue. In my
> experience you should either take it all or leave it. If
> you start telling developers that "We're using C++ but we
> don't use X, Y, Z", you are constraining the number of
> paradigms that they are used to working in. Further you
> are now creating a non-standard language that looks like
> C++ but isn't. The possibility would then be open for
> subsequent maintenance or post design programmers to
> start using forbidden features out of ignorance.

Any shop that cannot establish and enforce coding
conventions is out of control and should not be doing
any software production at all. Any programmer who is
uncomfortable with following an established set of
conventions is also out of control and should be got
rid of. The industry simply cannot afford such a level
of incompetence.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Crazy Pete]

> Any shop that cannot establish and enforce coding
> conventions is out of control and should not be doing
> any software production at all. Any programmer who is
> uncomfortable with following an established set of
> conventions is also out of control and should be got
> rid of. The industry simply cannot afford such a level
> of incompetence.

Actually that is all a matter of opinion and also a matter of degree. 
I once worked at a C++ shop where they came up with some standard 
naming conventions, this seemed like a good idea and we followed them.
 Then the person who actually wrote the document  decided that 
everyone should place their braces '{' in the manner in which she did 
and went to some incredible extremes in an attempt to enforce this.  
Everyone decided she was a nut and pretty much ignored her after that.
 Some people would say that is far too restrictive (some of the best 
programmers I know will refuse to work under such restrictive 
conditions) and others feel that the more rules the better.  In any 
case it is certainly a matter of opinion and not one of incompetence.

Peace

Peter

Re: Ada vs C++ vs Java

[robert_dewar]

In article
<YkGBP4MNXb2t-pn2-pGYtgdoCPzh2@pn15-ppp-170.primary.net>,
  peter.garner@toward.com (Crazy Pete) wrote:
> Then the person who actually wrote the document  decided
> that everyone should place their braces '{' in the manner
> in which she did  and went to some incredible extremes in
> an attempt to enforce this. Everyone decided she was a
> nut and pretty much ignored her after that.

That is exactly the sort of thing I am talking about. For
a large project to permit divergence in style on a trivial
issue like this is very poor management. For programmers
to object to following a consistent style in a trivial
issue like this is evidence of out-of-control hacker
mentality. Just imagine an automotive engineer who insisted
on using non-standard screw sizes ...

As I said in a previous post, trivial issues of style like
this are important ONLY to the extent that consistency in
style is very important.

Yes I am quite aware in the C world that you get at least
two different styles of bracket placement and some
programmers get used to one and don't like the other.
One of the marks of a good programmer is that they can
easily make a transition between coding styles in this
kind of trivial respect.

The trouble is that if you have two programmers one of
whom insists on

   if (a == 2) {

and the other who insists on

   if (a == 2)
   {

and insists so strongly that they refuse to follow a
prescribed standard, as in the case you mention, then
they will not be happy working with one another's code,
and that leads to code ownership, and ego-centered
programming.

> Some people would say that is far too restrictive (some
> of the best  programmers I know will refuse to work under
> such restrictive conditions)

Such programmers may be the "heroes" of a CMM level 1 shop,
but they are NOT "best programmers".

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Judah Diament]

It's nice to see somone of Dr. Dewar's stature take this childish and long
standing fight to task. If someone is so small minded that he would create
a fight over where the brackets get placed, I ceartainly wouldn't want him
on my team, no matter how good he is. People who are that small minded and
stubborn inevitably cause more trouble on a project than they are worth.

        -Judah

robert_dewar@my-dejanews.com wrote:

> In article
> <YkGBP4MNXb2t-pn2-pGYtgdoCPzh2@pn15-ppp-170.primary.net>,
>   peter.garner@toward.com (Crazy Pete) wrote:
> > Then the person who actually wrote the document  decided
> > that everyone should place their braces '{' in the manner
> > in which she did  and went to some incredible extremes in
> > an attempt to enforce this. Everyone decided she was a
> > nut and pretty much ignored her after that.
>
> That is exactly the sort of thing I am talking about. For
> a large project to permit divergence in style on a trivial
> issue like this is very poor management. For programmers
> to object to following a consistent style in a trivial
> issue like this is evidence of out-of-control hacker
> mentality. Just imagine an automotive engineer who insisted
> on using non-standard screw sizes ...
>
> As I said in a previous post, trivial issues of style like
> this are important ONLY to the extent that consistency in
> style is very important.
>
> Yes I am quite aware in the C world that you get at least
> two different styles of bracket placement and some
> programmers get used to one and don't like the other.
> One of the marks of a good programmer is that they can
> easily make a transition between coding styles in this
> kind of trivial respect.
>
> The trouble is that if you have two programmers one of
> whom insists on
>
>    if (a == 2) {
>
> and the other who insists on
>
>    if (a == 2)
>    {
>
> and insists so strongly that they refuse to follow a
> prescribed standard, as in the case you mention, then
> they will not be happy working with one another's code,
> and that leads to code ownership, and ego-centered
> programming.
>
> > Some people would say that is far too restrictive (some
> > of the best  programmers I know will refuse to work under
> > such restrictive conditions)
>
> Such programmers may be the "heroes" of a CMM level 1 shop,
> but they are NOT "best programmers".
>
> Robert Dewar
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own

Re: Ada vs C++ vs Java

[bill]

In article <36A12D50.9604A0B0@cs.nyu.edu>, Judah says...
>
>It's nice to see somone of Dr. Dewar's stature take this childish and long
>standing fight to task. If someone is so small minded that he would create
>a fight over where the brackets get placed, I ceartainly wouldn't want him
>on my team, no matter how good he is. 

Wow! what a strong statment ! and comming from someone from the computer
science department of New York university where Dewar PhD works (worked?) too!

makes one wonder if someone has a axe to grind against some other person?

as for the issue at hand, nowadays there are plenty of automated tools
to reformat the source code in any shape one prefers. so it is not a 
problem. When you need to work on the code, reformat it as you prefer, work
on it and check it in. The other person can check the code later, reformat it
as they want and work on it.  I've done this myself on C/C++ code working
with other programmers each prefer different way of formating. and we never
had any problem.

Bill.
  

Re: Ada vs C++ vs Java

[Al Christians]

bill@north.nospam.com.net wrote:
> 
> 
> as for the issue at hand, nowadays there are plenty of automated tools
> to reformat the source code in any shape one prefers. so it is not a
> problem. When you need to work on the code, reformat it as you prefer, work
> on it and check it in. The other person can check the code later, reformat it
> as they want and work on it.  I've done this myself on C/C++ code working
> with other programmers each prefer different way of formating. and we never
> had any problem.
> 

Bill

I thought that was ok, too, but it worked out poorly for me 
recently. 

The problem was that the differences in styles were sufficiently 
great that the formatting tool wouldn't be able to convert code 
from the different styles into a common representations so that 
diff would find only non-format differences and so that the 
standard code being diff'd would be readable enough  for 
efficient maintenance.  For example, when there are differences 
in whether a single-statement block should have {}'s 
around it, whether lines of code should be internally spaced so 
that similar items on successive lines would form neat columns, 
whether to use tabs or spaces, whether or not tabs should be used 
after non-whitespace characters, and when maximum line-length 
preferences vary from 60 to infinity, the tool is unlikely 
to be able to keep everyone working happily and productively in
their own preferred style.

Of course, diff is typically built into the versioning tool, so 
the code should be standardized each time before check-in.  That
means that at least n-1 programmers will be reformatting code 
every time they check it out, which may be inefficient, 
particularly so if they are trying to use a style that cannot be
reproduced 100% by machine.


Al

Re: Ada vs C++ vs Java

[Judah Diament]

Huh!?!? I was complimeting Dr. Dewar's statement, not attacking it. I thought he
had an excellent point when saying that it's silly how some people stubbornly
refuse to conform to shop standards because of inconsequential personal
preferences on an issue as tiny as where I put my brackets. I certainly am not
grinding an axe, quite the opposite - because I attended a class taught by Dr.
Dewar 2 years ago ( he is a tenured professor at NYU's Courant Institute for
Mathematical Sciences and has been for a couple of decades) I have seen that he
has a clear and thorough understanding of compilers and programming languages and
is someone to be taken quite seriously on these issues.

    It escapes me how you read my last message as attacking Dr. Dewar. It's kind
of stupid to entertain the notion of  messing with someone who has been
programming professionally, and doing a good job of it, since before you were
born.

        -Judah

bill@north.nospam.com.net wrote:

>
> Wow! what a strong statment ! and comming from someone from the computer
> science department of New York university where Dewar PhD works (worked?) too!
> makes one wonder if someone has a axe to grind against some other person?
>
> Bill.
>

Re: Ada vs C++ vs Java

[robert_dewar]

In article <77rjbk$7d0@drn.newsguy.com>,
  bill@north.nospam.com.net wrote:
> As for the issue at hand, nowadays there are plenty of
> automated tools to reformat the source code in any shape
> one prefers. so it is not a problem. When you need to
> work on the code, reformat it as you prefer, work
> on it and check it in. The other person can check the
> code later, reformat it as they want and work on it.
> I've done this myself on C/C++ code working with other
> programmers each prefer different way of formating. and
> we never had any problem.

This is often trotted out as an argument, but it is in
practice bogus for several reasons:

1. Massive reformatting like this tends to disturb the
sources and not be completely reversible. This will lead
to bogus differences between successive versions, which
cause trouble in practice.

2. Many coding rules are not susceptible to completely
automated translation (e.g. going from all upper case to
mixed case identifiers with exceptions for acronyms).

3. You still have the problem of each programmer having
a distinct style, so code tends to belong to given
programmers, and the fact that programmers dislike one
another's style is an unnecessary source of confusion and
friction.

4. Programmer's get careless, and unless this multi-style
approach is truly automated, someone will put code into
someone elses program in the wrong style causing annoyance.

5. Ideally, simple things like bracket placement can be
checked with automatic tools that are part of the CM
system, or even the compiler. For GNAT, we have a compiler
option to check style rules, and everyone is required to
use it.

All these problems, JUST because some programmer has such
a big ego, or is so stubborn that they can't adopt a simple
set of style rules? In my experience, programmers who are
this individualistic are likely to be poor team members in
any case, and as I said in my first post, I simply would
not tolerate this kind of behavior. Once again, such
programmers may be the heroes of CMM level 1, but the whole
point of the CMM, even at level 2, is to get rid of this
kind of nonsense!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[bill]

In article <77t241$mnj$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com
says...
>
>In article <77rjbk$7d0@drn.newsguy.com>,
>  bill@north.nospam.com.net wrote:
>> As for the issue at hand, nowadays there are plenty of
>> automated tools to reformat the source code in any shape
>> one prefers. so it is not a problem. When you need to
>> work on the code, reformat it as you prefer, work
>> on it and check it in. The other person can check the
>> code later, reformat it as they want and work on it.
>> I've done this myself on C/C++ code working with other
>> programmers each prefer different way of formating. and
>> we never had any problem.
>
>This is often trotted out as an argument, but it is in
>practice bogus for several reasons:
>

<good reason snipped).

I believe after I read your arguments and other that I have decided
your point of view is the correct one.

I now changed my position on this, and I agree that one common style would
be better and that using continuose reformatting of source code would not 
work on the long run. 

Bill.
 

Enforcement of coding standards (was: Ada vs C++ vs Java)

[Nick Roberts]

This is a topic we've had before (many times I think) on comp.lang.ada, and
Robert Dewar has always made his position very clear (and I mine :-). I
disagree with him. I'm not sure if I can successfully argue him round, but I
shall try!

The essence of my argument is that: (a) it can be harmful to young
programmers to expose them to only one style of programming; (b) forcing an
unfamiliar style on experienced programmers may reduce their productivity,
and can cause resentment; and, most importantly, (c) a standard coding style
is never really necessary anyway.

I will begin by trying to demonstrate (c) first, in terms of 'answering' one
of Dr Dewar's posts.

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

robert_dewar@my-dejanews.com wrote in message
<77t241$mnj$1@nnrp1.dejanews.com>...
|In article <77rjbk$7d0@drn.newsguy.com>,
|  bill@north.nospam.com.net wrote:
|> As for the issue at hand, nowadays there are plenty of
|> automated tools to reformat the source code in any shape
|> one prefers. so it is not a problem. When you need to
|> work on the code, reformat it as you prefer, work
|> on it and check it in. The other person can check the
|> code later, reformat it as they want and work on it.
|> I've done this myself on C/C++ code working with other
|> programmers each prefer different way of formating. and
|> we never had any problem.
|
|This is often trotted out as an argument, but it is in
|practice bogus for several reasons:
|
|1. Massive reformatting like this tends to disturb the
|sources and not be completely reversible. This will lead
|to bogus differences between successive versions, which
|cause trouble in practice.

The solution to this problem is really simple: don't reformat working code!
Furthermore, I would say that it's (normally) rude to reformat another
programmer's working code, as well as being a futile exercise. I believe
this will be found to held as "programmer's etiquette" all over the world.

Furthermore, if a piece of code does need to be reformatted, you only need
to 'reregister' it (undelta it, reformat it, redelta it without changing
version stamp). If your version control system can't do this, the problem is
with your version control system!

|2. Many coding rules are not susceptible to completely
|automated translation (e.g. going from all upper case to
|mixed case identifiers with exceptions for acronyms).


The solution to this problem is to impose the minor coding standard that all
identifiers are coded in mixed case (if mixed case is required). I've never
yet encountered a programmer so bloody-minded as to insist on coding in all
upper or all lower case when asked (politely!) not to. Doubtless there is
one somewhere.

|3. You still have the problem of each programmer having
|a distinct style, so code tends to belong to given
|programmers,

It's never a source of confusion; this is simply not true. Reading code
written in a style unfamiliar to me may be slow going for a few minutes, but
I become familiar with it very quickly, and it never actually confuses me.
Isn't this every programmer's experience?

|and the fact that programmers dislike one
|another's style is an unnecessary source of confusion and
|friction.

There's a difference between a programmer preferring a certain style and
disliking all other styles. I would suggest that forcing a coding standard
on a programmer is likely to be much greater source of friction than having
to read code in alternative styles every now and then!

|4. Programmer's get careless, and unless this multi-style
|approach is truly automated, someone will put code into
|someone elses program in the wrong style causing annoyance.


On the contrary, if you insert or correct code in someone else's program,
you use your own coding style, and they just have to accept it (and you have
to accept them doing the same in your code). Again, I think this will be
found to be generally accepted programmer's etiquette.

Professional programmers don't get careless. As a class, they're the least
careless people on the planet. This accusation is the number one reason for
programmers chewing right through the skin to the ligament.

|5. Ideally, simple things like bracket placement can be
|checked with automatic tools that are part of the CM
|system, or even the compiler. For GNAT, we have a compiler
|option to check style rules, and everyone is required to
|use it.


Indeed I believe that any code (or at least any Ada code) can be
'beautified' in a totally automated manner, except for the above mentioned
problem with identifiers (and certain minor problems with comments, which
can also be easily overcome). Thus, if any programmer's code is felt to be
just _too_ weird, it can be beautified back into shape in seconds.

|All these problems, JUST because some programmer has such
|a big ego, or is so stubborn that they can't adopt a simple
|set of style rules?

Yes! You can sack all your stubborn, egotistical programmers, and I will
employ them. And, because I don't impose a coding style on them, they will
like working for me, and quite possibly help to make me a rich man (well,
that's the theory, anyway :-). But seriously, do you think good (i.e.
talented and/or experienced) programmers are never stubborn or egotistical?

|In my experience, programmers who are
|this individualistic are likely to be poor team members in
|any case,

In _my_ experience, good programmers tend not to be good 'team members'.
It's just one of those facts of life: the psychological factors that lead to
a person becoming adept at computer programming tend be the same
psychological factors which are associated with an individualistic
personality. Which do you want: a good programmer, or a 'team member'?
Demanding that a programmer be a good 'team member' strikes me as being
rather like a football team demanding that a prospective quarterback is also
good at doing tax returns. It may be very fashionable these days, but it's
still nonsense.

|and as I said in my first post, I simply would
|not tolerate this kind of behavior.

Perhaps you should try to be a little more tolerant, Robert ;-)

|Once again, such
|programmers may be the heroes of CMM level 1, but the whole
|point of the CMM, even at level 2, is to get rid of this
|kind of nonsense!


I suspect a lot of people would agree with me that CMM was not written by
people who really understand the issues. They may be experts on work
methodologies, and many other things, but they are not experts on the
realities of programming.

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

To expand on point (a), I believe a good employer has a duty to protect the
career interests of young programmers. It is almost certainly the case that
a young programmer, even if they only ever use one language throughout their
entire career, will come to work in many different jobs, departments, and/or
projects, and will need to be able to read, understand, and modify other
people's code, written to a variety of standards of style (or none). Surely
it would be unrealistic to think this will not happen? And, surely, you are
not really considering the interests of this programmer unless you allow
them to work in an environment where they are likely to be exposed to a
variety of different coding styles? Some people may think this is a bit of a
concocted point, but it is a serious matter to programmers right at the
beginning of their careers.

For point (b), I believe it is simply unrealistic to think that you can
bring an old, grizzled, programmer into a shop, and expect them to just drop
the style of coding they have used for years (even decades) in favour of
your preferred style. My specific point is that many (not all) such
programmers are certain to be happier, and a little more productive, using
the style they prefer and/or are used to.

In an earlier post, Robert makes the point that if a programming shop does
not impose a coding standard on all its programmers, it is out of control,
and badly managed. But, this is not true per se: poor control or management
_may_ be a reason for not imposing a single standard, but it is not the only
possible reason. It may be that a shop which is being very well managed, and
firmly controlled, does not impose a standard as a matter of considered
policy.

I reiterate, for point (c), that I believe there is never any genuine reason
why a single coding standard needs to be imposed on a set of programmers. It
is always possible to organise things so that this is not necessary. Whilst
it may be easier for the management to make their programmers fit their
requirements, rather than bending to the preferences of their programmers, I
would go so far as to assert that such a management may actually be
demonstrating poorer, rather than greater, control or managerial skill, in
giving way to its own laziness, bloody-mindedness, lack of imagination, or
even lack of care for its programmers.

And finally, I must emphasise that I have the highest regard for Robert
Dewar's opinions, and in most computer matters I would readily defer to him.
I genuinely have no doubt at all that ACT is run very efficiently, and I do
not even begin to argue with the many obvious benefits of using or imposing
a standard of coding style in a programming department. I would simply argue
that doing so is not necessarily the best policy in all circumstances.

-------------------------------------------
Nick Roberts
-------------------------------------------

Re: Enforcement of coding standards (was: Ada vs C++ vs Java)

[dennison]

In article <78j2ck$72f$2@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:

> It's never a source of confusion; this is simply not true. Reading code
> written in a style unfamiliar to me may be slow going for a few minutes, but
> I become familiar with it very quickly, and it never actually confuses me.
> Isn't this every programmer's experience?

It jibes w/ mine. The only time I have ever had to reformat someone else's
code to read it was when I was trying to read the code of an ex-assembler
programmer who indented randomly (no spaces, two spaces, twelve spaces, I
couldn't make heads or tails of it).

> There's a difference between a programmer preferring a certain style and
> disliking all other styles. I would suggest that forcing a coding standard
> on a programmer is likely to be much greater source of friction than having
> to read code in alternative styles every now and then!

I think that's actually pretty healthy. I have found all sorts of good new
ideas that way.

> On the contrary, if you insert or correct code in someone else's program,
> you use your own coding style, and they just have to accept it (and you have
> to accept them doing the same in your code). Again, I think this will be
> found to be generally accepted programmer's etiquette.

True here. It does seem to be some sort of unwritten rule. However, I have
seen it *enforced* via standards that insist a style be maintained within a
source file.

> I suspect a lot of people would agree with me that CMM was not written by
> people who really understand the issues. They may be experts on work
> methodologies, and many other things, but they are not experts on the
> realities of programming.

I don't think CMM is all that useless. I just think it misses the mark. Its
focus is on quality (particularly *repeatable* quality). At the upper CMM
levels this *has* to come at the expense of efficency. Developers do care a
lot about quality, because noone wants to spend their life producing crap.
But software customers as a rule (and there are exceptions) don't care that
much about quality. They may say they do, but when pressed they aren't really
willing to pay any extra or wait any longer for it. Assuming you are in
business for your customers and not your developers, efficiency is a more
important goal.

That's why I think in the long run OSS is going to be more important than CMM
(not that they can't be used together).


T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Dennis]

What about when you want to see what one person changed? Not only do you get
their changes, but also their formatting changes shown in the differences
report.

When I write new code, I follow the company's guidelines.
When I modify existing code, I try to keep my code 'consistent' with the
surrounding code.

What I've found helps the most is consistency. Ideally, consistency among
all the files. Failing that, consistency in that source file is decent.

Dennis

bill@north.nospam.com.net wrote in message <77rjbk$7d0@drn.newsguy.com>...
>In article <36A12D50.9604A0B0@cs.nyu.edu>, Judah says...
>>
>>It's nice to see somone of Dr. Dewar's stature take this childish and long
>>standing fight to task. If someone is so small minded that he would create
>>a fight over where the brackets get placed, I ceartainly wouldn't want him
>>on my team, no matter how good he is.
>
>Wow! what a strong statment ! and comming from someone from the computer
>science department of New York university where Dewar PhD works (worked?)
too!
>
>makes one wonder if someone has a axe to grind against some other person?
>
>as for the issue at hand, nowadays there are plenty of automated tools
>to reformat the source code in any shape one prefers. so it is not a
>problem. When you need to work on the code, reformat it as you prefer, work
>on it and check it in. The other person can check the code later, reformat
it
>as they want and work on it.  I've done this myself on C/C++ code working
>with other programmers each prefer different way of formating. and we never
>had any problem.
>
>Bill.
>

Re: Ada vs C++ vs Java

[Michael J. Tobler]

In article <77ommt$9bo$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com 
says...
[snip]
> Any shop that cannot establish and enforce coding
> conventions is out of control and should not be doing
> any software production at all.

> Any programmer who is
> uncomfortable with following an established set of
> conventions is also out of control and should be got
> rid of.

It's not always the programmer's fault; you're being a little unfair here. 
Many times it's the programmer's peers or manager's or lead's fault. There 
are many reasons for not following established standards. To put the blame 
on a programmer and fire them is unqualified. You need to find out where 
the problem really is. 

Now, if there is a process, and there are deliverables expected, and some 
programmer consistently refuses to deliver, then yes, they may require 
disciplinary action.

> The industry simply cannot afford such a level
> of incompetence.

WOW, where have you been?  I empathize with you, but this stuff exists. 
The best we can do is to mentor others.

-- 
<<<<<<<<<<<<<<<<  Blue Skies  >>>>>>>>>>>>>>>>
< Michael J. Tobler: mtobler@no-spam-ibm.net >
<   **remove "no-spam-" when replying**      >
<     http://www.webbrew.com/toblermj        >
< MJTobler:Instant Messenger;  28038932:ICQ  >
<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>

Re: Ada vs C++ vs Java

[robert_dewar]

In article <MPG.1109de3d99a2452e98a0af@news3.ibm.net>,
  mtobler@no-spam-ibm.net (Michael J. Tobler) wrote:

> WOW, where have you been?  I empathize with you, but this
> stuff exists. The best we can do is to mentor others.

Among other things I have been president of a software
company that rigorously enforces coding standards, and
indeed we would not continue to work with someone who
was uncomfortable with following them! Note that I am
not simply talking about refusing to follow them. I think
it is very important for programmers to fully adopt an
agreed on style. At ACT, we typically vote on things that
don't really matter, e.g. number of columns of indentation,
but once a vote is taken and established in our coding
conventions, then we expect everyone to follow it. The
result is very uniform code, and a substantial step to
breaking down code ownership, which I regard as a severe
detriment in many environments (I wrote this code, I own
it, no one but me understands it, and I must be the one to
maintain it -- and when I leave with two weeks notice ....)

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Draconian coding standards (was: Ada vs C++ vs Java)

[dennison]

In article <77q4p7$diu$1@nnrp1.dejanews.com>,
  robert_dewar@my-dejanews.com wrote:

> agreed on style. At ACT, we typically vote on things that
> don't really matter, e.g. number of columns of indentation,
  ^^^^^^^^^^^^^^^^^^^ A telling phrase there. ;-)

> but once a vote is taken and established in our coding
> conventions, then we expect everyone to follow it. The
> result is very uniform code, and a substantial step to
> breaking down code ownership, which I regard as a severe
> detriment in many environments (I wrote this code, I own
> it, no one but me understands it, and I must be the one to
> maintain it -- and when I leave with two weeks notice ....)

The point is to get all the code readable by anyone with a minimum of effort,
not to send individualistic developers off to Dhakow. The last thing we want
to do is give the message that the best work in the world is less important
than putting the parentheses in the right place.

For just that reason, I tend to try to get standards drafted so that
non-compliant code can be brought into compliance with a tool. I've seen some
environments where the tool was automaticly run on any code checked into
revision control. (That can be a disaster if no thought is placed into the
settings on the tool). But if your style is going to be changed to the
standard *anyway*, most developers will eventually adopt it themselves. This
way folks don't feel like the value of their creative work is being
trivilized.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Draconian coding standards (was: Ada vs C++ vs Java)

[dewar]

In article <77vk87$pv9$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> In article <77q4p7$diu$1@nnrp1.dejanews.com>,
>   robert_dewar@my-dejanews.com wrote:
>
> > agreed on style. At ACT, we typically vote on things
> > that don't really matter, e.g. number of columns of
> > indentation,
>   ^^^^^^^^^^^^^^^^^^^ A telling phrase there. ;-)

I think you are making a serious misintpretation here. I
was saying that the *particular choice* is unimportant but
consistency is VERY important. As Tarski used to say, it
matters not one whit whether you drive on the right or left
side of the street, but it is vital for everyone to agree!


> The point is to get all the code readable by anyone with
> a minimum of effort, not to send individualistic
> developers off to Dhakow. The last thing we want
> to do is give the message that the best work in the world
> is less important than putting the parentheses in the
> right place.

Nope, that's not the point, the point is that
individualistic programmers who make a big stink about
conforming to standards are a potential menace.


> For just that reason, I tend to try to get standards
> drafted so that non-compliant code can be brought into
> compliance with a tool. I've seen some environments where
> the tool was automaticly run on any code checked into
> revision control. (That can be a disaster if no thought
> is placed into the settings on the tool).

Yup, sounds like a disaster to me, particularly with
respect to tracking down changes done from a particular
checkin.


> But if your style is going to be changed to the
> standard *anyway*, most developers will eventually adopt
> it themselves. This way folks don't feel like the value
> of their creative work is being trivilized.

Anyone who thinks that following standards for uniformity
in such an area is trivilaizing things has an unbalanced
view of things.

At one company I worked for, there were strict coding
standards (requiring the use of all upper case identifiers
in Ada). One developer refused and wrote everything with
mixed case. He would not touch code written with upper case
identifiers, and consequently would not work on anyone
else's code, and no one could touch his in the standard
style.

Result, he was the only one who knew his code, and disaster
struck when he left the company.

I would have fired him right away, and thought it was a
huge mistake. Yes, he was, in the sense of CMM level 1
heroes, a great programmer, but you simply cannot tolerate
this kind of hacker mentality in an disciplined environment
committed to sound software engineering.

Note incidentally that consistency of style goes FAR beyond
the issue of where parens are placed. If you have a team
that is dedicated to the desirability of consistency, they
will be able to reach this higher level of consistency far
more easily. As I have said before, I think the GNAT
sources are a good example. No one owns any particular
piece of the code, and all the code is written in a highly
uniform style that goes far beyond the simple subset that
are tools can easily check.

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Draconian coding standards (was: Ada vs C++ vs Java)

[dennison]

In article <77vpeu$unb$1@nnrp1.dejanews.com>,
  dewar@gnat.com wrote:
> In article <77vk87$pv9$1@nnrp1.dejanews.com>,

> At one company I worked for, there were strict coding
> standards (requiring the use of all upper case identifiers
> in Ada). One developer refused and wrote everything with
> mixed case. He would not touch code written with upper case
> identifiers, and consequently would not work on anyone
> else's code, and no one could touch his in the standard
> style.

The part mentioned in the latter sentence is quite bad. If someone refuses to
work on code that they are assigned to work on, and tries (no one can stop it
:-) ) to prevent others from working on *their* code, they certainly are more
trouble to have around than they could possibly be worth.

But I'd hope there'd be better methods of getting rid of such people other
than trying to "legislate" them out of existence. If no one feels any
connection whatsover to what they are working on, where's the incentive to
keep working for you at all? (Hopefully the answer lies somewhere in your
team dynamics) Your solution seems to throw the baby out with the bathwater.

In isoloation this may not be to bad. But some companies hate the way that
losses of individuals damage them, so they use all sorts of methods to try to
foce every individual to act the same. Not only is this a  tremendous waste
of beuracratic energy, it ends up removing any joy a worker might have found
in the performance of their job. This ends up *increasing* the turnover rate.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Draconian coding standards (was: Ada vs C++ vs Java)

[robert_dewar]

In article <78039c$7vk$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
>
> In isoloation this may not be to bad. But some companies
> hate the way that losses of individuals damage them, so
> they use all sorts of methods to try to force every
> individual to act the same. Not only is this a
> tremendous waste of beuracratic energy, it ends up
> removing any joy a worker might have found
> in the performance of their job. This ends up
> *increasing* the turnover rate.

In a company that is working well, the sense of team spirit
that comes from working together in a cooperative and
consistent manner is a great source of additional
satisfaction to those involved. It sounds like you have
never been fortunate enough to work in such an environment!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Draconian coding standards (was: Ada vs C++ vs Java)

[dennison]

In article <7809ne$dqe$1@nnrp1.dejanews.com>,
  robert_dewar@my-dejanews.com wrote:
> In article <78039c$7vk$1@nnrp1.dejanews.com>,
>   dennison@telepath.com wrote:
> >
> > In isoloation this may not be to bad. But some companies
> > hate the way that losses of individuals damage them, so
> > they use all sorts of methods to try to force every
> > individual to act the same. Not only is this a
> > tremendous waste of beuracratic energy, it ends up
> > removing any joy a worker might have found
> > in the performance of their job. This ends up
> > *increasing* the turnover rate.
>
> In a company that is working well, the sense of team spirit
> that comes from working together in a cooperative and
> consistent manner is a great source of additional
> satisfaction to those involved. It sounds like you have
> never been fortunate enough to work in such an environment!

Twice, but it has been too long...

But I don't see imposing restrictive coding styles causing that. Rather the
team should naturally grow their own style, which they will all eventually
gravitate to if they are truly behaving in the manner you describe. If it
gets written down at all, it should just be so that new folk can assimilate
with the team easier. For instance, in both the aformentioned instances above
there were official written syntax standards but the *team* didn't follow
them. That doesn't mean we didn't have syntax standards. Just that they were
*our* standards, not the ones kept in some document maintained by systems
engineers (who wouln't know Ada code from a Mellville novel).

I don't know...perhaps we're dancing around the same point here.

But if you have managed to set up such an atmosphere where you work, please,
please ignore whatever you hear from me and keep doing what you are doing! :-)


 T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Draconian coding standards (was: Ada vs C++ vs Java)

[robert_dewar]

In article <780fir$j51$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:

>  For instance, in both the aformentioned instances above
> there were official written syntax standards but the
> *team* didn't follow them. That doesn't mean we didn't
> have syntax standards. Just that they were *our*
> standards, not the ones kept in some document maintained
> by systems engineers (who wouln't know Ada code from a
> Mellville novel).

Well most certainly the programming team needs to be
involved in developing these standards.

But I can't buy the idea of not writing them down
carefully. ISO-9000 and many other total quality
approaches are all about documenting how you do things
and then rigorously following these written procedures.

But perhaps you think this ISO-9000 stuff is all a bunch
of beaurocratic rubbish :-)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Draconian coding standards (was: Ada vs C++ vs Java)

[dennison]

In article <7813fe$3sg$1@nnrp1.dejanews.com>,
  robert_dewar@my-dejanews.com wrote:
> In article <780fir$j51$1@nnrp1.dejanews.com>,
> Well most certainly the programming team needs to be
> involved in developing these standards.
>
> But I can't buy the idea of not writing them down
> carefully. ISO-9000 and many other total quality
> approaches are all about documenting how you do things
> and then rigorously following these written procedures.

Perhaps that's OK, if you see what works first, write *it* down, and change
is when your engineers need a change. The problem is when the development
people don't have the lattitude to change the document ever. The document
becomes the holy commandments etched in stone, rather than a sensible way of
doing business.

To mangle an analogy from Brooks, it makes a lot of sense that all of Reims
cathedral be built in the same style. It does not make sense to require that
every cathedral in France be built in the same style.

>
> But perhaps you think this ISO-9000 stuff is all a bunch
> of beaurocratic rubbish :-)

Not entirely. I just don't think where specifying where semicolons get placed
in source code is the right level of detail to be spelling out in corporate
procedures. You might as well have a procedure for where phones are placed on
desks!

I think ISO has more to do with repeatabilty that quality (which is how it is
sold). Not that the two aren't related, but they aren't the same thing
either. But I wouldn't put any stock whatsover in an ISO9K certification. I
have seen orginizations just write down what they *currently* do in a big
hurry right before the ISO audit, pay the exact same auditors extra for a
"pre-audit" (to make sure the real audit will go smoothly of course, wink
wink, say no more.) then promptly forget about the documents after the audit.
So you can see where I could get a bit cynical. The SEI level is more telling
to me.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Draconian coding standards (was: Ada vs C++ vs Java)

[Simon Wright]

dewar@gnat.com writes:

> I would have fired him right away, and thought it was a huge
> mistake. Yes, he was, in the sense of CMM level 1 heroes, a great
> programmer, but you simply cannot tolerate this kind of hacker
> mentality in an disciplined environment committed to sound software
> engineering.

Hmm, there are heroes and heroes! I have always understood the CMM
heroes to be the ones who work all the hours God sends, in spite of
total lack of assistance from their environment, to get the product
built successfully. They may even be led by donkeys too, though
usually it's the blind leading the blind instead[1].

That's quite a different concept from cowboy, which is what I think
Robert is describing (I don't know the American for the concept, aside
from 'hacker', which wouldn't apply to plumbers ..)

[1] No reflection on past/present employers intended.

Re: Draconian coding standards (was: Ada vs C++ vs Java)

[Bob Munck]

On Mon, 18 Jan 1999 15:33:27 GMT, dennison@telepath.com wrote:

>The point is to get all the code readable by anyone with a minimum of effort,
>not to send individualistic developers off to Dhakow. ...

Jeez, in these days of modern times, why are we worrying about doing
manual formatting in any given way?  Just store the source in some
internal or cannonical form, retrieve it with XML markup (say
through ASIS if it's Ada), and have your editor use a good browser
to do its display.  Each programmer can have a personal DFD that
displays the code in the format that they prefer.  (Plus you have
all of the hypertext facilities of the browser to make code editing
and reading easier, such as popping up  the definition of a variable
when the mouse is over it.)

I'll bet you could do an ok editor in a couple of hundred lines
of JavaScript using this approach.  Or, of course, write it in
Ada and compile to the Java VM.

Bob Munck
Mill Creek Systems LC

Re: Draconian coding standards (was: Ada vs C++ vs Java)

[Aidan Skinner]

On Tue, 19 Jan 1999 18:20:57 GMT, Bob Munck <munck@Mill-Creek-Systems.com> 
wrote:

>to do its display.  Each programmer can have a personal DFD that
>displays the code in the format that they prefer.  (Plus you have

mutter mutter mutter emacs mutter mutter mutter

- Aidan
-- 
You know it's time to stop playing Quake2 when KILL KILL KILL KILL KILL
KILL KILL KILL KILL KILL KILL KILL KILL KILL KILL KILL KILL KILL KILL KILL
http://www.skinner.demon.co.uk/aidan/
http://www.gla.ac.uk/Clubs/WebSoc/~9704075s/

Re: Draconian coding standards (was: Ada vs C++ vs Java)

[robert_dewar]

In article <36a4c9f4.304346937@news.mindspring.com>,
  munck@Mill-Creek-Systems.com (Bob Munck) wrote:
> On Mon, 18 Jan 1999 15:33:27 GMT, dennison@telepath.com
wrote:
>
> >The point is to get all the code readable by anyone with
a minimum of effort,
> >not to send individualistic developers off to Dhakow.
...
>
> Jeez, in these days of modern times, why are we worrying
> about doing manual formatting in any given way?  Just
> store the source in some
> internal or cannonical form, retrieve it with XML markup
> (remainder of obvious thought snipped).

There are many reasons why this does not work in practice.
See previous thread (which is itself a repeat of many
previous threads on the subject). And if you *currently*
work in an environment where this is routinely done, let
us know more details. Ideas don't solve problems on their
own, engineered solutions to problems based on ideas can,
but in this case, the devil is in the details.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[dennison]

In article <77ommt$9bo$1@nnrp1.dejanews.com>,
  robert_dewar@my-dejanews.com wrote:

> any software production at all. Any programmer who is
> uncomfortable with following an established set of
> conventions is also out of control and should be got
> rid of. The industry simply cannot afford such a level
> of incompetence.

Spoken like a man who gets to write the standards... :-)

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Larry Kilgallen]

In article <77vhjf$nn9$1@nnrp1.dejanews.com>, dennison@telepath.com writes:
> In article <77ommt$9bo$1@nnrp1.dejanews.com>,
>   robert_dewar@my-dejanews.com wrote:
> 
>> any software production at all. Any programmer who is
>> uncomfortable with following an established set of
>> conventions is also out of control and should be got
>> rid of. The industry simply cannot afford such a level
>> of incompetence.
> 
> Spoken like a man who gets to write the standards... :-)

If by "standards" you mean the ACT shop standards, Robert Dewar
has specified that they take a vote when resolving religious
issues (possibly not on more serious issues like whether to
engage in backups of the machines, whether to put the comments
in English or Esperanto, etc.)

Larry Kilgallen

Re: Ada vs C++ vs Java

[robert_dewar]

In article <77vhjf$nn9$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> In article <77ommt$9bo$1@nnrp1.dejanews.com>,
>   robert_dewar@my-dejanews.com wrote:
>
> > any software production at all. Any programmer who is
> > uncomfortable with following an established set of
> > conventions is also out of control and should be got
> > rid of. The industry simply cannot afford such a level
> > of incompetence.
>
> Spoken like a man who gets to write the standards... :-)


Actually -- no ...

In ACT, if we have to make an arbitrary style decision,
like what capitalization to use, or what indentation, we
simply take a vote with the understanding that the result
of the vote is binding on everyone.

In the case of capitalization, I use to prefer all caps,
and I still like the fact that this convention makes it
easier to see identifier names in comments.

But the majority preferred mixed-case, so I changed. It
took a little while to get used to, but now I am used to
it and it would be hard to go back.

That's the real point, you quickly get used to any
particular style, so fighting furiously to maintain your
own style is a sign of non-cooperative behavior that is
unlikely to be the mark of a good team player.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Crazy Pete]

> In ACT, if we have to make an arbitrary style decision,

Just out of curiosity, what is ACT?

> That's the real point, you quickly get used to any
> particular style, so fighting furiously to maintain your
> own style is a sign of non-cooperative behavior that is
> unlikely to be the mark of a good team player.

I have watched this thread with some interest.  I still prefer to be 
generous and say this is all a matter of opinion.  I am sure there are
many people who would not want to work in a shop where strict 
standards regarding brace placement, number of columns to indent, etc.
are not enforced.  I am also sure there are a number of others (myself
included) who would refuse to work in a shop where such strict 
standards are enforced.  Being as I began coding in C++ more than 11 
years ago, I am usually the senior programmer on most projects and I 
am expected to mentor more junior individuals.  There are some 
standards that have to be enforced, but we leave things like code 
format (indentation, brace placement, etc.) up to the individual.  
E.g. :

if ( boolCondition )
  doSomething () ;

Would NEVER be allowed, because there are no braces, but we leave the 
individual free to :


if ( boolCondition ) {
  doSomething () ;
}


if ( boolCondition )
{
      doSomething () ;
}


if ( boolCondition )
      {
      doSomething () ;
      }


Or whatever else.  I always try to encourage each person to "own" 
individual modules and be responsible for them.  I have found this 
encourages a sense of pride in their work.   By letting them determine
their own style they also enjoy what they are doing to a much greater 
degree and learn faster and become more productive.  Also as you get 
to know your programmers and their coding styles, it becomes very easy
to maintain their code because you begin to associate their strengths 
and weakness with a particular style.  E.g.  "This section of code has
braces placed as such, this must be Ben's code, Ben is very good with 
X but keeps forgetting to Y, therefore let's check the Y first - yep 
that was the problem!"  Again I think this is all a matter of opinion.
 I would not work in a shop such as Dr. Dewar advocates and Dr. Dewar 
would not work in an environment where I would be happy.  I will say 
this, however, I DO have a reputation for getting projects in well 
ahead of deadline and having the results work very well.  But I think 
this has more do to with my refusal to participate in any project 
where Microsoft products are involved than it does with my refusal to 
work in overly strict environments. ;-)  BTW, I am a freelance 
consultant, so I may choose which projects I work on and which I do 
not.

Peace

Peter

Re: Ada vs C++ vs Java

[robert_dewar]

In article <YkGBP4MNXb2t-pn2-bjzMwxf6POdh@localhost>,
  peter.garner@toward.com (Crazy Pete) wrote:

> > In ACT, if we have to make an arbitrary style decision,
>
> Just out of curiosity, what is ACT?

Ada Core Technologies

which provides support and development for GNAT
Professional, the fully supported commercial Ada 95
compiler and tool suite, based on GNU/gcc technology.
See www.gnat.com for details. Publicly available versions
of these compilers are available for downloading, go to
the FTP directories pub/gnat at cs.nyu.edu.

Robert Dewar
Ada Core Technologies

P.S. The sources are of course also available, so you can
have a look at them to understand what I mean by uniform
style.

P.P.S. I find it a very bad idea not to standardize on
brackets placement in C/C++. It is a perfect example of
an issue where there can be no advantage in inconsistency.
If you really have programmers who would quit rather than
follow shop standards on such minor details, they will be
unmanageable on more major things, and it is good to find
that out in advance.

Notice that management here to me is far more than just
A following the orders of B, it is figuring out how a team
works together in a cooperative and effective manner.


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Christopher Browne]

On Tue, 19 Jan 1999 21:00:22 GMT, robert_dewar@my-dejanews.com
<robert_dewar@my-dejanews.com> wrote: 
>P.P.S. I find it a very bad idea not to standardize on
>brackets placement in C/C++. It is a perfect example of
>an issue where there can be no advantage in inconsistency.
>If you really have programmers who would quit rather than
>follow shop standards on such minor details, they will be
>unmanageable on more major things, and it is good to find
>that out in advance.

And this is an example of putting concentration in the wrong place. 

There are automated indentation utilities such as GNU Indent that know
how to cope with a wide variety of styles. 

If there are programmers who prefer one format, and others that prefer
another, they can have a common format imposed on the CVS archives, and
then use what ever format they prefer personally on checked out copies.
If the organization or the people are so inflexible that something like
this isn't possible, then something's wrong. 

-- 
"In elementary school, in case of fire you have to line up quietly in a
single file line from smallest to tallest. What is the logic? Do tall
people burn slower?" -- Warren Hutcherson
cbbrowne@hex.net- <http://www.ntlug.org/~cbbrowne/lsf.html>

Re: Ada vs C++ vs Java

[bill]

In article <6Oap2.16170$MW1.4028@news2.giganews.com>, cbbrowne@news.hex.net
says...
>
 
>
>There are automated indentation utilities such as GNU Indent that know
>how to cope with a wide variety of styles. 
>
>If there are programmers who prefer one format, and others that prefer
>another, they can have a common format imposed on the CVS archives, and
>then use what ever format they prefer personally on checked out copies.
>If the organization or the people are so inflexible that something like
>this isn't possible, then something's wrong. 
>
 
maybe eveyone should code in python. in python there are no braces and
no BEGIN END. the way the block is from is by indentation! 

python has solved this life lone problem of where to places the braces!

I think however, having a uniform style is the best solution. one can really
get used to any style. I prefer

if a
{
  ...
}

but if I have to use

if a{
   ...
}

then I would. it is no big deal really !!

btw, since Ada has no braces, what is the problem? this only seems to
be C/C++/Java thing, since those uses braces.

Bill.

Re: Ada vs C++ vs Java

[dennison]

In article <783nnb$s9c@drn.newsguy.com>,
  bill@nospam.com wrote:

> btw, since Ada has no braces, what is the problem? this only seems to
> be C/C++/Java thing, since those uses braces.

The braces are really just a cryptic shorthand for "begin" and "end", which
Ada does have.

A good example of an Ada syntax spat is listing procedure parameters in
function bodies. Say I have a fuction w/ 2 input parameters. Here are a few
of the ways I have seen that written out.

(1)
function foo (Left : in Integer; Right : in Float) return Boolean is
begin
   ...
end foo;

(2)
function foo (Left  : in Integer;
              Right : in Float) return Boolean is
begin
   ...
end foo;

(3)
function foo
  (Left  : in Integer;
   Right : in Float) return Boolean is

(4)
function foo
  (Left  : in Integer;
   Right : in Float
  ) return Boolean is

(5)
function foo
  ( Left  : in Integer
  ; Right : in Float
  ) return Boolean is

(6)
function foo (Left  : in Integer;
              Right : in Float)
  return Boolean
is
begin

...I could go on and on. And of course Ada "style guides" will typically
require one and only one of these formats to be used. A sensible programmer
would switch from style (1) or (2) when they run out of space on the line to
something like style (3) or (4). Remember that Ada developers tend to use
fairly long identifier names, so this can easily happen. But if the style
guide doesn't give you that lattitude, you might be forced to stick with the
other style but make one of the lines wrap to the next line. That's much
tougher to read. More typically the style guide gets ignored because
following it would be counter-productive. But that's an awfully slippery
slope...

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[robert_dewar]

In article <784qvi$a0a$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> A good example of an Ada syntax spat is listing procedure
> parameters in function bodies.

The GNAT style rules are as follows, and yes everyone
at ACT follows them:

  function x (y : integer) return Boolean is
     ... declarations
  begin
     ... statements
  end x;

Above is used if it fits on one line

  function x
    (Hello : Integer;
     Goodbye : Integer)
     return    Integer
  is
     ... declarations
  begin
     ... statements
  end x;

if the prototopye takes more than one line.

> And of course Ada "style guides" will typically require
> one and only one of these formats to be used.

An old debater's trick, set up a silly strawman, and knock
it down. I never saw a set of guidelines that was obviously
wrong in this respect.

Remember

(a) no one is arguing in favor of demonstrably silly
    style guidelines.

(b) no one will accept that absurd notion that all style
    guidelines are bound to be demonstrably silly.

So please don't produce examples of idiotic rules as a
reason to have no rules!!!!!!

> More typically the style guide gets ignored because
> following it would be counter-productive. But that's an
> awfully slippery slope...

Indeed, which is why I think failure to follow style guide
lines should not for a moment be tolerated. If the problem
is that there is something wrong with the guidelines, fix
them, don't ignore them!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[dennison]

In article <78549k$iqv$1@nnrp1.dejanews.com>,
  robert_dewar@my-dejanews.com wrote:
> In article <784qvi$a0a$1@nnrp1.dejanews.com>,
>   dennison@telepath.com wrote:
> (a) no one is arguing in favor of demonstrably silly
>     style guidelines.

Hmm. I didn't find any of those examples *silly*. The exception is perhaps
the leading ';' rule, which was from an *actual* style guide for a project I
worked on.

> (b) no one will accept that absurd notion that all style
>     guidelines are bound to be demonstrably silly.

Its just as absurd to claim that they are all perfect.

> lines should not for a moment be tolerated. If the problem
> is that there is something wrong with the guidelines, fix
> them, don't ignore them!

I was on two programs where the style guide was a project deliverable with a
deadline *before* coding started. When silly parts of the guide were stumbled
across, it was not *possible* to go back and change the guide.

I worked on another with over 100 developers. Any change to a deliverable
like the style guide had to go the the "Engineering Review Board". That board
was mostly staffed with managers, including the very high level engineer who
"owned" the style guide. He had nothing else to do and was highly sensitive
to any criticism (and had never written a line of Ada). For masses of
low-level engineers this was a daunting body that you did *not* go in front
of on a lark. Far better would be to start a grassroots movement for a
different style, and let the style guide nazi either fix the guide, or try to
convince the engineers though email why the official method was better, or
give out "waivers" on a selective basis.

I take it its not so tough to change the guide where you work...

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[dewar]

In article <785enu$sq5$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> In article <78549k$iqv$1@nnrp1.dejanews.com>,
>   robert_dewar@my-dejanews.com wrote:
> > In article <784qvi$a0a$1@nnrp1.dejanews.com>,
> >   dennison@telepath.com wrote:

> > (a) no one is arguing in favor of demonstrably silly
> >     style guidelines.
>
> Hmm. I didn't find any of those examples *silly*. The
> exception is perhaps the leading ';' rule, which was from
> an *actual* style guide for a project I worked on.

No, the silly thing from your point of view (in your post)
was requiring the use of ONE of these in all cases even
when it is inappropriate.
>
> > (b) no one will accept that absurd notion that all
> >     style guidelines are bound to be demonstrably
> >     silly.
>
> Its just as absurd to claim that they are all perfect.

Yes, but no one has argued that. You have been arguing
against style guide lines all together and then using
as your argument examples of silly rules. Please look at
your previous posts in the thread, you have made some
quite sweeping statements about *all* guidelines.


> > If the problem is that there is something wrong with
> > the guidelines, fix them, don't ignore them!
>
> I was on two programs where the style guide was a project
> deliverable with a deadline *before* coding started.

A very reasonable requirement, and one that should be
easy to meet, since any well run shop should have a well
tried and true set of familiar guidelines on the shelf.

> When silly parts of the guide were stumbled across, it
> was not *possible* to go back and change the guide.

But as I say, the guidelines should have been established
well in advance, furthermore, there are plenty of places
to go to get established sets of rules that are known to
be workable. Feel free to borrow the ACT ones :-)
>
> I worked on another with over 100 developers. Any change
> to a deliverable
> (details on a silly situation snipped)

This is not an argument against having a well chosen set
of style guidelines. You can't use one example of
incompetence to argue against an entire principle.
Some people drive cars incompetently, shall we ban
all driving as a result?

Actually it would be interesting to see from this
environment where it is hard to change things whether
or not the changes were really justified, or were just
people chafing under having to change what they are
used to. My experience is that most often it is the
latter and not the former.

> I take it its not so tough to change the guide where you
> work...

At this stage, at Ada Core Technologies, it would be almost
impossible to make a significant change to our style, since
even the smallest change would be very disruptive, both to
our common sources, and to everyone's ingrained habits. We
do sometimes make changes. For example, we recently fixed
our habit of mispelling runtime thus (instead of the
proper run-time when used as an adjective). We did this
because Digital pointed out this error in our documentation
when we were doing the VMS port, and we wanted our sources
consistent. This was about as tiny a change as you can
imagine, but it required hundreds of files to be updated.

We occasionally consider adding new rules, but at this
point we are so settled down with our existing set of rules
that it is no longer an issue.

You would find the situation in most well run shops.
Certainly at Alsys the rules had been established early
on, and were not an issue (except for the one employee
who simply refused to follow them as I mentioned in a
previous post).

Yes, I can see that if a shop got a project for which
coding style rules were a deliverable, and had nothing
on the shelf, it would be in trouble, but that's
self made trouble caused by incompetent management.

You definitely need to iterate and fix and polish to get
a workable set of coding rules that will work in your
environment. Having to do it in a hurried manner to meet
a contract deliverable sounds like a horrible situation
to me!

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[bourguet]

In article <787bv0$gr8$1@nnrp1.dejanews.com>,
  dewar@gnat.com wrote:

> > When silly parts of the guide were stumbled across, it
> > was not *possible* to go back and change the guide.
>
> But as I say, the guidelines should have been established
> well in advance, furthermore, there are plenty of places
> to go to get established sets of rules that are known to
> be workable. Feel free to borrow the ACT ones :-)

Just out of curiosity, are they available somewhere ?

-- Jean-Marc

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[dennison]

In article <787bv0$gr8$1@nnrp1.dejanews.com>,
  dewar@gnat.com wrote:

> Yes, but no one has argued that. You have been arguing
> against style guide lines all together and then using
> as your argument examples of silly rules. Please look at
> your previous posts in the thread, you have made some
> quite sweeping statements about *all* guidelines.

No. I never argued *against* them. I have argued that guides should not
include minutia like parentheses placement, or that developers should not be
*forced* to follow them to that level; encouraged perhaps but not forced.
Unless I'm mistaken, that's what "guideline" means.

Unless you count the above, I don't think you are correct about me making
"sweeping statements about style guidelines". But my memory's bad enough that
I'll admit the possibility (I'm not sure *why* I would take such an
easily-disproved approach to arguing a point, but it wouldn't be the first
stupid thing I ever did). So I have done as you suggested and gone through
dejanews looking for somewhere where I made a "sweeping statement about all
style guidelines". Perhaps my query skills are not so hot, but I can't find
any such statement. If someone could point me to the posts of mine Robert got
this impression from, I'd appreciate it.

I did find a whole lot of posts about specific situations where requiring
strict adherence causes problems. Two of these counter-examples got dismissed
as "silly", even though they were both real situations I have found myself in
(funny, I wasn't laughing at the time...)

> > I was on two programs where the style guide was a project
> > deliverable with a deadline *before* coding started.
>
> A very reasonable requirement, and one that should be
> easy to meet, since any well run shop should have a well
> tried and true set of familiar guidelines on the shelf.

Not if they have never before used the language in question!

> This is not an argument against having a well chosen set
> of style guidelines. You can't use one example of
> incompetence to argue against an entire principle.

(sigh) I'm not arguing against the principle of using good style guidelines.
I'm arguing against the principle of automaticly firing *any* engineer who
has a problem following a portion of a style guidline that is buggy (please
allow me to use "buggy" rather than the more subjective and deragatory
"silly").

I think all this time we have been arguing about two different things. The sad
thing about it is that you just about have me convinced on what *you* were
arguing about. I'll have to try it sometime.

> Actually it would be interesting to see from this
> environment where it is hard to change things whether
> or not the changes were really justified, or were just
> people chafing under having to change what they are
> used to. My experience is that most often it is the
> latter and not the former.

In the "silly" example I gave, the *entire* staff was new to Ada. No one had a
style of their own before the project started. Everyone (with one possible
exception) picked up and used the style guide's style for most things. The
problem was that it had holes, which isn't horribly suprising for a first
effort.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[dennison]

In article <78549k$iqv$1@nnrp1.dejanews.com>,
  robert_dewar@my-dejanews.com wrote:
> In article <784qvi$a0a$1@nnrp1.dejanews.com>,
> The GNAT style rules are as follows, and yes everyone
> at ACT follows them:
>
>   function x (y : integer) return Boolean is
>      ... declarations
>   begin
>      ... statements
>   end x;
>
> Above is used if it fits on one line
                ^^^^^^^^^^^^^^^^^^^^^^
Good rule.

>
>   function x
>     (Hello : Integer;
>      Goodbye : Integer)
>      return    Integer

I do have to admit, I see no reason why following this guideline should be a
big problem for anyone (except perhaps the leading ';' devotees). I would
have a tough time at first not lining up the ':'s. I'm pretty used to the
implicit "in"s being supplied too.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[robert_dewar]

In article <785fo3$thj$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> >
> >   function x
> >     (Hello : Integer;
> >      Goodbye : Integer)
> >      return    Integer
>
> I do have to admit, I see no reason why following this
> guideline should be a big problem for anyone (except
> perhaps the leading ';' devotees). I would have a tough
> time at first not lining up the ':'s. I'm pretty used to
> the implicit "in"s being supplied too.

Actually we do line up the colons, that was an editing
typo on my part. As for implicit IN's that seems entirely
redundant in the function case. Of course the whole point
here is the "I'm pretty used to" phrase.

Yes, everyone is "pretty used to" a particular style, and
feels more comfortable in that style. That is the entire
point of my posts in this thread. What you want is that
everyone feel comfortable with everyone else's code and
that everyone is "pretty used to" the same style.

Yes, it takes a bit of an adjustment. For a long time I
followed the Alsys style rules, since I wrote most of my
Ada code for Alsys, and I certainly got used to it. At
this stage, having got used to the GNAT rules, which are
different, it would be an adjustment to go back to the
Alsys rules (all cap identifiers for example).

But for most people, other than unmanagable "devotees",
it is no big deal to adjust your style, it just takes a
little while, actually often a suprisingly short little
while, and surprisingly little effort, to switch what
you are "pretty used to".

In my experience the gain in working harmony in a group
is well worth this slight adjustment, and most certainly
for someone coming to the sources, it is a huge advantage
if the sources are consistent in style.

One important point here is that one should reach for even
greater consistency in style, far beyond simple syntax
rules. You cannot of course legislate or automate this
kind of consistency, but if you have a team that is
committed to the idea that consistency is important to
make it easier for people to understand one another's
code, and that is happy to conform on the simple syntax
issues then you have a much better chance of achieving
this greater level of consistency.

A note here is that for me, an essential element of
this kind of consistency is simplicity. Yes it is very
important that Ada has a large arsenal of powerful
features, but I am always amazed to see programs which
use all sorts of very complex features to achieve very
simple goals. My image is of a fire department rolling
out all available fire trucks, including specialized
ladders etc, just to put out a fire in a trash basket :-)

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Matthew Heaney]

dennison@telepath.com writes:

> I do have to admit, I see no reason why following this guideline should be a
> big problem for anyone (except perhaps the leading ';' devotees). I would
> have a tough time at first not lining up the ':'s.

If you use emacs, then move to the parameter list, type C-c C-f, and
life is good...

Re: Ada vs C++ vs Java

[Al Christians]

Matthew Heaney wrote:
> 
> dennison@telepath.com writes:
> 
> > I do have to admit, I see no reason why following this guideline should be a
> > big problem for anyone (except perhaps the leading ';' devotees). I would
> > have a tough time at first not lining up the ':'s.
> 
> If you use emacs, then move to the parameter list, type C-c C-f, and
> life is good...

If I'm the boss, I'm going to ban any editor that encourages my staff
to take the time to reformat code every time they check it in or out.
I'm going to get ever-lovin' livid if a macrographical error at this
point introduces a bug into a product. And I'm going to start handing
out applications for employment over at the post office if (a) the guy 
who is supposed to find the bug has to reformat the code again before 
he can start looking for it, or (b) each of the two coders who might 
have created the bug insists that the other one did it when he 
re-formatted their perfectly good code.

When everything is going well, it is.  But in the software business, 
you have to do a little risk management.  This is the kind of
distraction 
that can make a bad situation much worse.  Robert Dewar is not only 
beyond criticism on this one, he's largely correct.

Al

Re: Ada vs C++ vs Java

[Matthew Heaney]

Al Christians <achrist@easystreet.com> writes:

> Matthew Heaney wrote:
> > 
> > dennison@telepath.com writes:
> > 
> > > I do have to admit, I see no reason why following this guideline should be a
> > > big problem for anyone (except perhaps the leading ';' devotees). I would
> > > have a tough time at first not lining up the ':'s.
> > 
> > If you use emacs, then move to the parameter list, type C-c C-f, and
> > life is good...
> 
> If I'm the boss, I'm going to ban any editor that encourages my staff
> to take the time to reformat code every time they check it in or out.

That is certainly not what I was referring to!  You're not using emacs?

C-c C-f runs the command ada-format-paramlist, which reformats a
parameter list of a subprogram or task entry.  

All it does is turn this:

procedure Push 
 (Item : in Item_Type;
  On : in out Stack_Type);

into this:

procedure Push
  (Item : in     Item_Type;
   On   : in out Stack_Type);

What's the problem?

Re: Ada vs C++ vs Java

[Al Christians]

Matthew Heaney wrote:
> 
> 
> procedure Push
>  (Item : in Item_Type;
>   On : in out Stack_Type);
> 
> into this:
> 
> procedure Push
>   (Item : in     Item_Type;
>    On   : in out Stack_Type);
> 
> What's the problem?

If that's just a way to make sure that newly-written code complies 
with a standard before it gets stored, there is no problem.

Perhaps I misunderstood.  I thought that you were saying that 
the power of C-c C-f and similar automated features was sufficient 
to allow wide variation in working copies of code based on individual 
programmer preferences without any significant disadvantages.  I 
don't think that's true; significant disadvantages are: 1) too much 
time wasted de-standardizing code after  check-out, 2) too much time 
wasted re-standardizing code before check-in, 3) chance of error being 
introduced in 1) and 2), and 4) likelihood that after code has gone 
through automated standardization, it will not be exactly identical to 
previous standardized version, leading to many false deltas found by 
diff. 

Al

Re: Ada vs C++ vs Java

[Matthew Heaney]

Al Christians <achrist@easystreet.com> writes:

> Matthew Heaney wrote:
> > 
> > 
> > procedure Push
> >  (Item : in Item_Type;
> >   On : in out Stack_Type);
> > 
> > into this:
> > 
> > procedure Push
> >   (Item : in     Item_Type;
> >    On   : in out Stack_Type);
> > 
> > What's the problem?
> 
> If that's just a way to make sure that newly-written code complies 
> with a standard before it gets stored, there is no problem.

Yes, that is that case.  You type in the declaration "loosely," as in
the former declaration above, type C-c C-f when you're done typing that
declaration, and then you get the latter declaration.  

When you're all done with your edits, and all your code is compliant
with coding standards, then you check it back in.

> Perhaps I misunderstood.

Yes.

> I thought that you were saying that the power of C-c C-f and similar
> automated features was sufficient to allow wide variation in working
> copies of code based on individual programmer preferences without any
> significant disadvantages.

No.

> I don't think that's true; significant disadvantages are: 1) too much
> time wasted de-standardizing code after check-out, 2) too much time
> wasted re-standardizing code before check-in, 3) chance of error being
> introduced in 1) and 2), and 4) likelihood that after code has gone
> through automated standardization, it will not be exactly identical to
> previous standardized version, leading to many false deltas found by
> diff.

I agree with Robert Dewar here.  Everyone should follow a standard.  Get
rid of pretty printers and other automatic code formatters.  Tools like
that are useless, and only promote programmer laziness and divisiveness.

Emacs is the only tool you need to edit program text.

Re: Ada vs C++ vs Java

[bill_1]

In article <m3n23c3v8b.fsf@mheaney.ni.net>, Matthew says...
>
 
>> > What's the problem?
>> 
>> If that's just a way to make sure that newly-written code complies 
>> with a standard before it gets stored, there is no problem.

>
>Yes, that is that case.  You type in the declaration "loosely," as in
>the former declaration above, type C-c C-f when you're done typing that
>declaration, and then you get the latter declaration.  
>
>When you're all done with your edits, and all your code is compliant
>with coding standards, then you check it back in.
>

Not only this is a good idea, but how else will one makes sure their
code is formatted in consistant way other than using a standard formating
pattern with the help of a tool?

I beleive the best solution is as shown above.

Eveyone will agree on ONE standard format.

Then before the code is checked in, one enters few commands to format the
code to this common format.

I can't imagine having to format the code by hand all the time. my eyes
does not always measure the amount of space correctly, and it is a waste
of time to having to do this by hand all the time, when with one or two
simple command, the code can be transformed into this common format much
faster.

Bill.
 

Re: Ada vs C++ vs Java

[Matthew Heaney]

bill_1@nospam.com writes:

> In article <m3n23c3v8b.fsf@mheaney.ni.net>, Matthew says...
> >
> >When you're all done with your edits, and all your code is compliant
> >with coding standards, then you check it back in.
> >
> 
> Not only this is a good idea, but how else will one makes sure their
> code is formatted in consistant way other than using a standard formating
> pattern with the help of a tool?
> 
> I beleive the best solution is as shown above.
> 
> Eveyone will agree on ONE standard format.
> 
> Then before the code is checked in, one enters few commands to format the
> code to this common format.

Not quite.  The standards-compliant formatting is done on-the-fly, not
just before you check the code in.

When using emacs, using C-j instead of RET indents the current line to
its proper place, and then moves you to the next line, with the cursor
properly indented.

For more complex formatting, you may have to issue another key sequence
to format code.  For example:

C-c C-w to format the with statements ala ACT:

with Pretty;  use Pretty;
with Girl;    use Girl;


C-C C-r to format a record declaration, i.e. go from this:

  type T is
    record
       Isnt_This_Where : Integer;
       We_Just : Float;
       Came_In_Another : Brick;
       In_The_Wall : Pink;
    end record;

to this

  type T is
    record
      Isnt_This_Where : Integer;
      We_Just         : Float;
      Came_In_Another : Brick;
      In_The_Wall     : Pink;
    end record;


It's never necessary to lay this out by hand.  You issue the command as
soon as you (loosely) type the record declaration in, and then emacs
will properly format it.

On my list of things to do is teach emacs (ada-mode) how to format a
record representation clause.

So it's never the case that I type in the code without any formatting,
and then let emacs just automatically reformat it to compliance at
check-in time.  The code gets properly formatted on-the-fly, at the time
of writing.

And of course, absolutely no tabs are inserted at any time in the file.
Tabs do nothing except reek havoc with formatting algorithms, and cause
very strange-looking print jobs.  Thank goodness, er, I mean, RMS, for
untabify.

I'm going to be taking over maintenance of ada-mode in another month or
so.  If you have any suggestions for me, let me know.

Matt

Ada mode requests (Re: Ada vs C++ vs Java)

[dennison]

In article <m3hftjstg6.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:

> I'm going to be taking over maintenance of ada-mode in another month or
> so.  If you have any suggestions for me, let me know.

I'd like to see a submode or new mode for editing gnat.adc files. But I
suppose I might be the only person who would use it.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada mode requests (Re: Ada vs C++ vs Java)

[David C. Hoos, Sr.]

dennison@telepath.com wrote in message <78a27f$rp4$1@nnrp1.dejanews.com>...
>In article <m3hftjstg6.fsf@mheaney.ni.net>,
>  Matthew Heaney <matthew_heaney@acm.org> wrote:
>
>> I'm going to be taking over maintenance of ada-mode in another month or
>> so.  If you have any suggestions for me, let me know.
>
>I'd like to see a submode or new mode for editing gnat.adc files. But I
>suppose I might be the only person who would use it.
>
Matt,

Glad to have a name attached to the maintenance/fixing of ada-mode.

ada-mode 3.0 is a quantum leap from 2.28, but there are still a few niggling
problems -- e.g., indentation doesn't work right in protected types; in some
contexts parameter lists are not recognized as parameter lists, etc.

As I encounter specific cases I'll send them to you.  I hadn't wanted to
bother ACT with it, since getting the executable-generation tools right is
more important.

David C. Hoos, sr.

Re: Ada mode requests (Re: Ada vs C++ vs Java)

[dewar]

In article <78age5$p8v@hobbes.crc.com>,
  "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:
> As I encounter specific cases I'll send them to you.  I
> hadn't wanted to bother ACT with it, since getting the
> executable-generation tools right is
> more important.

ACT spends considerable resources on updating and improving
Ada mode, since EMACS is at the center of one of our
integrated development environments, so it is most
certainly worth sending suggestions to us. We will of
course acquire useful suggestions from wherever we see
them, but sending mail to report@gnat.com is certainly the
most direct way to make specific suggestions to us.

In any case I suggest waiting till you see the latest 3.11
version, since that represents a big jump in capability
(really 3.11 is the first version of Ada mode that we
consider to begin to have the needed functionality).

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada mode requests (Re: Ada vs C++ vs Java)

[John McCabe]

dewar@gnat.com wrote:

> ACT spends considerable resources on updating and improving
> Ada mode, since EMACS is at the center of one of our
> integrated development environments, so it is most
> certainly worth sending suggestions to us.

Well it's a pity you didn't start off with the latest version of
ada-mode before modifying it to produce the 3.1 version on the
cs.nyu.edu site. There are quite a few bugs in the version that's there,
some of which have already been fixed in the last version that was
distributed to the emacs ada-mode mailing list. Also, there's a comment
from your bloke about having done a major rewrite of the indenting code
- I can see no evidence of a major rewrite, all he's done is take out a
couple of bits (i.e. references to GEI and ada-format) that probably
nobody used anyway!

> In any case I suggest waiting till you see the latest 3.11
> version, since that represents a big jump in capability
> (really 3.11 is the first version of Ada mode that we
> consider to begin to have the needed functionality).

Well if you make an announcement on this newsgroup, I'll keep an eye out
for it and see whether you've left any of the bugs in that I know about.

John

PS. A couple of suggestions for 3.1...

Try:

1) Set ada-case-attribute to ada-loose-case-word, ada-case-keyword to
downcase word.

Open a new file and enter some Ada code.

Insert a character constant e.g. 'a'

What happens when you put the closing "'" on the character constant? I
would expect you to get 'A'

2) Insert a line of code that uses the 'Access attribute.

Select the whole buffer and the ada-adjust-caase-region.

What happens to 'access? does it stay as 'Access or become 'access? (The
first case is correct - second is wrong.

3) finally put in a procedure specification eg.

procedure x_z (y : in integer);

place point on the y.

M-x eval-expression
(ada-in-paramlist-p)

result should be t. It is a bug (that I know how to fix) if you get nil.

If you are seeing any of this behaviour and want to know how to fix it,
please let me know.

Re: Ada mode requests (Re: Ada vs C++ vs Java)

[John McCabe]

John McCabe wrote:

> Also, there's a comment
> from your bloke about having done a major rewrite of the indenting code
> - I can see no evidence of a major rewrite, all he's done is take out a
> couple of bits (i.e. references to GEI and ada-format) that probably
> nobody used anyway!

I'd like to apologise to Emmanuel Briot for this comment. I failed to
notice that this was something that was already in V2.27 of ada-mode
when I was comparing his Version 3.1 with my V2.28.

Sorry Emmanuel.

Best Regards
John

Re: Ada mode requests (Re: Ada vs C++ vs Java)

[dewar]

In article <36B0FEF4.381F@gecm.com>,
  John McCabe <john.mccabe@gecm.com> wrote:
> dewar@gnat.com wrote:
>
> > ACT spends considerable resources on updating and
> > improving
> > Ada mode, since EMACS is at the center of one of our
> > integrated development environments, so it is most
> > certainly worth sending suggestions to us.
>
> Well it's a pity you didn't start off with the latest
> version of ada-mode before modifying it to produce the
> 3.1 version on the cs.nyu.edu site.

Remember that the sources for 3.11 were frozen a while ago
(a couple of months), so you are not seeing an up to date
snap shot here! But in any case, I would think that emacs
stuff of this kind should be VERY amenable to the
let-the-world-play-and-improve mode of open source software
(unlike perhaps the visibility analysis circuitry of the
front end), so we welcome any improvements etc, and we will
be happy to post any new versions at the cs.nyu.edu site.
In fact I think Marcus Kuhn will be organizing this kind of
activity around the Linux port, and this is exactly the
sort of area where we should see that the community can do
a better job than any one person :-)

The really important new functionality is the connection to
the new cross-referencing information in the ali file. Even
that is fairly straightforward, since the ali formats are
well documented (see the file lib-writ.adb).

At ACT, our work on the EMACS Ada mode is focussed on what
our own internal EMACS users want and what our customers
want, but this is very definitely an area where lots of
people have lots of useful ideas, and where lots of people
know enough technically about how things are done to
contribute.

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada mode requests (Re: Ada vs C++ vs Java)

[John McCabe]

dewar@gnat.com wrote:
 
> In article <36B0FEF4.381F@gecm.com>,
>   John McCabe <john.mccabe@gecm.com> wrote:

> > > ACT spends considerable resources on updating and
> > > improving
> > > Ada mode, since EMACS is at the center of one of our
> > > integrated development environments, so it is most
> > > certainly worth sending suggestions to us.

> > Well it's a pity you didn't start off with the latest
> > version of ada-mode before modifying it to produce the
> > 3.1 version on the cs.nyu.edu site.
 
> Remember that the sources for 3.11 were frozen a while ago
> (a couple of months), so you are not seeing an up to date
> snap shot here!

Granted, but even then V2.28 had been available from the ada-mode
mailing list for quite a loong time.

> But in any case, I would think that emacs
> stuff of this kind should be VERY amenable to the
> let-the-world-play-and-improve mode of open source software
> front end), so we welcome any improvements etc, and we will
> be happy to post any new versions at the cs.nyu.edu site.
> In fact I think Marcus Kuhn will be organizing this kind of
> activity around the Linux port, and this is exactly the
> sort of area where we should see that the community can do
> a better job than any one person :-)

I think we need to make sure we know who is going to be maintaining
ada-mode then. Rolf Ebert did a brilliant job of it, but won't be doing
it any longer. Latest news on this group was that Matt Heaney would be
doing it. I heard this only a day or two after I had contacted Rolf to
find out what was happening with ada-mode, and he said he was still
looking for someone to take over maintenance.

So if anyone out there knows and definitive detail, let us know. You
could start off by posting to ada-mode@email.enst.fr.

> The really important new functionality is the connection to
> the new cross-referencing information in the ali file. Even
> that is fairly straightforward, since the ali formats are
> well documented (see the file lib-writ.adb).

I was using ada-xref.el a couple of years ago with Emacs 19.34 and GNAT
3.05.
 
> At ACT, our work on the EMACS Ada mode is focussed on what
> our own internal EMACS users want and what our customers
> want, but this is very definitely an area where lots of
> people have lots of useful ideas, and where lots of people
> know enough technically about how things are done to
> contribute.

I am glad you look at it that way and I will be happy to help with
comments, suggestions and bugfixes, especially at the moment until we
can sort out some method of merging the work that Rolf Ebert put in
after V2.27, the work you are doing, as well as the adjustments, fixes
and additions that I and many other ada-mode users have put into their
own versions.


Best Regards
John

Re: Ada mode requests (Re: Ada vs C++ vs Java)

[robert_dewar]

In article <36B2381E.70A@gecm.com>,
> I think we need to make sure we know who is going to be
> maintaining ada-mode then. Rolf Ebert did a brilliant job
> of it, but won't be doing it any longer. Latest news on
> this group was that Matt Heaney would be doing it. I
> heard this only a day or two after I had contacted Rolf
> to find out what was happening with ada-mode, and he said
> he was still looking for someone to take over
> maintenance.

Well most certainly ACT will be continuing to maintain our
version, especially as long as there is confusion as to
whether anyone else is even trying to fill this role, and
how much time they may have.

For us, the Ada aware version of EMACS is one of the
critical parts of our technology, since at this stage it
really begins to provide a very attractive integrated
development environment, that many of our big customers
are using.

So we will most certainly continue that development. We are
happy to support any indepedent efforts by contributing our
ideas and code, but just as Cygnus maintains versions of
gdb and gcc independent of EGCS to meet the needs of their
customers, we need to maintain a version that is under our
control and meets our customer needs. What will be nice is
if we an avoid divergence of the code bases (just as Cygnus
does, i.e. by resynchronizing every now and then), and we
should all work towards that.

But one problem here is that editor related matters tend to
generate lots of diverse and strongly held ideas, so it is
not necessarily so easy to guarantee convergence.


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada mode requests (Re: Ada vs C++ vs Java)

[John McCabe]

robert_dewar@my-dejanews.com wrote:

>Well most certainly ACT will be continuing to maintain our
>version, especially as long as there is confusion as to
>whether anyone else is even trying to fill this role, and
>how much time they may have.

That's good to know, but would it be worth changing it's name to
GNAT-Mode to reduce confusion? It would then be up to whoever's using
your software to make sure they have the correct setup in their .emacs
to use GNAT-mode instead of ada-mode.

>For us, the Ada aware version of EMACS is one of the
>critical parts of our technology, since at this stage it
>really begins to provide a very attractive integrated
>development environment, that many of our big customers
>are using.

Having used Emacs with GNAT on SGI IRIX, I would agree with your views
here.

>So we will most certainly continue that development. We are
>happy to support any indepedent efforts by contributing our
>ideas and code, but just as Cygnus maintains versions of
>gdb and gcc independent of EGCS to meet the needs of their
>customers, we need to maintain a version that is under our
>control and meets our customer needs.

From a purely language based point of view, I would expect that your
customers and the Ada community at large probably hold very similar
views on what is needed from ada-mode. At a tool (compiler, debugger
etc) level the requirement is likely to diverge, but really the same
basic requirements regarding launching compilation, linking, debugging
and so on are likely to be required for any compiler, with a superset
of vendor dependant stuff like handling of libaries, cross-referencing
and so on.

It has been mentioned here a couple of times that it would be best to
keep GNAT specific code out of the ada-mode.el code base. All that is
then needed then would be to use elisp's equivalent of
access-to-subprogram types using (funcall...) etc to produce a type of
API that could be used to call either default functions contained
within ada-mode.el, or a particular vendor's implementation of those
functions specific to their product. It would be nice to get more
vendors involved actually so that the API ended up being as useful as
possible. Personally, I can't see why any vendor really needs to
develop their own editing technology with ada-mode around. I'm using
ObjectAda at the moment and, to be honest, their default editor is
completely clueless compared to Emacs with ada-mode.

> What will be nice is if we an avoid divergence of the code bases (just
> as Cygnus does, i.e. by resynchronizing every now and then), and we
> should all work towards that.

I agree that we should avoid divergence of the code bases which is why
I believe that all vendor/tool specific code should be separate from
ada-mode.el. Again, from a language point of view, I don't think there
would be too much difficulty in maintaining this state, or ada-mode
itself.

>But one problem here is that editor related matters tend to
>generate lots of diverse and strongly held ideas, so it is
>not necessarily so easy to guarantee convergence.

Agreed, but generally some compromise, or configurale option can be
put in place that most users will be happy with.



Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Ada mode requests (Re: Ada vs C++ vs Java)

[John McCabe]

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:


>Glad to have a name attached to the maintenance/fixing of ada-mode.
>
>ada-mode 3.0 is a quantum leap from 2.28, but there are still a few niggling
>problems -- e.g., indentation doesn't work right in protected types; in some
>contexts parameter lists are not recognized as parameter lists, etc.

What on earth is ada-mode 3.0? First I've heard of it. Where can I get
it?

TIA

Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Ada mode requests (Re: Ada vs C++ vs Java)

[John McCabe]

Brian Orpin wrote:
> 
> On Mon, 25 Jan 1999 22:44:25 GMT, john@assen.demon.co.uk.nospam (John
> McCabe) wrote:
> >What on earth is ada-mode 3.0? First I've heard of it. Where can I get
> 
> It is on the cs.nyu archive (as is 11p) as 3.1

Can you give me an exact URL? I had a look round last night and couldn't
find anything that seemed right. Is it part of a gzipped file or
something.

> 
> It does of course seem to assume that the only Ada compiler in the world
> is Gnat which is a real pity.

That's not surprising. I've heard something about ACT getting involved
with ada-mode from the emacs ada mode mailing list, but I had hoped they
would separate anything they did from the main code to allow other
compilers to be used with it.

> 
> The texi file will not convert to info nor will it convert to html (as
> the html file in the distribution shows).

Tremendous ! (*NOT*)

John

Re: Ada mode requests (Re: Ada vs C++ vs Java)

[dennison]

In article <36AE35EB.2A7F@gecm.com>,
  John McCabe <john.mccabe@gecm.com> wrote:
> Brian Orpin wrote:
> > It does of course seem to assume that the only Ada compiler in the world
> > is Gnat which is a real pity.
>
> That's not surprising. I've heard something about ACT getting involved
> with ada-mode from the emacs ada mode mailing list, but I had hoped they
> would separate anything they did from the main code to allow other
> compilers to be used with it.

The previous standard seems to have been that compiler-specifc stuff be
placed in separate "ada-compilername.el" files. However, there always were
features in the main adamode which only gnat could support.

I guess a good request for a first activity for the new adamode maintainer
would be to break gnat-specific stuff out into its own file, where it
belongs.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada mode requests (Re: Ada vs C++ vs Java)

[John McCabe]

Brian Orpin wrote:

> >Can you give me an exact URL? I had a look round last night and couldn't
> >find anything that seemed right. Is it part of a gzipped file or
> >something.
> 
> ftp.cs.nyu.edu/pub/gnat/adamode_3.1.tar.gz

Thanks - I've had a look. It seems to be based on an old version of
ada-mode, probably the one that was distributed with emacs 20.2, rather
than the most up-to-date version that was distributed on the mailing
list.

> >That's not surprising. I've heard something about ACT getting involved
> >with ada-mode from the emacs ada mode mailing list, but I had hoped they
> >would separate anything they did from the main code to allow other
> >compilers to be used with it.
 
> Can you supply details about the mailing list although it appears that
> ACT intend to supersede it by using the gnat chat list.

Mmm, there lies a problem - I can't find a way of subscribing to it from
work (Waterlooville) although I subscribed a couple of years ago at
home.  If you want to send messages to the list, I think it's
emacs-ada-mode@inf.enst.fr or something like that. I'll check from home
and email you.

John

Re: Ada mode requests (Re: Ada vs C++ vs Java)

[John McCabe]

Brian Orpin wrote:

> Is this one distributed via the mailing list available for download
> anywhere?

Not that I'm aware of, at least I haven't seen anything later than
Version 2.23 for download. 2.23 was the second to last version for Emacs
19. The latest version distributed on the mailing list was 2.28, which
was later than the version shipped with Emacs 20.3.

John

Re: Ada mode requests (Re: Ada vs C++ vs Java)

[dewar]

In article <36B0FFCC.769@gecm.com>,
  John McCabe <john.mccabe@gecm.com> wrote:
> > Can you supply details about the mailing list although
> > it appears that
> > ACT intend to supersede it by using the gnat chat list.

Not at all, gnat chat is simply an additional forum for
discussing GNAT specific issues. As several people
correctly point out, many of the issues with Ada mode in
EMACS are not GNAT specific, and it seems quite appropriate
to have a more general forum for such discussions.

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada mode requests (Re: Ada vs C++ vs Java)

[Samuel Tardieu]

>>>>> "Robert" == Robert Dewar <dewar@gnat.com> writes:

Robert> Not at all, gnat chat is simply an additional forum for
Robert> discussing GNAT specific issues. As several people correctly
Robert> point out, many of the issues with Ada mode in EMACS are not
Robert> GNAT specific, and it seems quite appropriate to have a more
Robert> general forum for such discussions.

There is a mailing-list indeed (created a long time ago by Rolf)! It
is located at ada-mode@inf.enst.fr. If someone wants to subscribe, she
has to send a mail with subject "subscribe" to
ada-mode-request@inf.enst.fr.

  Sam
-- 
Samuel Tardieu -- sam@ada.eu.org

Re: Ada mode requests (Re: Ada vs C++ vs Java)

[John McCabe]

Samuel Tardieu <sam@ada.eu.org> wrote:


>There is a mailing-list indeed (created a long time ago by Rolf)! It
>is located at ada-mode@inf.enst.fr. If someone wants to subscribe, she
>has to send a mail with subject "subscribe" to
>ada-mode-request@inf.enst.fr.

Samuel,

Have you tried to subscribe recently? The list server appears to have
no knowledge of the ada-mode list.


Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Ada mode requests (Re: Ada vs C++ vs Java)

[dennison]

In article <m3hftjstg6.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:
> I'm going to be taking over maintenance of ada-mode in another month or
> so.  If you have any suggestions for me, let me know.

I may not be using the latest ada-mode, so if this is already in there please
forgive me....

The "other file" feature that automagicly generates stubbed bodies for spec
routines is incredibly useful. But it also copies non-subprogram declarations
over into the body. Those just have be be removed again by a human. I'd like
to see just the subprograms that get expanded copied over (and perhaps
comment blocks).

I'd also like to see the capability expanded somewhat. I always end up having
to add a subprogram or two afterwards. It'd be awfully nice to have a "create
a stub in the other file for the declaration under the cursor" function.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada mode requests (Re: Ada vs C++ vs Java)

[Matthew Heaney]

dennison@telepath.com writes:

> In article <m3hftjstg6.fsf@mheaney.ni.net>,
>   Matthew Heaney <matthew_heaney@acm.org> wrote:
> 
> > I'm going to be taking over maintenance of ada-mode in another month or
> > so.  If you have any suggestions for me, let me know.
> 
> I'd like to see a submode or new mode for editing gnat.adc files. But I
> suppose I might be the only person who would use it.

What's a gnat.adc file?

Re: Ada mode requests (Re: Ada vs C++ vs Java)

[David C. Hoos, Sr.]

Matthew Heaney wrote in message ...
>dennison@telepath.com writes:
>
>> In article <m3hftjstg6.fsf@mheaney.ni.net>,
>>   Matthew Heaney <matthew_heaney@acm.org> wrote:
>>
>> > I'm going to be taking over maintenance of ada-mode in another month or
>> > so.  If you have any suggestions for me, let me know.
>>
>> I'd like to see a submode or new mode for editing gnat.adc files. But I
>> suppose I might be the only person who would use it.
>
>What's a gnat.adc file?
>
Surprisingly, this information is found in the Gnat User's Guide in the
obsurely-named section titled "The gnat.adc file," viz.:

The gnat.adc file
In GNAT a compilation environment is defined by the current directory at the
time that a compile command is given. This current directory is searched for
a file whose name is `gnat.adc'. If this file is present, it is expected to
contain one or more configuration pragmas that will be applied to the
current compilation.

Configuration pragmas may be entered into the `gnat.adc' file either by
running gnatchop on a source file that consists only of configuration
pragmas, or more conveniently by direct editing of the `gnat.adc' file,
which is a standard format source file.

A search of the User's guide for ".adc" will bring to light
several other references to this file.

Re: Ada mode requests (Re: Ada vs C++ vs Java)

[robert_dewar]

In article <78ag05$p23@hobbes.crc.com>,
  "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:

> Surprisingly, this information is found in the Gnat
> User's Guide in the obsurely-named section titled "The
> gnat.adc file," viz.:

Ah, now David is giving away his secret sources of
information as well :-)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada mode requests (Re: Ada vs C++ vs Java)

[dennison]

In article <m37lufb56j.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:
> dennison@telepath.com writes:
>
> > In article <m3hftjstg6.fsf@mheaney.ni.net>,
> >   Matthew Heaney <matthew_heaney@acm.org> wrote:
> >
> > > I'm going to be taking over maintenance of ada-mode in another month or
> > > so.  If you have any suggestions for me, let me know.
> >
> > I'd like to see a submode or new mode for editing gnat.adc files. But I
> > suppose I might be the only person who would use it.
>
> What's a gnat.adc file?

Its the standard file in gnat for handling configuration pragmas. See
http://www.gnat.com/gnat_ug.html#SEC69

It appears my assesment of its frequency of use by folks other than myself was
on the mark...


T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[bill_1]

In article <m3hftjstg6.fsf@mheaney.ni.net>, Matthew says...
 
>
>I'm going to be taking over maintenance of ada-mode in another month or
>so.  If you have any suggestions for me, let me know.
>
>Matt

It would nice to be able to format the whole file with one command also.
(in case one downloads some Ada code written not in the style being used).
or select a region of code, and format that region.

thanks,
Bill

Re: Ada vs C++ vs Java

[Matthew Heaney]

bill_1@nospam.com writes:

> In article <m3hftjstg6.fsf@mheaney.ni.net>, Matthew says...
>  
> >
> >I'm going to be taking over maintenance of ada-mode in another month or
> >so.  If you have any suggestions for me, let me know.
> >
> >Matt
> 
> It would nice to be able to format the whole file with one command also.
> (in case one downloads some Ada code written not in the style being used).
> or select a region of code, and format that region.

That's already implemented: C-x h C-c C-l 

C-c C-l runs the command ada-indent-region, which would appear to do
what you were asking.  (C-x h selects the entire buffer as the
region.)

Re: Ada vs C++ vs Java

[Simon Wright]

Matthew Heaney <matthew_heaney@acm.org> writes:

> C-C C-r to format a record declaration, i.e. go from this:

Well, round here that means adjust-case-region!

> On my list of things to do is teach emacs (ada-mode) how to format a
> record representation clause.

I hope you're going to look at that align-regexp code someone posted
last time this came up, makes rep clauses a doddle. I've only tried by
hand so far ..

> And of course, absolutely no tabs are inserted at any time in the file.
> Tabs do nothing except reek havoc with formatting algorithms, and cause
> very strange-looking print jobs.  Thank goodness, er, I mean, RMS, for
> untabify.

Not sure if the 20.3 ada-mode does that -- isn't it optional
behaviour? I've had a whole lot of CVS diffs recently absolutely
stuffed with leading whitespace changes, what a bore!

> I'm going to be taking over maintenance of ada-mode in another month or
> so.  If you have any suggestions for me, let me know.

Great! (will you be liasing with ACT on this one? they are working in
a similar direction ..)

I'd like some customisability in the layout of created bodies; it does

  procedure Foo (params)
    is
  begin -- Foo
    null;
  end Foo;

and I keep having to change it to read

  procedure Foo (params) is
  begin
    null;
  end Foo;

Re: Ada vs C++ vs Java

[Matthew Heaney]

Simon Wright <simon@pogner.demon.co.uk> writes:

> Matthew Heaney <matthew_heaney@acm.org> writes:
> 
> > C-C C-r to format a record declaration, i.e. go from this:
> 
> Well, round here that means adjust-case-region!

It aligns the colons in the declaration?

 
> Great! (will you be liasing with ACT on this one? they are working in
> a similar direction ..)

I know ACT made some changes to ada-mode; I don't know how or if they
coordinated this with Rolf.
 
> I'd like some customisability in the layout of created bodies; it does
> 
>   procedure Foo (params)
>     is
>   begin -- Foo
>     null;
>   end Foo;
> 
> and I keep having to change it to read
> 
>   procedure Foo (params) is
>   begin
>     null;
>   end Foo;


I ended up tweaking my version of ada-mode source to do exactly as you
indicated.  Let me know if you want my version.

Re: Ada vs C++ vs Java

[Simon Wright]

Matthew Heaney <matthew_heaney@acm.org> writes:

> Simon Wright <simon@pogner.demon.co.uk> writes:
> 
> > Matthew Heaney <matthew_heaney@acm.org> writes:
> > 
> > > C-C C-r to format a record declaration, i.e. go from this:
> > 
> > Well, round here that means adjust-case-region!
> 
> It aligns the colons in the declaration?

No; this is 2.28 with the comment bug fixed, and C-h k C-c C-r says

  C-c C-r runs the command ada-adjust-case-region
     which is an interactive Lisp function in `ada-mode'.
  (ada-adjust-case-region FROM TO)

> > I'd like some customisability in the layout of created bodies; it does
[snip]
> 
> I ended up tweaking my version of ada-mode source to do exactly as you
> indicated.  Let me know if you want my version.

No, that's fine: I don't use it all that often, and when I need to use
it a lot I go and fix ada-mode again :-)

Re: Ada vs C++ vs Java

[Matthew Heaney]

Simon Wright <simon@pogner.demon.co.uk> writes:

> > > > C-C C-r to format a record declaration, i.e. go from this:
> > > 
> > > Well, round here that means adjust-case-region!
> > 
> > It aligns the colons in the declaration?
> 
> No; this is 2.28 with the comment bug fixed, and C-h k C-c C-r says
> 
>   C-c C-r runs the command ada-adjust-case-region
>      which is an interactive Lisp function in `ada-mode'.
>   (ada-adjust-case-region FROM TO)

I don't think I made myself clear.  I re-bound the key sequence C-c C-r to
the command mjh-format-record.  So it's more or less analogous to C-c
C-f.

I never use ada-adjust-case-region.

Re: Ada vs C++ vs Java

[dewar]

In article <m3hftjstg6.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:

> Not quite.  The standards-compliant formatting is done
> on-the-fly, not just before you check the code in.

<<details on using EMACS for this purpose snipped>>

Yes it is of course fine to use any tools you like for
formatting your code. I personally don't like editors that
intefere with what I type, but many people can't live
without them :-)
> I'm going to be taking over maintenance of ada-mode in
> another month or so.  If you have any suggestions for me,
> let me know.

I am not quite sure of the context of this remark, but in
fact ACT supplies versions of EMACS with Ada mode
formatting, and we maintain and enhance this mode. Much
of this work goes far beyond just EMACS. Most
significantly, version 3.11 of GNAT provides automatic
cross-referencing facilities that are fully utilized by
the version of EMACS distributed with 3.11.

We expect to be making official releases of 3.11p starting
tomorrow.

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada Mode wish list

[John McCabe]

Brian Orpin wrote:
> 
> On Mon, 25 Jan 1999 10:27:07 GMT, abuse@borpin.demon.co.uk (Brian Orpin)

> A hook that will execute the format code when using the arrow keys so if
> you are editing a type or object declaration if you use the arrow keys to
> move off the declaration it will reformat it.  I tried this but couldn't
> find the correct key codes.



I think this may be a bit difficult - the main reason being that if you
are half way through creating a declaration the incomplete syntax may
screw things up.

John

Re: Ada Mode wish list

[Simon Wright]

abuse@borpin.demon.co.uk (Brian Orpin) writes:

> A finalisation mode to force a reformat/adjust case at the end of the
> session.

Personally I don't trust ada-mode enough yet for this one! every so
often I have to override its indentation.

> Better handling of multi-line statements so it al least aligns it past
> the ':=' when 'tabbed'

yrch (speaking personally). I guess, if it's an option ..

> Include your align-regexp in the distribution (used all the time thanks!)

The one I have is by Steve Koren (koren@fc.hp.com)

Re: Ada vs C++ vs Java

[Tarjei Tj�stheim Jensen]

Matthew Heaney wrote:
>I agree with Robert Dewar here.  Everyone should follow a standard.  Get
>rid of pretty printers and other automatic code formatters.  Tools like
>that are useless, and only promote programmer laziness and divisiveness.
>
>Emacs is the only tool you need to edit program text.


You mean vi of course :-)

Greetings,

Re: Ada vs C++ vs Java

[Stephen Leake]

Andi Kleen <ak-uu@muc.de> writes:

> In article <m3ww2g4kvs.fsf@mheaney.ni.net>,
> Matthew Heaney <matthew_heaney@acm.org> writes:
> > All it does is turn this:
> 
> > procedure Push 
> >  (Item : in Item_Type;
> >   On : in out Stack_Type);
> 
> > into this:
> 
> > procedure Push
> >   (Item : in     Item_Type;
> >    On   : in out Stack_Type);
> 
> > What's the problem?
> 
> It makes reading cvs diff file (or your favourite version control system's
> equivalent) output hell.
<snip>
> 
> For example in a lot of projects I know it is common to send back patches 
> to the submitters when they contain formatting changes, unless they're
> explicitely marked as formatting patch and only contain them. Separating
> the formatting noise and the useful stuff is just too much work. 

A good diff program can be told to ignore whitespace differences. And
again, emacs comes to the resue with ediff - by far the best
file-difference viewer I've ever seen.

On the other hand, I tend to agree that formatting should be done the
first time, and if a formatting error gets into checked-in source, it
shouldn't be "fixed" unless there is some other reason to edit nearby lines.

-- Stephe

Re: Ada vs C++ vs Java

[robert_dewar]

In article <783nnb$s9c@drn.newsguy.com>,
  bill@nospam.com wrote:
> In article <6Oap2.16170$MW1.4028@news2.giganews.com>,
cbbrowne@news.hex.net
> I prefer
>
> if a
> {
>   ...
> }

ARRGH! Are you trying to turn this into a brackets war.
Now we will get dozens of followups from people who would
rather quit than follow this style, followed by followups
from people who would quit if they could NOT follow this
style :-)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[robert_dewar]

In article <783nnb$s9c@drn.newsguy.com>,
  bill@nospam.com wrote:
> In article <6Oap2.16170$MW1.4028@news2.giganews.com>,
cbbrowne@news.hex.net
> says...
> >
>
> >
> btw, since Ada has no braces, what is the problem? this
> only seems to be C/C++/Java thing, since those uses
> braces.

Brace placement was just an example. I chose it because
the fights that go on over this trivial issue are
well known, notorious in fact you could say!

In Ada, basic layout is dictated by the RM, and most
people follow the RM more or less, less than more in
some cases where it is not quite detailed enough, for
example, all Ada programmers would follow the RM in
lining up the ELSE under the IF. This is not required
by the RM, but suggested by both its syntax rules, which
include layout suggestions, and its examples.

But there are other matters. For a detailed list, see the
unit style.adb in the GNAT sources. For example, some
people write:

   a:=b( j );

where others (including GNAT) would write

   a := b (j);

Arguments about which of the above are preferable are
in my opinion rather dubious, but I see no reason to let
people be sloppy and inconsistent about such minor issues.
Let's all drive on the same side of the road, OK?




-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Peter Hend�n]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]

robert_dewar@my-dejanews.com wrote:
<snip>
>   a:=b( j );

>where others (including GNAT) would write

>   a := b (j);

>Arguments about which of the above are preferable are
>in my opinion rather dubious, but I see no reason to let
>people be sloppy and inconsistent about such minor issues.
>Let's all drive on the same side of the road, OK?

Any shop that makes rules about silly things like this, may
possibly be run by people who understand little of the whys
and wherefores of style. Excessive restrictions on style are
IMHO as detrimental to (group) productivity  and code quality
as no rules.

To compare inconsistency in the writing of expressions as
per your example with driving on the wrong side of the road
is, to say the least, an exaggeration. OTOH, people who
quit because of excessive/bad style rules are also difficult
to take seriously.

Regards,
Peter

--
Peter Hend�n           http://www.algonet.se/~phenden
ICQ: 14672398
Teknisk Dokumentation AB          http://www.tdab.com

Re: Ada vs C++ vs Java

[robert_dewar]

In article <6Oap2.16170$MW1.4028@news2.giganews.com>,
  cbbrowne@hex.net wrote:

<<repeat of the by now familiar suggestion that style
  differences can be handled by a tool snipped>>

> If the organization or the people are so inflexible that
> something like this isn't possible, then something's
> wrong.

Here we go again, I guess cbbrowne did not read to the end
of the thread (to see that this particular suggestion has
been made several times and answered).

In my experience, with no exceptions so far, everyone who
has made this suggestion is talking about something they
think might work, rather than describing actual practices
in a live shop.

For all sorts of reasons, some of which have been recently
discussed, this approach is very hard to get working in
practice. There is no conceptual problem, but the tools
and environments are just not conveniently setup to take
this approach. I am dubious about whether it would work
anyway, because I think the team psychological advantages
of learning to work together in a completely consistent
manner can still be lost.

For example, suppose you have two people working together
at a workstation on a problem looking at sources. If one
is used to looking at them one way, and one another way,
then you won't be able to work together as smoothly as if
you have made the (really rather trivial) effort to all get
used to a completely common style.

But I would be happy to hear from people who have actually
worked in an environment where this approach is used in a
systematic and controlled manner, if there are any. As I
say I have never encountered any. So far, all suggestions
of this type come from shops where in fact practices with
respect to consistency of style at this level are chaotic,
and code ownership, partly stamped by style is endemic.

Remember the goals here

1. To eliminate the notion of code ownership, and encourage
egoless programming where people work as a team, and regard
the product they are working on as a team product rather
than a collectoin of individual projects.

2. To facilitiate cooperative work based on a common
environment and common set of stylistic approaches.

Now some people may actually object to the goals of 1.
Fine, you are on another planet from me when it comes to
software production, but I perfectly understand that
workable software can be produced in a highly
individualistic environment (I used to work that way
myself :-)

But given the goals above, I believe they can only be
achieved by actually reaching a consensus on style issues,
and having everyone FULLY adopt them, both at a technical
and psychological level.

As I say, it would be interesting to here from a group
that systematically used some kind of canonicalization
of sources, with individuals performing style translations
to their own tastes whenever they make changes.

Note the importance of the word systematically here. I am
not talking about isolated cases where Joe is forced to
work on Harry's code, which he finds disgusting because the
brackets are in the wrong place, and first changes all the
bracket positions with a tool, then works on it, leaving
Harry annoyed when he gets back to find that his code has
been destroyed :-)


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Robert I. Eachus]

In article <784lo6$59l$1@nnrp1.dejanews.com> robert_dewar@my-dejanews.com writes:

 > As I say, it would be interesting to here from a group
 > that systematically used some kind of canonicalization
 > of sources, with individuals performing style translations
 > to their own tastes whenever they make changes.

   I do know of one case, but only one.  When we were building the
Ada/SIL compiler at Honeywell (in PL/I on Multics) we used Multics
Emacs and first reference traps on our source library, so that when
you opened a file in Emacs, the indentation, comment columns,
etc. were set to your preferences in a copy that you automagically
checked out.  The check-in tool recanonicalized the file, compiled it,
ran regression tests, etc.

   The system worked pretty well because there was no effort required
to use it, in fact it took a lot of work to bypass it.  (And of
course, those who did try to bypass it got caught quickly, and
eventually removed from the project.)  The only major disadvantage was
that if you needed to have a block comment, the tool required that
each line be a separate comment so the internal formatting didn't
change.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada vs C++ vs Java

[dennison]

In article <784lo6$59l$1@nnrp1.dejanews.com>,
  robert_dewar@my-dejanews.com wrote:

> Remember the goals here
>
> 1. To eliminate the notion of code ownership, and encourage
> egoless programming where people work as a team, and regard
> the product they are working on as a team product rather
> than a collectoin of individual projects.

Perhaps part of the problem centers around this goal. I'm not so sure you
would actually *want* this in all environments. I can see it making sense in
a maintenance mode. But for initial development I think everyone needs a
"home" in the project as much as they need a physical "home" in the plant.
(Don't tell me you do hotelling too?)

I just can't see it working where one person starts to code up a design for a
circular delimited logging queue one day, and another person comes in the
next and codes up a bit more of it, then a third person come in the next day
and codes some more of it. Every person left to their own devices would
probably solve that problem a different way. If all of them tried this at
once, it'd be a mess.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[robert_dewar]

In article <784sgq$bho$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> In article <784lo6$59l$1@nnrp1.dejanews.com>,
>   robert_dewar@my-dejanews.com wrote:
>
> > Remember the goals here
> >
> > 1. To eliminate the notion of code ownership, and
> > encourage egoless programming where people work as a
> > team, and regard the product they are working on as a
> > team product rather than a collectoin of individual
> > projects.
>
> Perhaps part of the problem centers around this goal. I'm
> not so sure you would actually *want* this in all
> environments. I can see it making sense in a maintenance
> mode. But for initial development I think everyone needs
> a "home" in the project as much as they need a physical
> "home" in the plant.

> I just can't see it working where one person starts to
> code up a design for a circular delimited logging queue
> one day, and another person comes in the next and codes
> up a bit more of it, then a third person come in the next
> day and codes some more of it. Every person left to their
> own devices would probably solve that problem a different
> way. If all of them tried this at once, it'd be a mess.

Smooth cooperative working together does not have to mean
that people get in one another's way. Of course the project
gets broken down into tasks, which are suitable for one
person to work on, but the point is that once the code is
checked in, it no longer belongs to the person who wrote it
(for example, in the GNAT project we do NOT permit author's
names in units, because our view is that everything was
written by the team).

That's the point. And if you have not worked in an
environment where this works well, it's a pity, because
it is a very pleasant and very productive way of working.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Martin Dowie]

In article <YkGBP4MNXb2t-pn2-bjzMwxf6POdh@localhost>, Crazy Pete
<peter.garner@toward.com> writes
>Or whatever else.  I always try to encourage each person to "own" 
>individual modules and be responsible for them.  I have found this 
>encourages a sense of pride in their work.   By letting them determine
>their own style they also enjoy what they are doing to a much greater 
>degree and learn faster and become more productive.  Also as you get 
>to know your programmers and their coding styles, it becomes very easy
>to maintain their code because you begin to associate their strengths 
>and weakness with a particular style.

it might be easy for *you*, as you have spent time learning each and
every team members style. what happens when the proverbial bus wipes out
you and your team and there are 'x' disperate styles, and no one is
familiar with then?

> I would not work in a shop such as Dr. Dewar advocates and Dr. Dewar 
>would not work in an environment where I would be happy.  I will say 
>this, however, I DO have a reputation for getting projects in well 
>ahead of deadline and having the results work very well.

good for you - but shouldn't we be trying to encourage standards that
allow those less able than your good self to be able to do a decent job
too? i would have thought that only having to learn one style per
job/project (even if it rubs against what one as an individual would
prefer if give a clean sheet) would help.

>Peace
respect
Martin

Re: Ada vs C++ vs Java

[Peter Hend�n]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 914 bytes --]

robert_dewar@my-dejanews.com wrote:
<snip>
>But the majority preferred mixed-case, so I changed. It
>took a little while to get used to, but now I am used to
>it and it would be hard to go back.
Why should it be hard to go back when...
>That's the real point, you quickly get used to any
>particular style, so fighting furiously to maintain your
>own style is a sign of non-cooperative behavior that is
>unlikely to be the mark of a good team player.

Agreed, but making decisions - whether by vote or
decree - on every detail of style is not the emblem
of a very productive group. Some style differences
simply don't matter enough to offset the negative
effect of enforcing style (ie. those mistakes that
are made because the individual has to change
his style).

Regards,
Peter

--
Peter Hend�n           http://www.algonet.se/~phenden
ICQ: 14672398
Teknisk Dokumentation AB          http://www.tdab.com

Re: Ada vs C++ vs Java

[robert_dewar]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]

In article <782j05$if5$2@zingo.tninet.se>,
  "Peter Hend�n" <phenden@algonet.se> wrote:
> robert_dewar@my-dejanews.com wrote:

> Agreed, but making decisions - whether by vote or
> decree - on every detail of style is not the emblem
> of a very productive group. Some style differences
> simply don't matter enough to offset the negative
> effect of enforcing style (ie. those mistakes that
> are made because the individual has to change
> his style).
>
> Regards,
> Peter


That's more a matter of how this is handled from a
management point of view. Here at ACT, these decisions have
been made very easily, and the resulting uniformity of
style is an important contribution to our very high
productivity. People have a little trouble adjusting,
but the benefits of standardization are considerable.

Have a look at the experience Sweden had in changing to
driving on the right hand side of the road, people expected
far more accidents to occur than actually did. People are
more flexible than you imagine!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Gerhard Menzl]

John Birch wrote:

> Yes you would certainly gain some features that were not present in C.
> Whether it made sense to use a crippled C++ in this way is a much more
> debatable issue. In my experience you should either take it all or
> leave it.

C++ was explicitly designed so that programmers could restrict themselves to whatever
subset they felt were appropriate for their application. Check out "The C++ Programming
Language (3rd. ed.)" and "The Design and Evolution of C++" by Bjarne Stroustrup for a
more detailed explanation. You may not use the full power of C++, but it's certainly not
"crippled".

> If you start telling developers that "We're using C++ but we
> don't use X, Y, Z", you are constraining the number of paradigms that
> they are used to working in. Further you are now creating a
> non-standard language that looks like C++ but isn't.

By your definition, every program that does not use each and every feature of C++ (in
other words: 99.9% of all programs ever written) would be non-standard. Again: it was the
intention of its designer that you could choose your subset from C++ that meets your
needs.

> My statement here rests upon the interpretation of 'subset'. I think a
> perfectly good mathematical definition exists. Using that definition C
> is not a subset of C++. I grant however that any C program that does
> not compile under C++ is probably weak ;-)

Oh please, not another subset discussion! Nobody claims that C is a subset of C++ in a
strict mathematical sense. The point is that the intersection covers well over 99% of C,
so in practical terms, C++ does everything that C does, plus a lot more.

Gerhard Menzl

Re: Ada vs C++ vs Java

[robert_dewar]

In article <36A2F986.97FB0411@sea.ericsson.se>,
  Gerhard Menzl <gerhard.menzl@sea.ericsson.se> wrote:
> John Birch wrote:

> C++ was explicitly designed so that programmers could
> restrict themselves to whatever subset they felt were
> appropriate for their application.

Indeed it is hard to imagine any language NOT being
designed in such a manner. Probably PL/1 was the first
design for which this goal was explicitly articulated.

Note that Tony Hoare's (in)famous address criticizing
Ada, he noted that it was possible to choose a safe
and reliable subset for critical application use. Well
that's the point! For each application you choose the
appropriate subset. Look for example at the GNAT sources,
they are written in what is really quite a small subset
of Ada, adequate to the purpose. Tony seemed to say that
it would be unwise to use the whole of Ada in a critical
application. Well yes of course, who could disagree with
that obvious truism!

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Wolfgang Denk]

johnb@invision.co.uk (John Birch) writes:

>There are many embedded programmers who regard the concept of dynamic
>memory allocation in an embedded system as laughable at best and a
>terminal offence at worst. If you restict C++ in such a way (i.e.

I think you are on very thin ice here.

First, I gues you really were thinking  of  "hard  realtime  require-
ments",  which  is  a somewhat different issue. Many embedded systems
don't have realtime problems (but of course  there  are  many  others
that do).

But even under hard  realtime  you  certainly  will  very  often  use
dynamic  memory allocation - all variables put on the stack are using
a method of  "dynamic  memory  allocation",  aren't  they?  And  even
malloc()  has it's use here and there, especially when you do it only
once during initialization/configuration...

Wolfgang Denk

-- 
Office:  (+49)-89-722-27328, Fax -36703  Wolfgang.Denk@icn.siemens.de
Private: (+49)-89-95720-110, Fax -112                  wd@denx.muc.de
Another dream that failed.  There's nothing sadder.
	-- Kirk, "This side of Paradise", stardate 3417.3

Re: Ada vs C++ vs Java

[robert_dewar]

In article <77mu1h$n6m$1@galaxy.mchh.siemens.de>,
  Wolfgang Denk <wolfgang.denk@icn.siemens.de> wrote:
>
> But even under hard  realtime  you  certainly  will  very
> often  use dynamic  memory allocation - all variables put
> on the stack are using a method of  "dynamic  memory
> allocation"

No, this misunderstands the concern. The concern is with
the use of malloc/free which makes it very hard to verify
that the program will not run out of memory. Stack
allocation is by comparison not a problem at all, assuming
that you avoid recursion, a normal rule in such systems,
you can easily statically analyze maximum stack use.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Michael J. Tobler]

> In article <77mu1h$n6m$1@galaxy.mchh.siemens.de>,
>   Wolfgang Denk <wolfgang.denk@icn.siemens.de> wrote:
> >
> > But even under hard  realtime  you  certainly  will  very
> > often  use dynamic  memory allocation - all variables put
> > on the stack are using a method of  "dynamic  memory
> > allocation"

This is an incorrect statement. The stack is a static area of storage. 
Objects, both native and user-defined are simply defined there and the 
stack pointer is adjusted appropriately. There is no concept of "searching 
for available memory", allocating it, and recording it - the memory 
reserved for the stack is "allocated" at startup. 

-- 
<<<<<<<<<<<<<<<<  Blue Skies  >>>>>>>>>>>>>>>>
< Michael J. Tobler: mtobler@no-spam-ibm.net >
<   **remove "no-spam-" when replying**      >
<     http://www.webbrew.com/toblermj        >
< MJTobler:Instant Messenger;  28038932:ICQ  >
<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>

Real-time dyn allctn (was: Ada vs C++ vs Java)

[Nick Roberts]

Michael J. Tobler wrote in message ...
|
|> In article <77mu1h$n6m$1@galaxy.mchh.siemens.de>,
|>   Wolfgang Denk <wolfgang.denk@icn.siemens.de> wrote:
|> >
|> > But even under hard  realtime  you  certainly  will  very
|> > often  use dynamic  memory allocation - all variables put
|> > on the stack are using a method of  "dynamic  memory
|> > allocation"
|
|This is an incorrect statement. The stack is a static area of storage.
|Objects, both native and user-defined are simply defined there and the
|stack pointer is adjusted appropriately. There is no concept of "searching
|for available memory", allocating it, and recording it - the memory
|reserved for the stack is "allocated" at startup.


Michael's comment is not strictly correct.

In the general case, the pattern of calls that will be made during the
execution of a program - even a 'hard' real-time one - will be unpredictable
(because it depends on unpredictable input values). The maximum possible
stack usage can be calculated. However, this figure will often be vastly
greater than any stack usage that will occur in practise (and thus be
useless). The occurance of recursion which is controlled by an input value
usually makes the aforementioned effect inevitable.

The allocation of data within a stack frame may well be static (but not
necessarily). There is a certain, small, subset of programs which have a
statically predictable pattern of stack allocation, and thus a memory
requirement which is statically determinable with little or no waste. But it
is misleading to describe allocation on the stack as 'static': it is
generally nothing of the kind.

I also feel that the sentiment "don't use dynamic allocation in real-time
programs" is somewhat naive, to put it mildly. I rather suspect that, in
rejecting the use of 'malloc' or 'new', the programmer simply replaces these
forms of dynamic allocation with others (a statically declared array used to
hold dynamically changing data, for example), for no better reason than
superstition.

There is no need to take this attitude for any kind of program.

Taking the example of a program which flies an aeroplane, you will want to
adopt a strategy of absolute robustness ('never crash').

[1] This means that, if the program uses dynamic allocation, either it must
be possible to statically determine that memory will never be insufficient,
or there must be a means of: (a) reliably detecting insufficient memory; and
(b) upon detecting this, returning the software to a state that enables it
to continue safely flying the aeroplane. These requirements are not usually
impractical to achieve.

[2] If the software has interrupt servicing time constraints, the interrupt
servicing routines which have these constraints must either: (a) be able to
use the dynamic allocation in a way which is predictably fast enough; or (b)
not use dynamic allocation. These conditions do not need to be imposed on
any of the other parts of the software (if there are any).

It may well be that typical supplied dynamic allocation facilities are too
crude or unreliable to satisfy the special requirements of a real-time
program. But the answer is not to simply abandon the use of 'malloc' and
replace it with a large number of ad-hoc, hybrid solutions (involving arrays
and indexes). Instead, all that is required is to reprogram the dynamic
allocation facilities to your requirements: you may need a 'malloc_a', a
'malloc_b', and a 'malloc_c', or whatever. The result is likely to be better
source code and better performing software, with no reduction in robustness.

In addition, in view of my comments earlier in this posting about the
dynamic nature of allocation on the stack, it will often be the case that my
comments above about dynamic allocation can be applied to stack allocation
as well (saving a lot of memory space wasted on making sure the stack cannot
crash).

-------------------------------------------
Nick Roberts
-------------------------------------------

Re: Real-time dyn allctn (was: Ada vs C++ vs Java)

[Niklas Holsti]

Nick Roberts wrote:
> 
> In the general case, the pattern of calls that will be made during the
> execution of a program - even a 'hard' real-time one - will be unpredictable
> (because it depends on unpredictable input values). The maximum possible
> stack usage can be calculated. However, this figure will often be vastly
> greater than any stack usage that will occur in practise (and thus be
> useless). The occurance of recursion which is controlled by an input value
> usually makes the aforementioned effect inevitable.

For real-time programs, I've found the maximum stack usage, as
computed by the compiler, to be very useful, and not a severe
overestimate. Of course, these programs do not use recursion --
to me, this restriction is quite natural, since the data in
real-time programs are usually not of recursive types.

Even if you think that the computed stack usage is an overestimate,
what is the alternative? Guess on a "reasonable" value, and hope
it works? Or use a deeper, context-sensitive static analysis to
eliminate infeasible call paths? The latter is OK, if you can do it...

> I also feel that the sentiment "don't use dynamic allocation in real-time
> programs" is somewhat naive, to put it mildly. I rather suspect that, in
> rejecting the use of 'malloc' or 'new', the programmer simply replaces these
> forms of dynamic allocation with others (a statically declared array used to
> hold dynamically changing data, for example), for no better reason than
> superstition.

I'll comment on this below.
 
> There is no need to take this attitude for any kind of program.
> 
> Taking the example of a program which flies an aeroplane, you will want to
> adopt a strategy of absolute robustness ('never crash').
> 
> [1] This means that, if the program uses dynamic allocation, either it must
> be possible to statically determine that memory will never be insufficient,
> or there must be a means of: (a) reliably detecting insufficient memory; and
> (b) upon detecting this, returning the software to a state that enables it
> to continue safely flying the aeroplane. These requirements are not usually
> impractical to achieve.

Yes of course (a) and (b) are essential. And using other forms of
dynamic allocation, such as bounded arrays of preallocated blocks,
is the traditional (and workable) method of achieving these
requirements.

Have you practical experience of achieving these requirements with a
standard or custom-made malloc(), without constraining the distribution
of the number of allocated blocks over block size? It seems to me that
the memory fragmentation problem will not be easy to beat, without
a lot of application-specific analysis.

> [2] If the software has interrupt servicing time constraints, the interrupt
> servicing routines which have these constraints must either: (a) be able to
> use the dynamic allocation in a way which is predictably fast enough; or (b)
> not use dynamic allocation. These conditions do not need to be imposed on
> any of the other parts of the software (if there are any).

Since we are considering real-time programs, we should omit the "other
parts". So your case (a) is the only real case, and it is rather common
opinion that the typical malloc()/free() implementations are
not predictably fast enough (I don't have any first-hand data, though).

> It may well be that typical supplied dynamic allocation facilities are too
> crude or unreliable to satisfy the special requirements of a real-time
> program. But the answer is not to simply abandon the use of 'malloc' and
> replace it with a large number of ad-hoc, hybrid solutions (involving arrays
> and indexes). Instead, all that is required is to reprogram the dynamic
> allocation facilities to your requirements: you may need a 'malloc_a', a
> 'malloc_b', and a 'malloc_c', or whatever. The result is likely to be better
> source code and better performing software, with no reduction in robustness.

Your malloc_a() etc. seem to be exactly the "other forms of dynamic
allocation" that you criticise earlier. Could you explain the
difference? Must malloc_x return a "pointer" (and not an index) to
count as true dynamic allocation?

> In addition, in view of my comments earlier in this posting about the
> dynamic nature of allocation on the stack, it will often be the case that my
> comments above about dynamic allocation can be applied to stack allocation
> as well (saving a lot of memory space wasted on making sure the stack cannot
> crash).

I don't understand your meaning here. Please elaborate. Do you mean
some application-specific method of allocating and deallocating
stack space? That would interfere wit typical compilers...

---
Niklas Holsti
Working at but not speaking for Space Systems Finland Ltd.

Re: Real-time dyn allctn (was: Ada vs C++ vs Java)

[Nick Roberts]

Niklas Holsti wrote in message <36ACC4D6.3E3FEF4@icon.fi>...

[...]
|Even if you think that the computed stack usage is an overestimate,
|what is the alternative? Guess on a "reasonable" value, and hope
|it works? Or use a deeper, context-sensitive static analysis to
|eliminate infeasible call paths? The latter is OK, if you can do it...

Guesswork. Yes really! It is a method I have used, and it works. Of course,
I then test the software: if stack crashes occur too often, increase the
stack space; if too infrequently, decrease it. It is vital to build in
effective monitoring or logging functionality, so that the number of crashes
occurring can be either continuously seen or retrieved at the end of a
run/flight/whatever. Deep analysis is often helpful, if it's available (its
never been to me :-(

[...]
|Yes of course (a) and (b) are essential. And using other forms of
|dynamic allocation, such as bounded arrays of preallocated blocks,
|is the traditional (and workable) method of achieving these
|requirements.
|
|Have you practical experience of achieving these requirements with a
|standard or custom-made malloc(), without constraining the distribution
|of the number of allocated blocks over block size? It seems to me that
|the memory fragmentation problem will not be easy to beat, without
|a lot of application-specific analysis.


Yes I have practical experience of memory management systems of nighmarish
complexity. You are quite right that fragmentation and other problems are
not easily beaten! But they can be beaten, and I have found that it is
surprisingly worthwhile doing so. Having powerful memory management
functionality licked really 'leverages' the power of your embedded software:
suddenly there is so much more you can do. This has been my own experience,
with certain kinds of embedded application which were not terrifically hard
('torpid' perhaps? Can I say that? :-) YMMV.

[...]> These conditions do not need to be imposed on
|> any of the other parts of the software (if there are any).
|
|Since we are considering real-time programs, we should omit the "other
|parts". So your case (a) is the only real case, and it is rather common
|opinion that the typical malloc()/free() implementations are
|not predictably fast enough (I don't have any first-hand data, though).


I don't think so, really. If you consider a typical whole application - e.g.
a jet engine management system - it will still tend to have parts that are
not particularly 'hard'. A jet engine management system, for example, will
probably have a task whose role is to record engine data onto a logger.
Whilst this task will undoubtedly have some tough timing constraints on it,
it is not really a 'hard' task: it could run out of memory (stack or heap)
every now and then, and nobody is going to die; it could drop packets every
so often, and while this may be inconvenient (very annoying perhaps), still
nobody is going to die. Providing that this task's crashing and resetting or
dropping out does not disturb other tasks - and this is the vital proviso -
all is well. Perhaps such a task would never need to use dynamic allocation
(or recursion, or multiple stack frames), but then again it might: it might,
for example, need to be able to encode data in a reverse/forward Polish
order.

[...]
|Your malloc_a() etc. seem to be exactly the "other forms of dynamic
|allocation" that you criticise earlier. Could you explain the
|difference? Must malloc_x return a "pointer" (and not an index) to
|count as true dynamic allocation?

I could have been clearer here. A program might have ten different arrays,
with distinct associated allocation, deallocation, and management code for
each one, just so as to avoid using malloc. All (or most) of this redundant
code might be replaceable by a single malloc_a function, which allocates
memory from a central heap.

But, malloc_a may well be programmed to do garbage collection if necessary
(or other slow operations). You may, therefore, wish to write a malloc_b
which allocates from the heap if it can, but never tries anything slow, so
that time-critical software can call malloc_b (with determinate upper bound
execution time). You may even need a malloc_c which is even quicker, or a
malloc_d which is intermediate. You get the picture (I hope ;-)

I must emphasise: it will, I repeat, _will_ be _very rare_ for the malloc_b
etc variations to be required: the vast majority of time-criticial code can
be, should be, or must be written without dynamic allocation (or recursion).
I never intended to give anyone the impression I thought otherwise.

|> [...] my
|> comments above about dynamic allocation can be applied to stack
allocation
|> as well [...]
|
|I don't understand your meaning here. Please elaborate. Do you mean
|some application-specific method of allocating and deallocating
|stack space? That would interfere wit typical compilers...


I simply mean that, just as a heap crash can be perfectly acceptable for
some parts of the software - provided that it is handled properly - a stack
crash is equally acceptable. Provided such stack crashes fulfil the same
criteria (not causing danger, not upsetting other software, being detected
and handled properly, etc.) this software is then absolved from the ligature
of static analysis and stack oversizing. For the purposes of squeezing
software into tight spaces, it can be a handy trick.

-------------------------------------------
Nick Roberts
-------------------------------------------

Re: Real-time dyn allctn (was: Ada vs C++ vs Java)

[robert_dewar]

In article <78i6m3$505$4@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> Michael's comment is not strictly correct.
>
> In the general case, the pattern of calls that will be
made during the
> execution of a program - even a 'hard' real-time one -
will be unpredictable
> (because it depends on unpredictable input values). The
maximum possible
> stack usage can be calculated. However, this figure will
often be vastly
> greater than any stack usage that will occur in practise
(and thus be
> useless). The occurance of recursion which is controlled
by an input value
> usually makes the aforementioned effect inevitable.

Recursion in a hard real time program? You certainly work
in a different environment from what I am used to. I am
used to recursion being forbidden, as in OCCAM, precisely
to allow static analysis of maximum storage use.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Real-time dyn allctn (was: Ada vs C++ vs Java)

[Nick Roberts]

I suppose it depends on how hard is 'hard', but I think the answer is 'yes'.
For example, a certain well-known brand of laser printers implements a
stack-based PDL, and it uses code, inside its ROM, which is effectively
recursive, to interpret this PDL. Recent models of these (and other)
printers also use a highly sophisticated system of dynamic memory allocation
and management (including garbage collection and data compression).

Another example: a certain military mapping program uses an reverse Polish
coding to encode the map data. The code used to unravel and display this
data uses recursive-descent. Of course, we could have used loops, but it
would have been a minor nightmare to do so. The program worked just fine.

Plainly, the use of recursive calls will be impossible (or at least
foolhardy) for many applications, and for many others it will simply be
unnecessary. But why forbid it? There will also be some applications where
recursion is a pain to avoid, and many where such avoidance is not really
necessary.

-------------------------------------------
Nick Roberts
-------------------------------------------

robert_dewar@my-dejanews.com wrote in message
<78im07$86a$1@nnrp1.dejanews.com>...
|Recursion in a hard real time program? You certainly work
|in a different environment from what I am used to. I am
|used to recursion being forbidden, as in OCCAM, precisely
|to allow static analysis of maximum storage use.

Re: Real-time dyn allctn (was: Ada vs C++ vs Java)

[dmitrik]

In article <78lv2n$dpl$2@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:

> I suppose it depends on how hard is 'hard', but I think the answer is 'yes'.
> For example, a certain well-known brand of laser printers implements a
> stack-based PDL, and it uses code, inside its ROM, which is effectively
> recursive, to interpret this PDL. Recent models of these (and other)
> printers also use a highly sophisticated system of dynamic memory allocation
> and management (including garbage collection and data compression).

Definitely not hard enough. How about "Stack Overflow", "Out of memory" or
"Page too Complex" printed nicely on top of otherwise blank page coming ouf of
certain well-known brand of laser printer? Or a suggestion to install more
memory in User Manual? They've got a big reset button on the front panel after
all.

> Another example: a certain military mapping program uses an reverse Polish
> coding to encode the map data. The code used to unravel and display this
> data uses recursive-descent. Of course, we could have used loops, but it
> would have been a minor nightmare to do so. The program worked just fine.

Was it really *hard real-time* app?
As I understand in situations like this you've got only 3 choices:
a) Stick another (64) megabytes and hope it won't blow up.
b) Handle stack overflow "gracefully" with a message "Unable to process all
your data. Some enemy missiles will not be intercepted".
c) Statically *prove* your recursion is limited and enough stack space is
available under any circumstances.

What choice did you make BTW?

Dmitri

>
> Plainly, the use of recursive calls will be impossible (or at least
> foolhardy) for many applications, and for many others it will simply be
> unnecessary. But why forbid it? There will also be some applications where
> recursion is a pain to avoid, and many where such avoidance is not really
> necessary.
>
> -------------------------------------------
> Nick Roberts
> -------------------------------------------
>
> robert_dewar@my-dejanews.com wrote in message
> <78im07$86a$1@nnrp1.dejanews.com>...
> |Recursion in a hard real time program? You certainly work
> |in a different environment from what I am used to. I am
> |used to recursion being forbidden, as in OCCAM, precisely
> |to allow static analysis of maximum storage use.
>
>

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Real-time dyn allctn (was: Ada vs C++ vs Java)

[Nick Roberts]

dmitrik@my-dejanews.com wrote in message
<78on0o$9rb$1@nnrp1.dejanews.com>...
[printer example]
|Definitely not hard enough. How about "Stack Overflow", "Out of memory" or
|"Page too Complex" printed nicely on top of otherwise blank page coming ouf
of
|certain well-known brand of laser printer? Or a suggestion to install more
|memory in User Manual? They've got a big reset button on the front panel
after
|all.


You know the one! Yes, it did indeed print a page with "Out of Memory" at
the top. It _then_ proceeded to print what it could on the _next_ page or
even _several_ pages (typically all garbled rubbish). Calculated to annoy
the poor user. This is why subsequent models had: (a) more memory in the
base configuration to start with; (b) serious compression algorithms. But
what other choice did we have?

[mapping program example]
|Was it really *hard real-time* app?
|As I understand in situations like this you've got only 3 choices:
|a) Stick another (64) megabytes and hope it won't blow up.

We were working on diabolically underpowered machines. Megabytes? We were
glad to get a few more KB.

|b) Handle stack overflow "gracefully" with a message "Unable to process all
|your data. Some enemy missiles will not be intercepted".

Read it and weep (well, I do). This is _exactly_ what it had to do.

|c) Statically *prove* your recursion is limited and enough stack space is
|available under any circumstances.


The map data was fixed, so we could run it through and simply measure
maximum stack depth. But then guess what? They changed the map data. But it
still worked.

|What choice did you make BTW?

In the end, we never had to: the entire project was cancelled (just as it
got to the 1Bn pound mark).


-------------------------------------------
Nick Roberts
-------------------------------------------

PS: none of this really happened, and I was never there. Okay?

Re: Real-time dyn allctn (was: Ada vs C++ vs Java)

[John Birch]

On Mon, 25 Jan 1999 01:13:44 -0000, "Nick Roberts"
<Nick.Roberts@dial.pipex.com> wrote:

>Michael J. Tobler wrote in message ...

>|> In article <77mu1h$n6m$1@galaxy.mchh.siemens.de>,
>|>   Wolfgang Denk <wolfgang.denk@icn.siemens.de> wrote:

>|> > But even under hard  realtime  you  certainly  will  very
>|> > often  use dynamic  memory allocation - all variables put
>|> > on the stack are using a method of  "dynamic  memory
>|> > allocation"

>|This is an incorrect statement. The stack is a static area of storage.
>|Objects, both native and user-defined are simply defined there and the
>|stack pointer is adjusted appropriately. There is no concept of "searching
>|for available memory", allocating it, and recording it - the memory
>|reserved for the stack is "allocated" at startup.


>Michael's comment is not strictly correct.

>In the general case, the pattern of calls that will be made during the
>execution of a program - even a 'hard' real-time one - will be unpredictable
>(because it depends on unpredictable input values).

This is simply wrong!

You argue that unpredictable input values cause unpredictable patterns
of function calls. This is at best an exaggeration of the typical
case. For a well structured hard real-time program, no individual
input value should be unexpected (i.e. not catered for in the code). 

Your argument assumes that the input values are coupled to the
algorithms of the system in a manner that allows unpredictable
behaviour! If you use input values to determine program execution flow
then I would grant you that unpredicatble behaviour might result, e.g.
take input value, multiply by random number and put result in program
counter will certainly get interesting in a hurry! A well designed
hard realtime system would never be designed in such a manner :-)

For example in a process control system, input might be aquired at
known rates under interrupt. A background (i.e. non interrupt) cycle
would process the current set of inputs and update output values.
These might also be moved to the output hardware under interrupt.
There is nowhere a possibility of an input value changing the course
of execution of the background cycle (except through well understood
paths to cope for error conditions). Consequently in such a design the
stack utilisation can be well determined. The coupling here is by
means of global variables (global between input and processing, and
between processing and output)

Many other valid design strategies are also possible. For performance
reasons it may be desirable to put more processing into the interrupt
mechanism and to retain the background 'loop' for detection of errors
and housekeeping only. 

> The maximum possible stack usage can be calculated. However, this figure will often be vastly
>greater than any stack usage that will occur in practise (and thus be
>useless). 

Certainly the maximum value calculated will be high, but this value
can be adjusted into a more reasonable range by cursory examination of
the program. Firstly all interrupt routines and all routines that can
be called as a result of an interrupt must be accumulated (in terms of
stack requirement). It is assumed here that an interrupt cannot
interrupt itself (if this is the case then the sums get harder ;-)). 

Having done this the background loop can be examined, looking at the
call tree it is perfectly possible to deduce which routines can never
be called from inside others. This allows the maximum initial stack
requirement to be considerably reduced. This stage is often automated
by the toolset provided by the compiler vendor.

>The occurance of recursion which is controlled by an input value
>usually makes the aforementioned effect inevitable.

So don't use recursion. If you believe recursion is a necessity for
hard real-time programming - please tell me which hard real-time
project you have used it on - I can then avoid it. ;-) If you do have
to use recursion then it must be bounded - if it is not then you have
a non-deterministic system. By definition if the system may behave
non-deterministically, then it cannot solve a hard real-time problem
(a deadline can never be missed!)

>The allocation of data within a stack frame may well be static (but not
>necessarily). There is a certain, small, subset of programs which have a
>statically predictable pattern of stack allocation, and thus a memory
>requirement which is statically determinable with little or no waste. But it
>is misleading to describe allocation on the stack as 'static': it is
>generally nothing of the kind.

'Generally' here meaning in programs written without careful
consideration of the issues involved in memory management for resource
limited systems!

>I also feel that the sentiment "don't use dynamic allocation in real-time
>programs" is somewhat naive, to put it mildly. I rather suspect that, in
>rejecting the use of 'malloc' or 'new', the programmer simply replaces these
>forms of dynamic allocation with others (a statically declared array used to
>hold dynamically changing data, for example), for no better reason than
>superstition.

I rather suspect you have never done any real-time coding. If you have
then you should go back to school. Whilst I would not completely rule
out the use of dynamic memory allocation (i.e. the use of malloc and
free) I would state categorically that there are very few hard
real-time systems IMHO where its use is a necessity. Since by its very
nature it makes deterministic behaviour more difficult to implement,
it is better avoided.

>There is no need to take this attitude for any kind of program.

>Taking the example of a program which flies an aeroplane, you will want to
>adopt a strategy of absolute robustness ('never crash').

>[1] This means that, if the program uses dynamic allocation, either it must
>be possible to statically determine that memory will never be insufficient,

A near tautology.

>or there must be a means of: (a) reliably detecting insufficient memory; and
>(b) upon detecting this, returning the software to a state that enables it
>to continue safely flying the aeroplane. These requirements are not usually
>impractical to achieve.

Oops - what's this? I know, it's the equivalent of the Microsoft BSOD.
"CTRL ALT DELETE To regain control of aircraft Captain!"
GET REAL!!!!

You are advocating designing a piece of software that has known flaws.
A good embedded software designer would regard stack (or heap) bounds
checking, (or a watchdog timer) as a belt and braces safety measure -
not as an integral part of the design.

BTW - if the input condition causes the program to CRASH, ie fail to
perform to specification - how does restarting the program resolve
that problem if the input condition continues unchanged. I.e. If the
pilot puts his aircraft into an inverted flat sipn, and the program
runs out of heap trying to solve the problem, how does "
>returning the software to a state that enables it to continue safely flying the aeroplane<
stop the same thing happening again?

>[2] If the software has interrupt servicing time constraints, the interrupt
>servicing routines which have these constraints must either: (a) be able to
>use the dynamic allocation in a way which is predictably fast enough; or (b)
>not use dynamic allocation. These conditions do not need to be imposed on
>any of the other parts of the software (if there are any).

Why oh why would an interrupt need to dynamically allocate memory?????
This is rather like saying, I want to catch a bus home but, rather
than work out how long it takes me to walk to the bus stop and how
often the bus comes, I'll just get myself a set of Bionic legs so that
I'll always be able to catch it! It is this kind of crap that causes
real-time software problems in the first place.

Whilst I would grant that removing dynamic memory allocation from
interrupts is a start, your follow up about it not being necessary for
the rest of the system is only true if the rest of the system has no
role in a deterministic process required by the system. This would
possibly be true if all the real work was done under interrupt and
none in background. While this is a workable solution for small
problems, the moment there is a moderate degree of interaction between
values calculated or aquired by different interrupt routines, then it
becomes extremely difficult, if not impossible, to maintain any
synchronous behaviour that may be required by the problem domain.

>It may well be that typical supplied dynamic allocation facilities are too
>crude or unreliable to satisfy the special requirements of a real-time
>program. But the answer is not to simply abandon the use of 'malloc' and
>replace it with a large number of ad-hoc, hybrid solutions (involving arrays
>and indexes).

Yes it is!
BTW - have you ever used a union?

Oh and while I'm at it, the use of malloc requires the use of pointer
casts and generally pointer arithmetic. Are these sound coding
practices when you are working in an environment where the background
radiation level can induce bit failures at rates of up to 1 million
times those on the average desktop?

> Instead, all that is required is to reprogram the dynamic
>allocation facilities to your requirements: you may need a 'malloc_a', a
>'malloc_b', and a 'malloc_c', or whatever. The result is likely to be better
>source code and better performing software, with no reduction in robustness.

Oh goody yet more potentially bug ridden code to add into our resource
limited system to support an unnecessary convenience.

>In addition, in view of my comments earlier in this posting about the
>dynamic nature of allocation on the stack, it will often be the case that my
>comments above about dynamic allocation can be applied to stack allocation
>as well (saving a lot of memory space wasted on making sure the stack cannot
>crash).

I think you missed the entire point. You don't code around problems.
You design in such a way as to never encounter them. This is exactly
what the contention is. By not using dynamic memory allocation and
having a statically allocated program - you simply never encounter the
following problems (and therefore never need any code for them!)

Heap overflow.
Heap fragmentation.
Stack Overflow (assuming you get the sums right - but at least you
have tried, which is more than can be said for the never, never
approach you are advocating).


regards John B.

Re: Real-time dyn allctn (was: Ada vs C++ vs Java)

[Nick Roberts]

John Birch wrote in message <36acb008.31947998@news.demon.co.uk>...
|On Mon, 25 Jan 1999 01:13:44 -0000, "Nick Roberts"
|<Nick.Roberts@dial.pipex.com> wrote:
|
|>Michael J. Tobler wrote in message ...
|
|>|> In article <77mu1h$n6m$1@galaxy.mchh.siemens.de>,
|>|>   Wolfgang Denk <wolfgang.denk@icn.siemens.de> wrote:
|
|>|> > But even under hard  realtime  you  certainly  will  very
|>|> > often  use dynamic  memory allocation - all variables put
|>|> > on the stack are using a method of  "dynamic  memory
|>|> > allocation"
|
|>|This is an incorrect statement. The stack is a static area of storage.
|>|Objects, both native and user-defined are simply defined there and the
|>|stack pointer is adjusted appropriately. There is no concept of
"searching
|>|for available memory", allocating it, and recording it - the memory
|>|reserved for the stack is "allocated" at startup.
|
|
|>Michael's comment is not strictly correct.
|
|>In the general case, the pattern of calls that will be made during the
|>execution of a program - even a 'hard' real-time one - will be
unpredictable
|>(because it depends on unpredictable input values).
|
|This is simply wrong!
|
|You argue that unpredictable input values cause unpredictable patterns
|of function calls. This is at best an exaggeration of the typical
|case.

No it really isn't an exaggeration; it's not always the case, of course, but
it really is the typical case. Consider the following (entirely concocted)
code:


int elev_rqd;

init()
{
  ...
  robin = 0;
  ...
};

handle_clock_tick()
{
  ...
  compensate_elevators();
  ...
};

...

compensate_elevators()
{
  int elev_dif = elev_rqd - read_port(ELEV_PSN_PORT);
  int elev_act;
  if (INSIDE(elev_dif,ELEV_DIF_THRESH,-ELEV_DIF_THRESH)) {
    elev_act = compute_elevator_actuator_power(elev_dif);
    CONSTRN(elev_act,ELEV_ACT_MIN,ELEV_ACT_MAX);
  } else {
    elev_act = 0;
  };
  write_port(ELEV_ACT_PORT,elev_act);
};


This is only the simplest example, but consider the pattern of calling of
the function compute_elevator_actuator_power (relative to the calling of all
the other functions). In other words, when will it get called, compared to
when the others get called? Will this pattern of calling be the same for
each flight of the aeroplane? It will be different every time.

|For a well structured hard real-time program, no individual
|input value should be unexpected

It is a fundamental quality of input values that they are unpredictable. If
the value of a certain input variable was predictable, you could use a
constant, or a lookup table, or whatever, and not input it at all! Think
about this.

|(i.e. not catered for in the code).

There is a difference between a value being unpredictable, and it not being
catered for in the code.

|Your argument assumes that the input values are coupled to the
|algorithms of the system in a manner that allows unpredictable
|behaviour!

No, I am not saying this. I use very precise language very precisely.
Perhaps you should go back, and read what I say very carefully.

|If you use input values to determine program execution flow
|then I would grant you that unpredicatble behaviour might result, e.g.
|take input value, multiply by random number and put result in program
|counter will certainly get interesting in a hurry!

I think your example demonstrates that you don't really understand the
nature of Von-Neumann architecture machines. Every time you execute a
conditional jump (as a result of an 'if', or other conditional construct)
whose condition depends on an input value you are effectively loading the
program counter with a value that depends on an input value. In fact, some
compilers will translate some 'switch/case' statements into a table lookup
straight into the PC.

|A well designed
|hard realtime system would never be designed in such a manner :-)


Smiley noted, but this is not true, John! I don't like saying it, but I
really am a veteran at this sort of thing, and I know what I'm talking
about.

|For example in a process control system, input might be aquired at
|known rates under interrupt. A background (i.e. non interrupt) cycle
|would process the current set of inputs and update output values.
|These might also be moved to the output hardware under interrupt.
|There is nowhere a possibility of an input value changing the course
|of execution of the background cycle (except through well understood
|paths to cope for error conditions).

I think (I hope ;-) my example above shows you that the course of execution
can be - and indeed generally is - changed by input values.

|Consequently in such a design the
|stack utilisation can be well determined. The coupling here is by
|means of global variables (global between input and processing, and
|between processing and output)
|
|Many other valid design strategies are also possible. For performance
|reasons it may be desirable to put more processing into the interrupt
|mechanism and to retain the background 'loop' for detection of errors
|and housekeeping only.


I think, therefore, the rest of your argument is predicated on false
premises.

|> The maximum possible stack usage can be calculated. However, this figure
will often be vastly
|>greater than any stack usage that will occur in practise (and thus be
|>useless).
|
|Certainly the maximum value calculated will be high, but this value
|can be adjusted into a more reasonable range by cursory examination of
|the program. Firstly all interrupt routines and all routines that can
|be called as a result of an interrupt must be accumulated (in terms of
|stack requirement). It is assumed here that an interrupt cannot
|interrupt itself (if this is the case then the sums get harder ;-)).
|
|Having done this the background loop can be examined, looking at the
|call tree it is perfectly possible to deduce which routines can never
|be called from inside others. This allows the maximum initial stack
|requirement to be considerably reduced. This stage is often automated
|by the toolset provided by the compiler vendor.


Cursory examination of the program? A small program maybe! Yes, a toolset
(or appropriate compiler) can be used, but there are typically certain, more
complicated, constructs that it cannot apply its deductive reasoning to. The
result is, you have to avoid these constructs; in practice, doing this is
always inconvenient but rarely impossible. My argument is that it is not
always necessary to ensure a stack 'crash' cannot happen - typically by
ensuring the amount of memory reserved for the stack will always be
sufficient - because sometimes it is perfectly workable to allow such a
crash to happen, providing you take the necessary precautions.

|>The occurance of recursion which is controlled by an input value
|>usually makes the aforementioned effect inevitable.
|
|So don't use recursion. If you believe recursion is a necessity for
|hard real-time programming - please tell me which hard real-time
|project you have used it on - I can then avoid it. ;-)

No I don't believe that recursion is a necessity for hard real-time
programming, and I never said so. I simply believe that it is not always
necessary to avoid using recursion, for two reasons: (a) in your own words
...

|If you do have
|to use recursion then it must be bounded - if it is not then you have
|a non-deterministic system. By definition if the system may behave
|non-deterministically, then it cannot solve a hard real-time problem
|(a deadline can never be missed!)

... and (b) there are almost always, in real real-time projects, parts of
the program which can fail - providing the failure can be caught and
properly recovered - without going beyond the bounds of reliability or
robustness required. For these parts of the program, it is acceptable to use
code which may run out memory - be it stack memory or heap memory (or any
other kind of memory) - provided that you can ensure that if it ever does
run out of memory, the ensuing 'crash' (or whatever perjorative term you
fancy using) and recovery does not jeopardise the minimum level of reliable
execution required of the software.

Of course, this does place constraints on the 'crashable' parts of the
program: (1) you must be sure that the crashes won't happen at a time or in
a circumstance which will jeopardise safety (or otherwise be unacceptable);
(2) you must be sure that the memory overflow will always be detected; (3)
you must be sure that the overflow will never interfere with the memory or
operation of the rest of the program; (4) you must be sure that recovery
will always be possible and correctly executed; (5) you must be sure that
the recovery process will never interfere with the proper operation of the
rest of the software; (6) you must be sure that the crash/recovery process
will never causes the gradual erosion of memory or other resources; and so
on.

But all of these constraints can be met, and it is not usually impractical
to do so.

|>The allocation of data within a stack frame may well be static (but not
|>necessarily). There is a certain, small, subset of programs which have a
|>statically predictable pattern of stack allocation, and thus a memory
|>requirement which is statically determinable with little or no waste. But
it
|>is misleading to describe allocation on the stack as 'static': it is
|>generally nothing of the kind.
|
|'Generally' here meaning in programs written without careful
|consideration of the issues involved in memory management for resource
|limited systems!


No, not at all. Again, this is not what I said, and not what I meant.

|>I also feel that the sentiment "don't use dynamic allocation in real-time
|>programs" is somewhat naive, to put it mildly. I rather suspect that, in
|>rejecting the use of 'malloc' or 'new', the programmer simply replaces
these
|>forms of dynamic allocation with others (a statically declared array used
to
|>hold dynamically changing data, for example), for no better reason than
|>superstition.

|
|I rather suspect you have never done any real-time coding. If you have
|then you should go back to school.

I simply repeat that I am a veteran of these things.

|Whilst I would not completely rule
|out the use of dynamic memory allocation (i.e. the use of malloc and
|free)

Hooray! ;-)

|I would state categorically that there are very few hard
|real-time systems IMHO where its use is a necessity.

I don't disagree with this, and I didn't in my original post! I'm not
arguing that its use is ever necessary, but simply that its non-use is not
always necessary.

|Since by its very
|nature it makes deterministic behaviour more difficult to implement,
|it is better avoided.


The nature of 'ordinary' dynamic allocation facilities often makes their use
best avoided. But I am talking about dynamic allocation facilities specially
programmed, if necessary, to have the required characteristics.

|>There is no need to take this attitude for any kind of program.
|
|>Taking the example of a program which flies an aeroplane, you will want to
|>adopt a strategy of absolute robustness ('never crash').
|
|>[1] This means that, if the program uses dynamic allocation, either it
must
|>be possible to statically determine that memory will never be
insufficient,
|
|A near tautology.


Not at all! There are some programs (only a few) which use dynamic
allocation which can be analysed and proved to never require more than a
certain amount of memory at any one point in time. For such a program, if
you supply at least that amount of memory, you have a program which uses
dynamic allocation but where it is possible to statically determine that
memory will never be insufficient. No tautology!

|>or there must be a means of: (a) reliably detecting insufficient memory;
and
|>(b) upon detecting this, returning the software to a state that enables it
|>to continue safely flying the aeroplane. These requirements are not
usually
|>impractical to achieve.
|
|Oops - what's this? I know, it's the equivalent of the Microsoft BSOD.
|"CTRL ALT DELETE To regain control of aircraft Captain!"
|GET REAL!!!!


Joke acknowledged, but I am not advocating the dreaded blue screen, nor the
attitude that goes with it (of 'throw-away' software as I think a recent
poster put it). Some means - be it a language's exception mechanism or
something else - must be used to catch the memory overflow condition and
then reset variables to a stable state (including the PC, if you want to
look at it that way) so that execution can continue 'gracefully'.

|You are advocating designing a piece of software that has known flaws.

Perjorative language doth not an argument make. You can call it a 'flaw' if
you like, but it is only a convention to consider it a flaw that a piece of
software may run out of memory from time to time. In reality, this is only a
flaw if it happens without the programmer's intent or consent; if it happens
but is planned for and expected, it is not a flaw, John.

|A good embedded software designer would regard stack (or heap) bounds
|checking, (or a watchdog timer) as a belt and braces safety measure -
|not as an integral part of the design.

Only because that is the orthodoxy they have been taught.

|BTW - if the input condition causes the program to CRASH, ie fail to
|perform to specification - how does restarting the program resolve
|that problem if the input condition continues unchanged. I.e. If the
|pilot puts his aircraft into an inverted flat sipn, and the program
|runs out of heap trying to solve the problem, how does "
|>returning the software to a state that enables it to continue safely
flying the aeroplane<
|stop the same thing happening again?


I am pointedly not advocating that vital flight systems are programmed so
that they could run out of memory at a critical time! Mary, God, and all the
saints forbid. But, to continue with the example of an aeroplane, there will
be lots of subsystems which are not at all crititcal to flight safety. An
example of this might be a task whose sole function was to monitor the fuel
levels in the various fuel tanks, and (in 'auto' mode) automatically pump
fuel from one tank to another so as to retain optimum 'flight profile'. If
this task were to crash once in a while, and have to reset itself to
recover, this would never jeopardise anyone's safety at any time.

|>[2] If the software has interrupt servicing time constraints, the
interrupt
|>servicing routines which have these constraints must either: (a) be able
to
|>use the dynamic allocation in a way which is predictably fast enough; or
(b)
|>not use dynamic allocation. These conditions do not need to be imposed on
|>any of the other parts of the software (if there are any).
|
|Why oh why would an interrupt need to dynamically allocate memory?????

I did not suggest that interrupts are likely to need to to dynamically
allocate memory. Yet again, I did not write this and I did not mean it. I am
simply saying that, provided the dynamic allocation can be done in a way
which is predictably fast enough, it can be safely done. Are you disagreeing
with this statement? If so, say how, precisely.

|This is rather like saying, I want to catch a bus home but, rather
|than work out how long it takes me to walk to the bus stop and how
|often the bus comes, I'll just get myself a set of Bionic legs so that
|I'll always be able to catch it!

Bionic legs are not required: only a special allocation routine that will
not attempt something too slow, such as garbage collection, before
returning.

|It is this kind of crap that causes
|real-time software problems in the first place.

I would suggest that it is a poor understanding of the true situation which
causes real-time software problems.

|Whilst I would grant that removing dynamic memory allocation from
|interrupts is a start, your follow up about it not being necessary for
|the rest of the system is only true if the rest of the system has no
|role in a deterministic process required by the system. This would
|possibly be true if all the real work was done under interrupt and
|none in background. While this is a workable solution for small
|problems, the moment there is a moderate degree of interaction between
|values calculated or aquired by different interrupt routines, then it
|becomes extremely difficult, if not impossible, to maintain any
|synchronous behaviour that may be required by the problem domain.

I'm getting the impression that you're one of those programmers who thinks
that synchronisation between tasks is a matter of 'suck it and see', rather
than using the proper synchronisation mechanisms in the proper places. A
good embedded software designer will only ever rely upon these mechanisms to
maintain the necessary synchronous behaviour between tasks, and not upon
hoping that some tasks will be able to 'keep up'.


|>It may well be that typical supplied dynamic allocation facilities are too
|>crude or unreliable to satisfy the special requirements of a real-time
|>program. But the answer is not to simply abandon the use of 'malloc' and
|>replace it with a large number of ad-hoc, hybrid solutions (involving
arrays
|>and indexes).
|
|Yes it is!

No it is not!

|BTW - have you ever used a union?

What have unions got to do with it?

|Oh and while I'm at it, the use of malloc requires the use of pointer
|casts and generally pointer arithmetic. Are these sound coding
|practices when you are working in an environment where the background
|radiation level can induce bit failures at rates of up to 1 million
|times those on the average desktop?


Wow, what an egregiously bogus argument! John, the processor uses pointers
(e.g. the program counter) whether you like it or not. Take a look at the
machine code produced by your compiler. It is full of pointers! Memory for
hard applications has had sophisticated ECC schemes for years: even if it
fails (to correct a bad bit) the failure is caught (it tugs on the NMI) and
then the software - and this is the bit you need to read, John - must then
be able to restart itself 'gracefully' (either that or BSOD). I take it you
don't design yet your software to do this.

|> Instead, all that is required is to reprogram the dynamic
|>allocation facilities to your requirements: you may need a 'malloc_a', a
|>'malloc_b', and a 'malloc_c', or whatever. The result is likely to be
better
|>source code and better performing software, with no reduction in
robustness.
|
|Oh goody yet more potentially bug ridden code to add into our resource
|limited system to support an unnecessary convenience.

I'm not advocating anybody introduce bug-ridden code, and I'm not advocating
anybody introduce code which hogs too much resource. Of course there will be
applications which cannot support the overhead or the complexity of dynamic
allocation. But I bet you there are many applications for which this is not
necessarily true. Using dynamic allocation can improve code (machine code
speed and size, and source code size and complexity) by the classic
technique of 'factoring out' allocation code: instead of having what is
effectively allocation code (for arrays) in several places in your program,
you have it in only one place (for the heap) instead.

|>In addition, in view of my comments earlier in this posting about the
|>dynamic nature of allocation on the stack, it will often be the case that
my
|>comments above about dynamic allocation can be applied to stack allocation
|>as well (saving a lot of memory space wasted on making sure the stack
cannot
|>crash).
|
|I think you missed the entire point. You don't code around problems.
|You design in such a way as to never encounter them. This is exactly
|what the contention is. By not using dynamic memory allocation and
|having a statically allocated program - you simply never encounter the
|following problems (and therefore never need any code for them!)
|
|Heap overflow.
|Heap fragmentation.
|Stack Overflow (assuming you get the sums right - but at least you
|have tried, which is more than can be said for the never, never
|approach you are advocating).


But John, I repeat, these are only problems if they are not properly
anticipated and dealt with. You must avoid the pitfall of being blinded by
the perjorative terms you have been taught for things. I am saying that,
with care, all of these 'problems' can be anticipated and dealt with
perfectly satisfactorily. There is nothing 'never never' about this
approach: it is rock solid! On the other hand your attitude of 'at least I
have tried' is nearer to a 'never never' approach.

|
|regards John B.
|

My best wishes to you, John. I entreat you to objectively rethink your
position on this subject, and I wish you the best of success in your
real-time projects.

-------------------------------------------
Nick Roberts
-------------------------------------------

Re: Real-time dyn allctn (was: Ada vs C++ vs Java)

[John Birch]

On Tue, 26 Jan 1999 21:58:25 -0000, "Nick Roberts" 

you (Nick.Roberts) originally wrote:
>>In the general case, the pattern of calls that will be made during the
>>execution of a program - even a 'hard' real-time one - will be
>>unpredictable (because it depends on unpredictable input values).

I wrote
>|This is simply wrong!
>|You argue that unpredictable input values cause unpredictable patterns
>|of function calls. This is at best an exaggeration of the typical case.

>No it really isn't an exaggeration; it's not always the case, of course, but
>it really is the typical case. Consider the following (entirely concocted)
>code:

>int elev_rqd;

>init()
>{
>  ...
>  robin = 0;
>  ...
>};

>handle_clock_tick()
>{
>  ...
>  compensate_elevators();
>  ...
>};

>...
>
>compensate_elevators()
>{
>  int elev_dif = elev_rqd - read_port(ELEV_PSN_PORT);
>  int elev_act;
>  if (INSIDE(elev_dif,ELEV_DIF_THRESH,-ELEV_DIF_THRESH)) {
>    elev_act = compute_elevator_actuator_power(elev_dif);
>    CONSTRN(elev_act,ELEV_ACT_MIN,ELEV_ACT_MAX);
>  } else {
>    elev_act = 0;
>  };
>  write_port(ELEV_ACT_PORT,elev_act);
>};

>This is only the simplest example, but consider the pattern of calling of
>the function compute_elevator_actuator_power (relative to the calling of all
>the other functions). In other words, when will it get called, compared to
>when the others get called? Will this pattern of calling be the same for
>each flight of the aeroplane? It will be different every time.

From your previous example I see what you are getting at by
'unpredictable pattern of calls' - assuming a repeating cycle program
(which all continuous execution real-time programs must be i.e. main
never exits!) - from cycle to cycle the pattern of calls _may_ (and
probably would) differ because of input changes .

>|For a well structured hard real-time program, no individual
>|input value should be unexpected

>It is a fundamental quality of input values that they are unpredictable. If
>the value of a certain input variable was predictable, you could use a
>constant, or a lookup table, or whatever, and not input it at all! Think
>about this.
Why don't you re-read my comment - the word I used was 'unexpected'
not unpredictable!

>|(i.e. not catered for in the code).

>There is a difference between a value being unpredictable, and it not being
>catered for in the code.
Agreed, but this is not the point!

>|Your argument assumes that the input values are coupled to the
>|algorithms of the system in a manner that allows unpredictable
>|behaviour!

>No, I am not saying this. I use very precise language very precisely.
>Perhaps you should go back, and read what I say very carefully.
Yep, I concede I misunderstood what you were saying about 'patterns of
calls'   - but practise what you preach!

>|If you use input values to determine program execution flow
>|then I would grant you that unpredicatble behaviour might result, e.g.
>|take input value, multiply by random number and put result in program
>|counter will certainly get interesting in a hurry!

>I think your example demonstrates that you don't really understand the
>nature of Von-Neumann architecture machines. 
Not at all, I simply didn't understand the 'pattern of calls' point
until you gave an example.

>|A well designed
>|hard realtime system would never be designed in such a manner :-)
This comment refers to the previous misunderstandings about input
values and program flow, it shoul I hope be obvious to anybody writing
a program that an input value changes the program flow - I hardly
think it is necessary to elaborate such points. This is in fact the
source of my misunderstanding over your pattern of calls point.

>Smiley noted, but this is not true, John! I don't like saying it, but I
>really am a veteran at this sort of thing, and I know what I'm talking
>about.

Since you have absolutely no idea of my experience in this field,
stating that you are a veteran seems like a chep attempt at brow
beating (and I didn't like saying that either!) 

>|For example in a process control system, input might be aquired at
>|known rates under interrupt. A background (i.e. non interrupt) cycle
>|would process the current set of inputs and update output values.
>|These might also be moved to the output hardware under interrupt.
>|There is nowhere a possibility of an input value changing the course
>|of execution of the background cycle (except through well understood
>|paths to cope for error conditions).

>I think (I hope ;-) my example above shows you that the course of execution
>can be - and indeed generally is - changed by input values.
Well, assuming that the code is written using conditional statements,
which might not be the case, there will of course be _minor_
variations in execution path, since efficient coding practice would be
to not execute unnecessary functions (re. your example).

<snip>

>I think, therefore, the rest of your argument is predicated on false
>premises.
Actually it is your argument that is based on false premises.

You stated;
>The maximum possible stack usage can be calculated. However, this figure
>will often be vastly greater than any stack usage that will occur in practise (and thus be
>useless).

Your argument being that calculation of the maximum possible stack is
useless because it is vastly more than will occur in practise. This is
obvious, so I followed this with a number of points about how this
value was refined;

>|Certainly the maximum value calculated will be high, but this value
>|can be adjusted into a more reasonable range by cursory examination of
>|the program. Firstly all interrupt routines and all routines that can
>|be called as a result of an interrupt must be accumulated (in terms of
>|stack requirement). 
This is because interrupt routines can interrupt each other (if
allowed to within the bounds of priority mechanisms etc.)


>|It is assumed here that an interrupt cannot
>|interrupt itself (if this is the case then the sums get harder ;-)).
Because it is a form of unbounded recursion!

>|Having done this the background loop can be examined, looking at the
>|call tree it is perfectly possible to deduce which routines can never
>|be called from inside others. This allows the maximum initial stack
>|requirement to be considerably reduced. This stage is often automated
>|by the toolset provided by the compiler vendor.

>Cursory examination of the program? A small program maybe!
Are you advocating the development of large monolithic embedded hard
real time programs here that are _NOT_ amenable to human analysis?

>Yes, a toolset
>(or appropriate compiler) can be used, but there are typically certain, more
>complicated, constructs that it cannot apply its deductive reasoning to. The
>result is, you have to avoid these constructs; in practice, doing this is
>always inconvenient but rarely impossible. My argument is that it is not
>always necessary to ensure a stack 'crash' cannot happen
You can't _ensure_ a stack crash won't happen. There is always scope
for
a) programmer error,
b) bit errors,
c) erroneous CPU operation - caused by brown outs on the power supply,
etc etc etc

> - typically by
>ensuring the amount of memory reserved for the stack will always be
>sufficient - because sometimes it is perfectly workable to allow such a
>crash to happen, providing you take the necessary precautions.

When, in a hard real-time embedded system is a stack crash acceptable?
Can you guarantee (unless we are talking about cycling through a reset
vector here -[ is this your necessary precaution?]) that post crash
your system is not corrupted in some subtle way?

There is no way that a crash _should_ occur in a hard real-time system
as a deliberate result of programming. 

Any reasonably sane embedded engineer will of course have watchdog
routines to catch infinte looping, they may add traps for stack
overflow and they may test critical variables. In all cases the
unexpected would cause (generally) a restart from zero. But I am
horriffied at the thought of a hard real-time system restarting
because of memory overflow - that to me indicates a significant design
failure.

<snip>
>No I don't believe that recursion is a necessity for hard real-time
>programming, and I never said so.
Neither did I - what's your point?

>I simply believe that it is not always
>necessary to avoid using recursion, for two reasons: (a) in your own words

>|If you do have
>|to use recursion then it must be bounded - if it is not then you have
>|a non-deterministic system. By definition if the system may behave
>|non-deterministically, then it cannot solve a hard real-time problem
>|(a deadline can never be missed!)

>... and (b) there are almost always, in real real-time projects, parts of
>the program which can fail - providing the failure can be caught and
>properly recovered - without going beyond the bounds of reliability or
>robustness required. For these parts of the program, it is acceptable to use
>code which may run out memory - be it stack memory or heap memory (or any
>other kind of memory) - provided that you can ensure that if it ever does
>run out of memory, the ensuing 'crash' (or whatever perjorative term you
>fancy using) and recovery does not jeopardise the minimum level of reliable
>execution required of the software.

I'm sorry, I find it difficult to conceive of  "parts of
the program which can fail - providing the failure can be caught and
properly recovered - without going beyond the bounds of reliability or
robustness required", in a real time system. 

What are they in there for if they are not critical to the system? 

If they are not part of an agreed customer specification - should they
be included if there is the slightest chance that they might impact
the performance of what is actually required. 

After all, how can one of these 'parts' fail with a stack crash
without potentialy impacting for example an interrupt routine that
calls a re-enterant sub routine?

>Of course, this does place constraints on the 'crashable' parts of the
>program: (1) you must be sure that the crashes won't happen at a time or in
>a circumstance which will jeopardise safety (or otherwise be unacceptable);

So this rules out any system that uses interrupts, or at least when
interrupts are enabled! Of course in an HRT system unacceptable would
be any impact on performance that affects response time. How do you
constrain when a crash happens? By only running the offending code at
specific times? Perhaps you could put up a warning message. Don't
apply up elevator just yet - the software is performing an operation
that may crash? Just how in a real-time system do you anticipate when
is a good time to do something?

>(2) you must be sure that the memory overflow will always be detected;
Easy to say - how would you advocate doing it?

>(3) you must be sure that the overflow will never interfere with the memory or
>operation of the rest of the program;
Right, so lets take a couple of cases;
Stack overflow - Oops that'll stuff up any interrupt routines - unless
of course you just let them compund the problem.
Heap overflow - Oh corrupts the stack and stuffs a return address for
some other bit of the program.
Divide by zero - steals cycles from rest of code?

>(4) you must be sure that recovery
>will always be possible and correctly executed;
How do you recover the state of the memory corrupted by a stack or
heap crash.

> (5) you must be sure that the recovery process will never interfere with the proper operation of the
>rest of the software;
So the crash occurs - and you need cycles to put right the damage (or
rewind) but there is no impact on the proper operation of the
software. I guess if you're just eating idle time there's no problem,
but what about interrupts. After all we're talking real-time here, so
bang worst case high priority interrupt 1 microsecond after you've
stack crashed.

> (6) you must be sure that the crash/recovery process
>will never causes the gradual erosion of memory or other resources; and so
>on.
Memory leaks should never occur in any kind of system! But are you
talking about fragmentation here?

>But all of these constraints can be met, and it is not usually impractical
>to do so.
Frankly that last comment is bull. 

>I simply repeat that I am a veteran of these things.
As am I.

>|Whilst I would not completely rule
>|out the use of dynamic memory allocation (i.e. the use of malloc and
>|free)

>Hooray! ;-)
Smiley acknowledged.

>|I would state categorically that there are very few hard
>|real-time systems IMHO where its use is a necessity.

>I don't disagree with this, and I didn't in my original post! I'm not
>arguing that its use is ever necessary, but simply that its non-use is not
>always necessary.
Sorry, I don't disagree :-). I also never said that it's non-use is
necessary; 
--------------------------------------------------------------V
>|I would state categorically that there are very few hard
>|real-time systems IMHO where its use is a necessity.

What I did say was;
>|Since by its very
>|nature it makes deterministic behaviour more difficult to implement,
>|it is better avoided.

>|>Taking the example of a program which flies an aeroplane, you will want to
>|>adopt a strategy of absolute robustness ('never crash').

>|>[1] This means that, if the program uses dynamic allocation, either it must
>|>be possible to statically determine that memory will never be insufficient,

>|A near tautology.

>Not at all! There are some programs (only a few) which use dynamic
>allocation which can be analysed and proved to never require more than a
>certain amount of memory at any one point in time. For such a program, if
>you supply at least that amount of memory, you have a program which uses
>dynamic allocation but where it is possible to statically determine that
>memory will never be insufficient. No tautology!
That's why I said a near tautology, you yourself make the point that
only a few programs fall into this category!

>|>or there must be a means of: (a) reliably detecting insufficient memory;
>and
>|>(b) upon detecting this, returning the software to a state that enables it
>|>to continue safely flying the aeroplane. These requirements are not
>usually
>|>impractical to achieve.

Now here is where I fundamentally disagree. Is it truly practical to
implement the constrained mechanisms you advocate simply to allow the
use of dynamic memory for only those parts of the system that are not
critical in meeting reliability and robustness requirments? What
benefit do you get by adding complexity here?

>I am not advocating the dreaded blue screen, nor the
>attitude that goes with it (of 'throw-away' software as I think a recent
>poster put it). Some means - be it a language's exception mechanism or
>something else - must be used to catch the memory overflow condition and
>then reset variables to a stable state (including the PC, if you want to
>look at it that way) so that execution can continue 'gracefully'.
But how can you achieve this given all the constraints YOU put upon
the mechanism? BTW I see nothing graceful in any kind of crash.

>|You are advocating designing a piece of software that has known flaws.

>Perjorative language doth not an argument make. You can call it a 'flaw' if
>you like, but it is only a convention to consider it a flaw that a piece of
>software may run out of memory from time to time. In reality, this is only a
>flaw if it happens without the programmer's intent or consent; if it happens
>but is planned for and expected, it is not a flaw, John.
I would consider it a flaw in the programmers design strategy, Nick.

>|A good embedded software designer would regard stack (or heap) bounds
>|checking, (or a watchdog timer) as a belt and braces safety measure -
>|not as an integral part of the design.

>Only because that is the orthodoxy they have been taught.
Seems OK to me. Layered safety I think they call it!

>|BTW - if the input condition causes the program to CRASH, ie fail to
>|perform to specification - how does restarting the program resolve
>|that problem if the input condition continues unchanged. I.e. If the
>|pilot puts his aircraft into an inverted flat sipn, and the program
>|runs out of heap trying to solve the problem, how does "
>|>returning the software to a state that enables it to continue safely
>flying the aeroplane<
>|stop the same thing happening again?

>I am pointedly not advocating that vital flight systems are programmed so
>that they could run out of memory at a critical time! Mary, God, and all the
>saints forbid. But, to continue with the example of an aeroplane, there will
>be lots of subsystems which are not at all crititcal to flight safety. An
>example of this might be a task whose sole function was to monitor the fuel
>levels in the various fuel tanks, and (in 'auto' mode) automatically pump
>fuel from one tank to another so as to retain optimum 'flight profile'. If
>this task were to crash once in a while, and have to reset itself to
>recover, this would never jeopardise anyone's safety at any time.

But you seem to be advocating that this critical function be
implemented as a part of a safety critical system, and further that if
it is incorporated into such a system that it can be allowed to fail.
It is evident that you have no experience of failure analysis if this
is truly what you are advocating. The safety guys would eat you for
breakfast.

>|>[2] If the software has interrupt servicing time constraints, the
>|>interrupt servicing routines which have these constraints must either: (a) be able
>|>to use the dynamic allocation in a way which is predictably fast enough; or
>|>(b) not use dynamic allocation. These conditions do not need to be imposed on
>|>any of the other parts of the software (if there are any).

>| Why oh why would an interrupt need to dynamically allocate memory?????

>I did not suggest that interrupts are likely to need to to dynamically
>allocate memory. Yet again, I did not write this and I did not mean it.
Oh I'm sorry, shall I quote you ->
" the interrupt servicing routines which have these constraints must
either: (a) be able to use the dynamic allocation in a way which is
predictably fast enough;

Seems perfectly clear to me what was written and that I therefore
replied to.

>I am
>simply saying that, provided the dynamic allocation can be done in a way
>which is predictably fast enough, it can be safely done. Are you disagreeing
>with this statement? If so, say how, precisely.

Yes I am. If you use dynamic memory allocation you are at risk of over
running the available memory. Note that this is not necessarily (but
typically is) the case. Speed of allocation is only one of the issues
here. You have not shown that it is safe (or safer) to use dynamic
memory allocation in a hard real-time system, rather you have
emphasised all the constraints one might be under if you do. Given
that my contention was 
>|Since by its very
>|nature it makes deterministic behaviour more difficult to implement,
>|it is better avoided.

I think you've made my point rather well.

>I'm getting the impression that you're one of those programmers who thinks
>that synchronisation between tasks is a matter of 'suck it and see', rather
>than using the proper synchronisation mechanisms in the proper places. A
>good embedded software designer will only ever rely upon these mechanisms to
>maintain the necessary synchronous behaviour between tasks, and not upon
>hoping that some tasks will be able to 'keep up'.

I don't see where you got this impression at all. It's not correct.

>Wow, what an egregiously bogus argument!
Admittedly a somewhat spurious comment about the effects of radiation
on hardware - would you dispute that an array of 256 chars indexed by
a short integer (8 bit) is safer than a 256 byte block of memory
accessed by 32 bit pointer? After all, corruption of my index at least
stays within the bounds of the array. 
>John, the processor uses pointers (e.g. the program counter)
This is a register _inside_ the CPU - the radiation implications are
somewhat different - for instance it may well be implemented using
static RAM rather than external memory which is where pointers would
typically be stored.

> whether you like it or not. Take a look at the
>machine code produced by your compiler. It is full of pointers! Memory for
>hard applications has had sophisticated ECC schemes for years: even if it
>fails (to correct a bad bit) the failure is caught (it tugs on the NMI) and
>then the software - and this is the bit you need to read, John - must then
>be able to restart itself 'gracefully' (either that or BSOD). I take it you
>don't design yet your software to do this.
Resorting to casting aspertions on my competence is a poor debating
tactic. Restarting software as a result of a hardware failure has no
relevance to the topic of dynamic memory allocation in embedded
systems. I never disputed the requirement for layered backups to the
software - I even mentioned then in my posting. You appear to be
trying to mix the arguments here.

>|> Instead, all that is required is to reprogram the dynamic
>|>allocation facilities to your requirements: you may need a 'malloc_a', a
>|>'malloc_b', and a 'malloc_c', or whatever. The result is likely to be better
>|>source code and better performing software, with no reduction in robustness.

>|Oh goody yet more potentially bug ridden code to add into our resource
>|limited system to support an unnecessary convenience.

>I'm not advocating anybody introduce bug-ridden code,
Neither was I, I said yet more potentially bug-ridden code, the
emphasis being of course on the fact that a) yuo're increasing the
size of the code base, b) more code means more bugs - since all code
has bugs.

> and I'm not advocating
>anybody introduce code which hogs too much resource. Of course there will be
>applications which cannot support the overhead or the complexity of dynamic
>allocation. But I bet you there are many applications for which this is not
>necessarily true.

> Using dynamic allocation can improve code (machine code
>speed and size, and source code size and complexity) by the classic
>technique of 'factoring out' allocation code: instead of having what is
>effectively allocation code (for arrays) in several places in your program,
>you have it in only one place (for the heap) instead.

allocation code for arrays???

>|>In addition, in view of my comments earlier in this posting about the
>|>dynamic nature of allocation on the stack, it will often be the case thatmy
>|>comments above about dynamic allocation can be applied to stack allocation
>|>as well (saving a lot of memory space wasted on making sure the stack cannot
>|>crash).

You were the one who brought up this idea of writing code to ensure
the stack would'nt crash. I don't see any memory requirement in a
statically allocated system for this at all. It is your 'solution'
with multiple allocation routines and horrendous constraints that is
going to increase the memory wasted. For example you are going to use
memory to indicate whether it is safe to enter one of your
non-critical - might blow the stack / heap - routines. 

I simply stated that the stack requirement for a statically allocated
program can be easily calculated (given certain inconsequential
restrictions - such as recursion and function pointers), and that this
was not so easy for a system using dynamic memory allocation. My
contention from there was that dynamic memory allocation is not
_necessary_ for the majority of embedded real time systems. I then
made the following comment;

>|You don't code around problems.
>|You design in such a way as to never encounter them. This is exactly
>|what the contention is. By not using dynamic memory allocation and
>|having a statically allocated program - you simply never encounter the
>|following problems (and therefore never need any code for them!)

>|Heap overflow.
>|Heap fragmentation.
>|Stack Overflow (assuming you get the sums right - but at least you
>|have tried, which is more than can be said for the never, never
>|approach you are advocating).

>But John, I repeat, these are only problems if they are not properly
>anticipated and dealt with. You must avoid the pitfall of being blinded by
>the perjorative terms you have been taught for things. I am saying that,
>with care, all of these 'problems' can be anticipated and dealt with
>perfectly satisfactorily. There is nothing 'never never' about this
>approach: it is rock solid! On the other hand your attitude of 'at least I
>have tried' is nearer to a 'never never' approach.

 I have only one further comment to make KISS.

>My best wishes to you, John. I entreat you to objectively rethink your
>position on this subject, and I wish you the best of success in your
>real-time projects.

Thanks for the blessing, I am sorry if this posting appears agressive
in tone, but I would entreat you to consider taking a less patronising
tone.

FYI I have a history of very successful hard real time projects behind
me.

BTW - If you follow this up, can we continue this thread only in
comp.realtime, this thread is far too X-posted.

regards John B.

Re: Ada vs C++ vs Java

[Ola Liljedahl]

Lots of crossposted groups.
This posting probably mostly concerns comp.realtime.

Wolfgang Denk wrote:
> 
> johnb@invision.co.uk (John Birch) writes:
> 
> >There are many embedded programmers who regard the concept of dynamic
> >memory allocation in an embedded system as laughable at best and a
> >terminal offence at worst. If you restict C++ in such a way (i.e.
> 
> I think you are on very thin ice here.

<SNIP>

> But even under hard  realtime  you  certainly  will  very  often  use
> dynamic  memory allocation - all variables put on the stack are using
> a method of  "dynamic  memory  allocation",  aren't  they?  And  even
> malloc()  has it's use here and there, especially when you do it only
> once during initialization/configuration...

What if the malloc() and free calls() take deterministic time?

OSE's heap functions have these real-time properties and if they
are not fast enough the kernel's pool functions (for allocation
and freeing message buffers) are a lot faster and of course also
deterministic in time.

But using dynamic memory allocation increases the probability that
the system will run out of memory or it at least becomes a lot more
difficult to verify that it doesn't. So static memory allocation
is more reliable. Stack allocation should be as reliable because
it should be possible to compute the maximum stack usage and
allocate a suitable stack for the process/task/thread.
--
	Ola Liljedahl
	olli@enea.se
	Enea OSE Systems

Re: Ada vs C++ vs Java

[Herman]

One can get fairly predictable memory management results if one uses a
partitioned approach with fixed block sizes.  We have used that approach
with VRTX on airborne products and it proved to be reliable.

Cheers,

Herman

Wolfgang Denk wrote:
> 
> johnb@invision.co.uk (John Birch) writes:
> 
> >There are many embedded programmers who regard the concept of dynamic
> >memory allocation in an embedded system as laughable at best and a
> >terminal offence at worst. If you restict C++ in such a way (i.e.
> 
> I think you are on very thin ice here.
> 
> First, I gues you really were thinking  of  "hard  realtime  require-
> ments",  which  is  a somewhat different issue. Many embedded systems
> don't have realtime problems (but of course  there  are  many  others
> that do).
> 
> But even under hard  realtime  you  certainly  will  very  often  use
> dynamic  memory allocation - all variables put on the stack are using
> a method of  "dynamic  memory  allocation",  aren't  they?  And  even
> malloc()  has it's use here and there, especially when you do it only
> once during initialization/configuration...
> 
> Wolfgang Denk
> 
> --
> Office:  (+49)-89-722-27328, Fax -36703  Wolfgang.Denk@icn.siemens.de
> Private: (+49)-89-95720-110, Fax -112                  wd@denx.muc.de
> Another dream that failed.  There's nothing sadder.
>         -- Kirk, "This side of Paradise", stardate 3417.3

Re: Ada vs C++ vs Java

[John Birch]

Wolfgang Denk wrote in message <77mu1h$n6m$1@galaxy.mchh.siemens.de>...

 I (John Birch) wrote:

>>There are many embedded programmers who regard the concept of dynamic
>>memory allocation in an embedded system as laughable at best and a
>>terminal offence at worst.

>I think you are on very thin ice here.

Well, I'm one of them and I have many colleagues who feel similarly ;-)


>First, I gues you really were thinking  of  "hard  realtime  require-
>ments",  which  is  a somewhat different issue. Many embedded systems
>don't have realtime problems (but of course  there  are  many  others
>that do).

What is an embedded system? By my definition it is a system designed to
perform a single specific task in accordance with a rigid specification -
including time constraints.

>But even under hard  realtime  you  certainly  will  very  often  use
>dynamic  memory allocation

I certainly wouldn't :-)

> - all variables put on the stack are using
>a method of  "dynamic  memory  allocation",  aren't  they?

That's rather tenuous, but the maximum potential stack size is calculable
provided you don't use recursion.

>  And  even
>malloc()  has it's use here and there, especially when you do it only
>once during initialization/configuration...

That might be the only time to use it, but the main point of dynamic
allocation is that memory is used and returned to a pool to allow for a
program to run in a smaller memory footprint than would be necessary if all
data was statically allocated. Of course then the ugly spectre of memory
fragmentation rears it's head!

regards John Birch (at home)

>Wolfgang Denk
>
>--
>Office:  (+49)-89-722-27328, Fax -36703  Wolfgang.Denk@icn.siemens.de
>Private: (+49)-89-95720-110, Fax -112                  wd@denx.muc.de
>Another dream that failed.  There's nothing sadder.
> -- Kirk, "This side of Paradise", stardate 3417.3

Re: Ada vs C++ vs Java

[Matthew Heaney]

"Erik Funkenbusch" <erikf@visi.com> writes:

> >- be available for popular processors (such as 68xxx, PowerPC, etc.)
> 
> Processors aren't the key, OS platforms are.  You're most safe with C++ on
> this matter i think.  Java isn't available on everything yet.  You're also
> likely to find limited choices in ADA compilers on more obscure OS's.

This is a weak argument.  The Ada front end marketed by AverStar
(formerly Intermetrics) emits human-readable C code, and therefore you
can use it where-ever there's a C compiler available.  If you want a
real compiler (instead of a "mere" translater), then contact Tucker Taft
about price.

gnat is also very portable.  Contact ACT about the cost of a port for
your "obscure" OS.

<mailto:stt@inmet.com>
<mailto:sales@act.com>

Note also that Ada is not an acronym, and is therefore spelled using
title-format, not all-uppercase.  The language was named after a woman,
Ada Lovelace, assistent of Charles Babbage and the first programmer.

> >- enjoy wealth of existing solutions
> 
> If you mean add-on libraries, again this is mostly OS platform related,
> although there are certainly a number of platform independant libraries as
> well.  I don't know much about the 3rd party ADA market, but C++ certainly
> has a strong support here.

You can call the library directly from Ada (via a thin binding), or
(what I prefer) just call a thin layer of code (say, written in C) that
itself calls the library.
 
> >- be suitable for design of embedded systems
> 
> C++ generally isn't.  There is an "embedded C++" that's in the works, and
> there might even be some implementations.  C is better for embedded work
> than C++.  I don't know the specifics of ADA embedded work.

Although Ada is a general purpose programming language, it was
originally designed for use in embedded systems.

For example, in Ada you don't need to use the heap to return a
unconstrained array from a function:

declare
  S : constant String := Name (File);
begin

No heap required!

(Of course, if you do need to allocate off the heap, then you can
substitute your own allocator, one the has the precise time and storage
behavior you require for your embedded application.  But, in many of
instances where heap is required in C/C++, no heap usage is required in
Ada.)

> >There is a legacy code written in Ada and our customer would prefer Ada
> >95. However, we became seriously concerned that there is not sufficient
> >support for Ada in the commercial world.
> 
> Well, there seems to be plenty of vendor support for ADA, but I think you
> won't find as much 3rd party library support.  That means you'll be stuck
> writing everything from scratch in most cases.

What specific 3rd party library support are you talking about?  Are
there libraries that exist that you can't call from Ada?

Many people unfamiliar with Ada don't realize that Ada was designed to
directly support calling code written in other languages. The argument
about "libraries not being available" is very weak.
 
>> Given, that we will be stuck with our project for the next several
>> years we would like to choose something that still will have adequate
>> support few years down the road.  Given all that we decided to check
>> C++ and Java. I would appreciate greatly any comparisons, comments,
>> hints, pointers to electronic and hard copy sources, warnings about
>> traps and pitfalls, etc. that would help us thoroughly justify the
>> language choice to our customer.
> 
> ADA is mature, and has proven itself in military applications and stability
> over the years.

Ada has proven itself in more than "military" applications.  It is the
language of choice for _commercial_ applications that have high
integrity requirements.

Many people unfamiliar with Ada think it's only used in military
applications.  This is incorrect.
-- 
Those who believe in the supernatural should be required to learn
computer programming.  This would force them to discover that things
which appear at first to be completely mysterious and incomprehensible,
in fact have a logical (and usually simple) explanation.  --J.B.R. Yant

Re: Ada vs C++ vs Java

[Matthew Heaney]

Matthew Heaney <matthew_heaney@acm.org> writes:

> gnat is also very portable.  Contact ACT about the cost of a port for
> your "obscure" OS.
> 
> <mailto:stt@inmet.com>
> <mailto:sales@act.com>

Oops, I think that should be

<mailto:sales@gnat.com>

Re: Ada vs C++ vs Java

[Ken Keys]

Matthew Heaney wrote:

 
> This is a weak argument.  The Ada front end marketed by AverStar
> (formerly Intermetrics) emits human-readable C code, and therefore you

Well it is readable by a C compiler. "Human-readable" is another matter.

> can use it where-ever there's a C compiler available.  If you want a

Not necessarily. There are, for instance, C compilers available for
certain 8 bit micros where not every program that can be compiled can be
run on the target. Writing a program that  will actually run requires
some concessions on the part of the programmer. The Ada translator, not
being aware of these concessions might not emit C code which can be
compiled into a runable program. Moreover, it could not be considered a
validated Ada implementation if the target didn't have enough resources
to support the full spectrum of Ada language features.

KLK

Re: Ada vs C++ vs Java

[Matthew Heaney]

For the real scoop, you'll have to ask Tucker directly.

<mailto:stt@averstar.com>
<http://www.averstar.com/~stt/>


Ken Keys <klkeys@west.raytheon.com> writes:

> Matthew Heaney wrote:
> 
>  
> > This is a weak argument.  The Ada front end marketed by AverStar
> > (formerly Intermetrics) emits human-readable C code, and therefore you
> 
> Well it is readable by a C compiler. "Human-readable" is another matter.
> 
> > can use it where-ever there's a C compiler available.  If you want a
> 
> Not necessarily. There are, for instance, C compilers available for
> certain 8 bit micros where not every program that can be compiled can be
> run on the target. Writing a program that  will actually run requires
> some concessions on the part of the programmer. The Ada translator, not
> being aware of these concessions might not emit C code which can be
> compiled into a runable program. Moreover, it could not be considered a
> validated Ada implementation if the target didn't have enough resources
> to support the full spectrum of Ada language features.
> 
> KLK

-- 
Those who believe in the supernatural should be required to learn
computer programming.  This would force them to discover that things
which appear at first to be completely mysterious and incomprehensible,
in fact have a logical (and usually simple) explanation.  --J.B.R. Yant

Re: Ada vs C++ vs Java

[Tucker Taft]

Ken Keys (klkeys@west.raytheon.com) wrote:

: Matthew Heaney wrote:

:  
: > This is a weak argument.  The Ada front end marketed by AverStar
: > (formerly Intermetrics) emits human-readable C code, and therefore you

: Well it is readable by a C compiler. "Human-readable" is another matter.

This variant of our Ada 95 front end compiles into optimized ANSI C,
that is actually designed to be human readable as well, to simplify 
manual debugging (it generates #line directives so that a "C" debugger
will display and step through the Ada source rather than the C intermediate).
For typical Ada code, you end up with pretty "typical" C code, 
though the identifiers (inherited from the Ada program) are probably 
longer than some C programmers are used to ;-).  If requested, it will 
take advantage of the C++ "namespace" feature in the output, to provide 
a more natural mapping for Ada package scopes.  It will also copy over
comments into the generated C code if requested.

: > can use it where-ever there's a C compiler available.  If you want a

: Not necessarily. There are, for instance, C compilers available for
: certain 8 bit micros where not every program that can be compiled can be
: run on the target. Writing a program that  will actually run requires
: some concessions on the part of the programmer. The Ada translator, not
: being aware of these concessions might not emit C code which can be
: compiled into a runable program. 

It doesn't emit very "exotic" C code.  Certainly any "validated" ANSI
C compiler could handle it ;-), and probably most usable C compilers,
even for microcontrollers.

: ... Moreover, it could not be considered a
: validated Ada implementation if the target didn't have enough resources
: to support the full spectrum of Ada language features.

That doesn't mean it isn't useful.  It does an order of magnitude
more compile-time checking than other languages, even if you restrict
yourself to the same kind of subset you would use if writing directly
in C for a microcontroller, and (in the absence of pragma suppress) will 
generate full run-time checking, while still being executable on essentially 
all machines out there.

The net effect is a significant boost in productivity, because the
Ada compiler and run-time checking are catching more errors, earlier, and 
providing better feedback as to their cause (rather than simply "bus 
error" ;-).  Things like packages and private types need impose no overhead
in the generated C, but can provide great benefits to the speed
of debugging and system integration.

: KLK

--
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Ada vs C++ vs Java

[Corvus]

well...I prefer C++ as it's easily maintainable and has more followers
than Ada...Actually...now that I think of it, Ada would be O.k too...if
you need programmers you can always check out military installations...

Leszek Sczaniecki wrote:
> 
> We are about to start a big project, something about 250k lines of code.
> We are going to stick to it for next several years. We would like to
> make an educated choice for the underlying language. This language
> should
> - support object oriented programming
> - support parallel programming
> - lead to easily maintainable code
> - promote safe programming techniques
> - have significant support from commercial vendors (compilers, GUI
> design, testing sw)
> - be available for popular processors (such as 68xxx, PowerPC, etc.)
> - enjoy wealth of existing solutions
> - support "almost real time" execution
> - be suitable for design of embedded systems
> - have existing support for vxworks
> 
> There is a legacy code written in Ada and our customer would prefer Ada
> 95. However, we became seriously concerned that there is not sufficient
> support for Ada in the commercial world. Given, that we will be stuck
> with our project for the next several years we would like to choose
> something that still will have adequate support few years down the road.
> Given all that we decided to check C++ and Java. I would appreciate
> greatly any comparisons, comments, hints, pointers to electronic and
> hard copy sources, warnings about traps and pitfalls, etc. that would
> help us thoroughly justify the language choice to our customer.
> 
> -leszek
> 
> PS
> If you are afraid that your response may start a religious war or that
> it is not of interest of your newsgroup please send me e-mail.

-- 
This is my .SIG file.  Enjoy.

Re: Ada vs C++ vs Java

[Herman]

Hi guys,

Nobody need be scared of Ada.  It is just Pascal by another name,
usually used with an overpriced development system, although the FSF has
a perfectly good Ada95 compiler too which can even run on a PC under DOS
(no need for Rational tools on Sun's...)

Once you have translated the following French terms to Swiss terms:
method = procedure
object = structure
specification = header
tower = make file

and realized that even Ada has a goto statement, the mystique
surrounding Ada disappears!

Cheers,

Herman


Corvus wrote:
> 
> well...I prefer C++ as it's easily maintainable and has more followers
> than Ada...Actually...now that I think of it, Ada would be O.k too...if
> you need programmers you can always check out military installations...
> 
> Leszek Sczaniecki wrote:
> >
> > We are about to start a big project, something about 250k lines of code.
> > We are going to stick to it for next several years. We would like to
> > make an educated choice for the underlying language. This language
> > should
> > - support object oriented programming
> > - support parallel programming
> > - lead to easily maintainable code
> > - promote safe programming techniques
> > - have significant support from commercial vendors (compilers, GUI
> > design, testing sw)
> > - be available for popular processors (such as 68xxx, PowerPC, etc.)
> > - enjoy wealth of existing solutions
> > - support "almost real time" execution
> > - be suitable for design of embedded systems
> > - have existing support for vxworks
> >
> > There is a legacy code written in Ada and our customer would prefer Ada
> > 95. However, we became seriously concerned that there is not sufficient
> > support for Ada in the commercial world. Given, that we will be stuck
> > with our project for the next several years we would like to choose
> > something that still will have adequate support few years down the road.
> > Given all that we decided to check C++ and Java. I would appreciate
> > greatly any comparisons, comments, hints, pointers to electronic and
> > hard copy sources, warnings about traps and pitfalls, etc. that would
> > help us thoroughly justify the language choice to our customer.
> >
> > -leszek
> >
> > PS
> > If you are afraid that your response may start a religious war or that
> > it is not of interest of your newsgroup please send me e-mail.
> 
> --
> This is my .SIG file.  Enjoy.

Re: Ada vs C++ vs Java

[Craig Garrett]

> and realized that even Ada has a goto statement

Hey!  Dont go spreading that information around!!!

 - Craig

Re: Ada vs C++ vs Java

[Michael Trausch]

The last thing we need is speghetti code!!!  Evil, evil stuff!!!

	- Mike


On Wed, 13 Jan 1999, Craig Garrett wrote:

> > and realized that even Ada has a goto statement
> 
> Hey!  Dont go spreading that information around!!!
> 
>  - Craig
> 
> 

-----
M. Trausch                                E-Mail:  mtrausch@wcnet.org

 Cole's Axiom: The sum of the intelligence on the planet is a constant.
 The population is growing.

Re: Ada vs C++ vs Java

[Martijn Lievaart]

Michael Trausch wrote in message ...
>The last thing we need is speghetti code!!!  Evil, evil stuff!!!
>


I always distinguish betwee maccaroni (not sure if this is correct in
English, I mean those short wigly pasta thingies) and spaghetti code.
Spaghetti code will still come apart in large threads if you pull, but
maccaroni is only short confusing pieces. ;^>

--
My reply-to address is intentionally set to /dev/null
reply to mlievaart at orion in nl

Re: Ada vs C++ vs Java

[Michael J. Tobler]

Martijn Lievaart wrote:
> 
> Michael Trausch wrote in message ...
> >The last thing we need is speghetti code!!!  Evil, evil stuff!!!
> >
> 
> I always distinguish betwee maccaroni (not sure if this is correct in
> English, I mean those short wigly pasta thingies) and spaghetti code.
> Spaghetti code will still come apart in large threads if you pull, but
> maccaroni is only short confusing pieces. ;^>

Great analogy. I have one - spaghetti chefs say that you
can tell when the spaghetti has been cooked long enough
by throwing it on the wall; if it falls, it's not ready,
if it sticks, it's ready.  In my opinion, spaghetti 
code 'never sticks to the wall'.

-- 
<<<<<<<<<<< Blue Skies >>>>>>>>>>>>
<       Michael J. Tobler         >
< remove "no-spam"when replying   >
< mailto:mtobler@no-spam-ibm.net  >
< http://www.webbrew.com/toblermj >
<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>

Re: Ada vs C++ vs Java

[Matthew Heaney]

Spaghetti code can be written easily enough even without the help of
goto statements.

Actually, choosing not to use a goto often obfuscates the algorithm.

Michael Trausch <mtrausch@wcnet.org> writes:

> The last thing we need is speghetti code!!!  Evil, evil stuff!!!
> 
> 	- Mike
> 
> 
> On Wed, 13 Jan 1999, Craig Garrett wrote:
> 
> > > and realized that even Ada has a goto statement
> > 
> > Hey!  Dont go spreading that information around!!!
> > 
> >  - Craig
> > 
> > 
> 
> -----
> M. Trausch                                E-Mail:  mtrausch@wcnet.org
> 
>  Cole's Axiom: The sum of the intelligence on the planet is a constant.
>  The population is growing.
> 
> 

-- 
Those who believe in the supernatural should be required to learn
computer programming.  This would force them to discover that things
which appear at first to be completely mysterious and incomprehensible,
in fact have a logical (and usually simple) explanation.  --J.B.R. Yant

Re: Ada vs C++ vs Java

[Matthew Heaney]

"Craig Garrett" <cgarrett@siscom.net> writes:

> > and realized that even Ada has a goto statement
> 
> Hey!  Dont go spreading that information around!!!

I use goto statements whenever I have to write a state-based
abstraction.  This is usually the case for Ada tasks, which are
typically written so that you jump among a few states.

You wouldn't believe the obtuse lengths to which programmers go, in
order to avoid spelling goto G-O-T-O.
-- 
Those who believe in the supernatural should be required to learn
computer programming.  This would force them to discover that things
which appear at first to be completely mysterious and incomprehensible,
in fact have a logical (and usually simple) explanation.  --J.B.R. Yant

Re: Ada vs C++ vs Java

[Craig Garrett]

BLASHPHEMER!!!!!!!!!!!

Shame on you!

Re: Ada vs C++ vs Java

[Jeff Carter]

Herman wrote:
> 
> Hi guys,
> 
> Nobody need be scared of Ada.  It is just Pascal by another name,

It has some significant improvements on Pascal, at least as I used it
for many years.

> usually used with an overpriced development system, although the FSF has
> a perfectly good Ada95 compiler too which can even run on a PC under DOS
> (no need for Rational tools on Sun's...)
> 
> Once you have translated the following French terms to Swiss terms:
> method = procedure
> object = structure
> specification = header
> tower = make file

With the exception of Specification, these are not Ada terms. Ada uses
Object to mean an instance of a type, whether variable or constant, but
not as a synonym of the C term Structure.

I have always disliked the term Method, which I would define as
Subprogram.

> 
> and realized that even Ada has a goto statement, the mystique
> surrounding Ada disappears!
> ...

I wasn't aware of a mystique surrounding Ada, but maybe that's because
I've been using it happily whenever possible for 15 years.

(We'd prefer you didn't tell people that Ada has a goto. We don't want
people who like goto's to use Ada.)

-- 
Jeff Carter
E-mail: carter commercial-at innocon [period | full stop] com
"Go and boil your bottom."
Monty Python & the Holy Grail

Re: Ada vs C++ vs Java

[dewar]

Herman wrote:
>
> Hi guys,
>
> Nobody need be scared of Ada.  It is just Pascal by
> another name,
>
> It has some significant improvements on Pascal, at least
> as I used it for many years.
>
> usually used with an overpriced development system,
> although the FSF has a perfectly good Ada95 compiler too
> which can even run on a PC under DOS

Just to clarify things here, GNAT is maintained by Ada
Core Technologies. The original version of GNAT was created
at New York University, under a contract that required NYU
to assign the copyright to FSF, so the copyright for large
parts of the GNAT technology is indeed held by the FSF, but
other than this connection, FSF has nothing to do with
GNAT.

The DOS version which you refer to was originally created
by a volunteer (Doug Rupp), and then for a while maintained
by Ada Core Technologies, but is now maintained by an
informal group of volunteers (for more information on the
DOS version, send mail to Mike Feldman at
mfeldman@cs.gwu.edu.

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Matthew Heaney]

Jeff Carter <spam.carter.not@spam.innocon.com> writes:

> I wasn't aware of a mystique surrounding Ada, but maybe that's because
> I've been using it happily whenever possible for 15 years.
> 
> (We'd prefer you didn't tell people that Ada has a goto. We don't want
> people who like goto's to use Ada.)

Oh dear, I think I've been ostracized...
-- 
Those who believe in the supernatural should be required to learn
computer programming.  This would force them to discover that things
which appear at first to be completely mysterious and incomprehensible,
in fact have a logical (and usually simple) explanation.  --J.B.R. Yant

Re: Ada vs C++ vs Java

[dennison]

In article <m3hftrj0ma.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:
> Jeff Carter <spam.carter.not@spam.innocon.com> writes:
>
> > I wasn't aware of a mystique surrounding Ada, but maybe that's because
> > I've been using it happily whenever possible for 15 years.
> >
> > (We'd prefer you didn't tell people that Ada has a goto. We don't want
> > people who like goto's to use Ada.)
>
> Oh dear, I think I've been ostracized...

Case statements in loops really aren't that bad. Join the light side! Let go
of your gotos... :-)

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[robert_dewar]

In article <77vkl8$qcs$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:

> Case statements in loops really aren't that bad. Join the
> light side! Let go of your gotos... :-)

Oh for goodness sakes, not this tired old thread here.
Anyone with any reasonable long term memory knows this has
been discussed to death, and that the bottom line is that
there is a divergence of opinion. There seem to be three
kinds of people.

1. People who much prefer the goto and consider it a
clearer (and likely more efficient) representation of
a finite state machine.

2. People who prefer the case statement, since they prefer
a data oriented representation with the state explicitly
encoded in data, rather than in the program location.

3. People who don't know enough to have a useful opinion,
but have been taught that gotos are always bad.

There really is ZERO point in declaring which of these
three groups you are in, since there is nothing new to
be said here. If you are really interested in this boring
issue, consult the archives.

But please, no posts from people in class 3, those are the
REALLY annoying ones :-)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Nick Roberts]

Matthew Heaney wrote in message ...
|Oh dear, I think I've been ostracized...
I'm sure I've got a cream for that, Matt
[PS: Is this a mega x posted topic or wot?]

Re: Ada vs C++ vs Java

[Peter Flynn]

test - sorry about this but I'm not too sure if my mails are posting OK.

Re: Ada vs C++ vs Java

[Thaddeus L. Olczyk]

On Wed, 13 Jan 1999 22:02:23 GMT, "Craig Garrett"
<cgarrett@siscom.net> wrote:

>> well...I prefer C++ as it's easily maintainable 
>
>I beg to differ.  Yes, C++ can be maintainable, but only if it was written
>EXTREMELY well, by very disciplined programmers who intended it to be
>maintainable.  Now, any language, including Ada, can result in hard to
>read, bad code, but, I have seen alot more bad C/C++ than I have bad Ada.
>

I do not think this is the responsibility of C++, rather it is the
responsibility of the market place. C++ was the hot, in-language. So
all your crap programmers ( which heavily outweigh good programmers )
learned C++. If Ada became the hot, in-language you would see a lot
more bad code in Ada. Java is taking C++'s place as the hot language,
and you are already seeing it happen there. In the long run this is
one thing that C++ owes to Java.

Re: Ada vs C++ vs Java

[Craig Garrett]

Well, the bad C++ code really came from the C programmers out there, who
should have been writing Assembly.  Start messing around with pointers, and
poof, bad code.  Its just too tempting (and sometimes necessary) to do this
in C/C++.
  Craig

Re: Ada vs C++ vs Java

[Gerry Quinn]

In article <01be426c$5945cb40$4304fbd1@longslide>, "Craig Garrett" <cgarrett@siscom.net> wrote:
=>Well, the bad C++ code really came from the C programmers out there, who
=>should have been writing Assembly.  Start messing around with pointers, and
=>poof, bad code.  Its just too tempting (and sometimes necessary) to do this
=>in C/C++.
=>  Craig

Start messing about with pointers when you're not good enough, and 
poof, bad code.  Stick to Java, patzer... VB is also safe! 

- Gerry

----------------------------------------------------------
  gerryq@indigo.ie  (Gerry Quinn)
----------------------------------------------------------

Re: Ada vs C++ vs Java

[Tom Maier]

"Craig Garrett" <cgarrett@siscom.net> wrote:

>> well...I prefer C++ as it's easily maintainable 
>
>I beg to differ.  Yes, C++ can be maintainable, but only if it was written
>EXTREMELY well, by very disciplined programmers who intended it to be
>maintainable.  Now, any language, including Ada, can result in hard to
>read, bad code, but, I have seen alot more bad C/C++ than I have bad Ada.
>

I worked together with another programmer, both of us doing the 
same program in Ada.  He never put any comments in so I ask him
to start.  His reply was "But this is a self documenting language!".

ARRRGGH!

Like you say, a mess can be made in any language.  Ocassionally
I demonstrate this by doing it myself.

Tom

Re: Ada vs C++ vs Java

[Vladyslav Kosulin]

Tom Maier wrote:
> 
> "Craig Garrett" <cgarrett@siscom.net> wrote:
> 
> >> well...I prefer C++ as it's easily maintainable
> >
> >I beg to differ.  Yes, C++ can be maintainable, but only if it was written
> >EXTREMELY well, by very disciplined programmers who intended it to be
> >maintainable.  Now, any language, including Ada, can result in hard to
> >read, bad code, but, I have seen alot more bad C/C++ than I have bad Ada.
> >
> 
> I worked together with another programmer, both of us doing the
> same program in Ada.  He never put any comments in so I ask him
> to start.  His reply was "But this is a self documenting language!".
> 
That's the problem of this programmer and his co-workers, not of language.
-- 
Sincerely yours,
Vladyslav Kosulin, Kharkiv, Ukraine
(vlad@kharkov.com)

Re: Ada vs C++ vs Java

[Michael J. Tobler]

Leszek Sczaniecki wrote:
> 
> We are about to start a big project, something about 250k lines of code.

R O T F L !!!!  I'm sorry for laughing soooooo hard, but
how can you possibly know the LOC there is going to be?
And you havent even picked an implementation language. 

I am going to make an educated guess - this project is 
already doomed :0

> We are going to stick to it for next several years. We would like to
> make an educated choice for the underlying language. This language
> should
> - support object oriented programming
> - support parallel programming
> - lead to easily maintainable code
> - promote safe programming techniques
> - have significant support from commercial vendors (compilers, GUI
> design, testing sw)
> - be available for popular processors (such as 68xxx, PowerPC, etc.)
> - enjoy wealth of existing solutions
> - support "almost real time" execution
> - be suitable for design of embedded systems
> - have existing support for vxworks

C++ and Java will work.

> There is a legacy code written in Ada and our customer would prefer Ada
> 95. However, we became seriously concerned that there is not sufficient
> support for Ada in the commercial world. Given, that we will be stuck
> with our project for the next several years we would like to choose
> something that still will have adequate support few years down the road.
> Given all that we decided to check C++ and Java. I would appreciate
> greatly any comparisons, comments, hints, pointers to electronic and
> hard copy sources, warnings about traps and pitfalls, etc. that would
> help us thoroughly justify the language choice to our customer.

You cant possibly expect to get an intelligent answer
based on the information given. We know nothing about 
the requirements of the system - they help drive the 
potential implementation. There is a lot of "other stuff"
that needs to happen before you start talking about
implementation language. You dont let the language drive
the project.

What ya'll probably need to do is to hire a consulting
company to mentor your team: to demonstrate proper
project practices and methodology.  This is not meant to 
slam ya'll's effort to build this system, I'm just saying 
that your team is starting off on the wrong foot.

-- 
<<<<<<<<<<< Blue Skies >>>>>>>>>>>>
<       Michael J. Tobler         >
< remove "no-spam"when replying   >
< mailto:mtobler@no-spam-ibm.net  >
< http://www.webbrew.com/toblermj >
<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>

Re: Ada vs C++ vs Java

[Tov Are Jacobsen]

Michael J. Tobler wrote:
> 
> Leszek Sczaniecki wrote:
> >
> > We are about to start a big project, something about 250k lines of code.
> 
> R O T F L !!!!  I'm sorry for laughing soooooo hard, but
> how can you possibly know the LOC there is going to be?
> And you havent even picked an implementation language.
> 

That estimate is easy if you get payed by the LOC you produce:

accurate_LOC_estimate = desired_salary / payment_per_LOC


---
Tov Are Jacobsen

Re: Ada vs C++ vs Java

[John Woodruff]

>>>>> "Leszek" == Leszek Sczaniecki <lsczan@concentric.net> writes:
In article <369C1F31.AE5AF7EF@concentric.net> Leszek Sczaniecki
<lsczan@concentric.net> writesm (in part):

    > We are about to start a big project, something about 250k lines of
    > code.  We are going to stick to it for next several years. We
    > would like to make an educated choice for the underlying
    > language. 

    > There is a legacy code written in Ada and our customer would
    > prefer Ada 95. However, we became seriously concerned that there
    > is not sufficient support for Ada in the commercial world. 

I suggest that Ada fulfills all your requirements, and according to
numerous other contributors to this thread is supported and long-lived
enough to qualify. Markus Kuhn, University of Cambridge, UK, wrote in a
different discussion, "I believe that Ada95 is tremendously underhyped."

My own work is in Ada95, building the software controls for the National
Ignition Facility, which will be the world's largest precision optical
instrument - a laser to perform fusion experiments.  We expect about
half a million SLOCS and we design for 30-year service life. (A paper in
SigAda 98 Conference Proceedings, to appear in Ada Letters, describes
our control system).

Ada meets or exceeds every one of our requirements: distribute
software over about 500 computers (mostly VxWorks PowerPC's and Suns)
using CORBA; incorporate commercial GUI and DBMS products; operate some
60_000 control points (of more than 400 distinct types).

--
John Woodruff                                             N I F   \ ^ /
Lawrence Livermore National Lab                         =====---- < 0 >
925 422 4661                                                      / v \

Re: Ada vs C++ vs Java

[Marin David Condic]

I've got a jet engine control for the F22 fighter that is programmed in
Ada and another one for the JSF programmed in Ada. Those engines aren't
going away any time real soon and so I've got similar concerns. Consider
that when you select a language/compiler you are going to arrive at a
point where you are going to have to freeze the version of the compiler
to maintain verification status. So fear of vendors going out of
business is probably irrelavent. Your biggest problem will be the
life/availability of the hardware/OS on which to run the compiler. (Ten
years ago, we were tied in with our Ada compiler for the F119 engine
(F22 airframe) on a VAX/VMS platform. We have migrated it to Alpha/VMS
but it is clear that this is not where industry is going. We've got
major problems if we ever have to migrate off of this platform!)

On the commercial side, we have large turbofan engines with controls
programmed in Ada and they have the same life expectancy issues and
verification issues. Lots of commercial avionics (Boeing 777 leaps to
mind) are programmed in Ada. Ask yourself how old the Boeing 747 is
(they first came out when I was a kid!) and it will give you some idea
as to how committed Boeing is to Ada. And remember that these are not
the only examples of Ada in the commercial world.

Ada may not have quite the following of C++ or Java, but it is not as if
there are only a few insignificant projects using it. It will not go
away any time real soon. Consider also how Java replaced C++ as "The Hip
Language Of The Day" just a short time ago. C++ didn't dry up and wither
away - it just took a back seat to the latest fad. And "fad" is exactly
what it is. In another year or two, the "Cool" language will be
something else, but Java won't go away either.

And besides: The world is what we make of it. If you sign your project
up for Ada and I do the same, etc, etc, we *create* the market that
keeps the language alive and well. I know there is enough critical mass
out there to keep Ada going for a number of years and if you sign on,
you're helping to cement that future.

MDC

Leszek Sczaniecki wrote:
> 
<snip>
> 
> There is a legacy code written in Ada and our customer would prefer Ada
> 95. However, we became seriously concerned that there is not sufficient
> support for Ada in the commercial world. Given, that we will be stuck
> with our project for the next several years we would like to choose
> something that still will have adequate support few years down the road.
> Given all that we decided to check C++ and Java. I would appreciate
> greatly any comparisons, comments, hints, pointers to electronic and
> hard copy sources, warnings about traps and pitfalls, etc. that would
> help us thoroughly justify the language choice to our customer.
> 
<snip>
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

    "Nobody shot me."

        --  Last words of Frank Gusenberg when asked by police who
            shot him fourteen times with a machine gun in the Saint
            Valentine's Day Massacre.

Re: Ada vs C++ vs Java

[David Gillon]

Marin David Condic wrote:
> 
> I've got a jet engine control for the F22 fighter that is programmed in
> Ada and another one for the JSF programmed in Ada. Those engines aren't
> going away any time real
[SNIP]
> On the commercial side, we have large turbofan engines with controls
> programmed in Ada and they have the same life expectancy issues and
> verification issues. Lots of commercial avionics (Boeing 777 leaps to
> mind) are programmed in Ada. Ask yourself how old the Boeing 747 is
> (they first came out when I was a kid!) and it will give you some idea
> as to how committed Boeing is to Ada.

Good points, I suspect that most people outside of the aerospace
industry underestimate the life expectancy of our current generation of
Ada projects by a considerable margin. Modern military aircraft run 15
year development cycles before service entry and can reasonably expect
to be in production for ten years or more, with possibly 40 year service
lives per airframe, for an inception to retirement duration of
potentially 65 years. The next generation of Western jets (F-22, JSF,
Typhoon (and Rafale?)) are all going to be heavily Ada dependent, and
can reasonably be expected to be in service, and therefore with a need
for continuing Ada based software support, past 2050 at least. The same
goes for 777, and given that 747 is still in active development of new
variants 30 years after service entry 2050 may be a conservative
estimate.
-----
David Gillon
MAv Rochester

Y2.1K (was: Ada vs C++ vs Java)

[Nick Roberts]

David Gillon wrote in message <369CF2EF.AC875B2A@gecm.com>...
[...]
|for continuing Ada based software support, past 2050 at least. The same
|goes for 777, and given that 747 is still in active development of new
|variants 30 years after service entry 2050 may be a conservative
|estimate.

[...]

Which causes me to renew my concerns about Ada's 'Y2.1K' problem.

I can honestly just see a whole squadron of F39 'Ares' superstealth
pilotless lazergun jet platforms (or whatever they hype them up as) - on a
fly-past of honour for the new year, 2100 AD - dropping out of the sky
straight onto a crowd of horrified USAF Generals.

Why? Take a look at Ada.Calendar.

As a matter of interest, if I were to declare Ada.Calendar.Year_Number as
having the range 0001..9999 (in line with the standard SQL definition of a
year), instead of 1901..2099 as required in the RM, would this be likely to
cause my compiler to fail the ACVC? Would it actually be a problem to anyone
(porting their existing code to my compiler)? Obviously it would potentially
be a problem to anyone requiring portability: but not if they wrote their
code carefully. Would anyone object?

I realise I would have to ensure the Ada.Calendar.Time type was able to
encompass these years, and that I would have to ensure leap years were
calculated correctly. I would use an assumed Gregorian calendar for all
dates (as specified for SQL).

-------------------------------------------
Nick Roberts
-------------------------------------------

Re: Y2.1K (was: Ada vs C++ vs Java)

[Robert A Duff]

"Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:

> As a matter of interest, if I were to declare Ada.Calendar.Year_Number as
> having the range 0001..9999 (in line with the standard SQL definition of a
> year), instead of 1901..2099 as required in the RM, would this be likely to
> cause my compiler to fail the ACVC?  ...

Interesting question.  I changed one of our (Averstar's) Ada
implementations (for the ADI SHARC target -- a cross compiler running on
Windows NT) in the way you suggested.  I ran the ACVC and got 100%
passing.  So the answer to your question appears to be "No".

Of course, this thing is no longer an Ada implementation.
I wouldn't want to sign the Delaration of Conformance after having so
deliberately disobeyed the standard!  And of course, there could be
a new ACVC test at any time, that checks that Year'Last = 2099.

By making this change, I broke the leap-year calculation, which depends
on the existing range of Year.  But of course the ACVC couldn't notice
that, and I didn't bother to fix it, since I was doing a throw-away
experiment just for fun.

By the way, I think ACVC is now called ACATS.  But I have trouble
breaking the habit -- just like lots of people say "rep specs" instead
of "rep clauses", and I sometimes say "protected record" instead of
"protected object".  And "Intermetrics" instead of "Averstar".  ;-)

>... Would it actually be a problem to anyone
> (porting their existing code to my compiler)?

It seems fairly unlikely to cause trouble.  But it *could*.
It also seems fairly unlikely to cause any good -- 2099 is
a long ways off.  I hope the state of the art in language
design has advanced a bit by then!

>... Obviously it would potentially
> be a problem to anyone requiring portability: but not if they wrote their
> code carefully. Would anyone object?

I object.

Your suggestion makes sense to me as a language change.
Maybe the next version of Ada will make the change.
But it seems naughty to just go off and do such a thing on your own.

You could submit it to the ARG if you like.

> I realise I would have to ensure the Ada.Calendar.Time type was able to
> encompass these years, and that I would have to ensure leap years were
> calculated correctly. I would use an assumed Gregorian calendar for all
> dates (as specified for SQL).

That makes sense.  (I've always been confused by people who object to
increasing the range into the past, because the people alive back then
used a different calendar.  I mean, doesn't it make perfect sense for me
to talk about something that happened in the year 100, even though the
people alive then called it something else?)

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Y2.1K (was: Ada vs C++ vs Java)

[robert_dewar]

In article <wcc3e4k7lev.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> "Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:
> Of course, this thing is no longer an Ada implementation.
> I wouldn't want to sign the Delaration of Conformance
> after having so deliberately disobeyed the standard!

So just put in a compiler option saying whether or not
to restrict the range.

Please don't imply that the ACVC or the DoC is such a
strait jacket when it is not!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Richard Krehbiel]

Marin David Condic wrote in message <369CBAED.20BE91CA@pwfl.com>...
>I've got a jet engine control for the F22 fighter that is programmed in
>Ada and another one for the JSF programmed in Ada. Those engines aren't
>going away any time real soon and so I've got similar concerns.

I would have to speculate that for this application, the amount of money you
spend on the compiler, tools, and support is virtually irrelevant.
Supposing Ada falls into disfavor and is relegated to a few critical
realtime tasks like yours, it's likely your Ada vendor will still be most
happy to continue to offer you years of support and upgrades, so long as the
contract is lucrative (and it can keep their company afloat).

Most of the rest of us care deeply whether the compiler and toolset costs
$50,000 a year for the support contract.  Choosing a language which is not
just a good language, but which is also popular, means we enjoy econmies of
scale and competition that ensure low prices and a choice of vendors.  This
is just one point of many to consider, but unless you find GNAT suitable, it
may tend to favor C++ over Ada.

>Leszek Sczaniecki wrote:
>>
><snip>
>>
>> There is a legacy code written in Ada and our customer would prefer Ada
>> 95. However, we became seriously concerned that there is not sufficient
>> support for Ada in the commercial world. Given, that we will be stuck
>> with our project for the next several years we would like to choose
>> something that still will have adequate support few years down the road.
>> Given all that we decided to check C++ and Java. I would appreciate
>> greatly any comparisons, comments, hints, pointers to electronic and
>> hard copy sources, warnings about traps and pitfalls, etc. that would
>> help us thoroughly justify the language choice to our customer.


--
Richard Krehbiel, Kastle Systems, Arlington VA USA
rich@kastle.com (work) or krehbiel@crosslink.net (personal)

Re: Ada vs C++ vs Java

[Dave Hansen]

On Wed, 13 Jan 1999 16:27:54 -0500, "Richard Krehbiel"
<rich@kastle.com> wrote:

>Marin David Condic wrote in message <369CBAED.20BE91CA@pwfl.com>...
>>I've got a jet engine control for the F22 fighter that is programmed in
>>Ada and another one for the JSF programmed in Ada. Those engines aren't
>>going away any time real soon and so I've got similar concerns.
>
>I would have to speculate that for this application, the amount of money you
>spend on the compiler, tools, and support is virtually irrelevant.

Just to provide a data point, I've worked on Military, commercial
avionics, process control, semiconductor research and many other kinds
of projects.  I have yet to find one where the budget for software
tools is "virtually irrelevant."

>Supposing Ada falls into disfavor and is relegated to a few critical
>realtime tasks like yours, it's likely your Ada vendor will still be most
>happy to continue to offer you years of support and upgrades, so long as the
>contract is lucrative (and it can keep their company afloat).

And supposing demons fly out of your nose when you modify an lvalue
twice between sequence points in C++?

But I don't think either occurance is very likely...

>
>Most of the rest of us care deeply whether the compiler and toolset costs
>$50,000 a year for the support contract.  Choosing a language which is not

Wow!  Who's charging that much?

Last time I checked, OpenAda from Rational was $99, ObjectAda from
Aonix was $245.  I don't know what they charge for support, but I
would guess it's less than $50K/yr.

>just a good language, but which is also popular, means we enjoy econmies of
>scale and competition that ensure low prices and a choice of vendors.  This
                                                    ^^^^^^^^^^^^^^^^^

and programmers.  Most programmers looking for a job claim to know
C++.  How well they know it is another matter...

>is just one point of many to consider, but unless you find GNAT suitable, it
>may tend to favor C++ over Ada.

I guess I'm not sure how GNAT wouldn't be suitable, especially to a
group considering C++ as an alternative...

All IMHO, a guy who makes his living writing C and C++ code...

Regards,

                          -=Dave
Just my (10-010) cents
I can barely speak for myself, so I certainly can't speak for B-Tree.
Change is inevitable.  Progress is not.

Re: Ada vs C++ vs Java

[Marin David Condic]

Well I'll come as clean as I can on the issue of cost. We *do* care how
much a compiler costs and we *don't* want to be some vendor's cash cow.
We, as much as anybody else, want to save money and do the job in as
cost effective a manner as possible. We get squeezed by budgetary
constraints as much as the next guy.

That being said, if suddenly there were only one Ada vendor on the
planet and they, like all good businessmen, set their prices to get
MC=MR and started jumping the price up to significantly higher levels,
we'd probably have to take a look at the investment we already have in
home-grown and off-the-shelf tools & infrastructure and decide if it
made sense to scrap the language or allow ourselves to be milked. Given
the size of what we do and our investment in infrastructure, the price
tag could go up and we'd find it to our advantage to pay. Fortunately,
there *is* competition and even if not, there *are* alternatives. We're
pretty smart around here when it comes to software and we could find a
way of vertically integrating if we were under threat.

Keep in mind that Ada compilers for most platforms are not that
expensive. Many of them can be purchased by your garden variety engineer
for home use without first getting permission from the spousal unit.
More fully featured systems are still within the reach of a well paid
engineer who saves his money and is enough of a geek to blow it on a
compiler instead of a vacation. And once we start talking about
*embedded* systems, the price tag of *all* compilers goes up
significantly for some pretty obvious reasons: You need really good
quality code out of them and you need lots of support tools to get the
code into the embedded box. The more stuff a vendor gives you, the more
they expect to receive on payday.

As for paying lots of money for a support contract, I think that is more
a function of what sort of support you need for the job you are doing.
I'm sure that if I had to go to a vendor of *any* language and ask for
the kinds of modifications, extensions, bug fixing and hand-holding that
is typical of hard real time development, they'd want a bunch of money
too. OTOH, I've purchased compilers with zero support beyond a couple of
installation related phone calls (any vendor had better give you this
much) and been quite happy with the results. It depends what you expect
to do with the compiler.

Also, a thing you want to consider with hard real time, safety critical
applications is that at some point rather early on in the life of the
project, you no longer need *any* support from the vendor because you
are going to freeze the version of the compiler and live with it the way
it is. Usually this is also a point in the project where you no longer
need to call the vendor and ask "How do I make your compiler do XYZ????"
so if the vendor wants to milk you, they've got to do it in the early
stages.

MDC

Richard Krehbiel wrote:
> I would have to speculate that for this application, the amount of money you
> spend on the compiler, tools, and support is virtually irrelevant.
> Supposing Ada falls into disfavor and is relegated to a few critical
> realtime tasks like yours, it's likely your Ada vendor will still be most
> happy to continue to offer you years of support and upgrades, so long as the
> contract is lucrative (and it can keep their company afloat).
> 
> Most of the rest of us care deeply whether the compiler and toolset costs
> $50,000 a year for the support contract.  Choosing a language which is not
> just a good language, but which is also popular, means we enjoy econmies of
> scale and competition that ensure low prices and a choice of vendors.  This
> is just one point of many to consider, but unless you find GNAT suitable, it
> may tend to favor C++ over Ada.
> 

-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

    "Nobody shot me."

        --  Last words of Frank Gusenberg when asked by police who
            shot him fourteen times with a machine gun in the Saint
            Valentine's Day Massacre.

Re: Ada vs C++ vs Java

[dennison]

In article <77j34t$b11@agora.dmz.khoral.com>,
  "Richard Krehbiel" <rich@kastle.com> wrote:
> Most of the rest of us care deeply whether the compiler and toolset costs
> $50,000 a year for the support contract.  Choosing a language which is not
> just a good language, but which is also popular, means we enjoy econmies of
> scale and competition that ensure low prices and a choice of vendors.  This
> is just one point of many to consider, but unless you find GNAT suitable, it
> may tend to favor C++ over Ada.

Fourtunately Ada compilers for the PC platform do *not* exhibit this
behavior. However they do tend to have the drawback that you still have to
buy Visual C++ to do serious development. Microsoft doesn't make their linker
available any other way, and noone's ballsy enough to reverse engineer it.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[dewar]

In article <77l9dt$a8n$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> Fourtunately Ada compilers for the PC platform do *not*
> exhibit this behavior. However they do tend to have the
> drawback that you still have to buy Visual C++ to do
> serious development. Microsoft doesn't make their linker
> available any other way, and noone's ballsy enough to
> reverse engineer it.

This is misleading information. GNAT for NT does indeed
provide a loader that can build and communicate with DLL's
built by the Microsoft linker, and the use of the Microsoft
linker is not required at all for building Ada programs
using GNAT.

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[dennison]

In article <77mavc$6vf$1@nnrp1.dejanews.com>,
  dewar@gnat.com wrote:
> In article <77l9dt$a8n$1@nnrp1.dejanews.com>,
>   dennison@telepath.com wrote:
> > Fourtunately Ada compilers for the PC platform do *not*
> > exhibit this behavior. However they do tend to have the
> > drawback that you still have to buy Visual C++ to do
> > serious development. Microsoft doesn't make their linker
> > available any other way, and noone's ballsy enough to
> > reverse engineer it.
>
> This is misleading information. GNAT for NT does indeed
> provide a loader that can build and communicate with DLL's
> built by the Microsoft linker, and the use of the Microsoft
> linker is not required at all for building Ada programs
> using GNAT.

Yes. But my understanding w/ Gnat is that the Win32 spec files are under the
Microsoft copyright, and are techinicly not supposed to be used by anyone who
does not have VC++ installed. Also, does Gnat's linker allow linking to VC++
object files?

I believe Aonix got around this issue by licensing (sounds so much nicer than
"bribing") the linker from Microsoft. Last I heard, Rational's solution was to
make VisualC++ a "System Requirement".

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Peter]

In article <369CBAED.20BE91CA@pwfl.com>, diespammer@pwfl.com wrote:

> In another year or two, the "Cool" language will be
> something else, but Java won't go away either.

I'm not so sure that Java won't go away quicker than you expect.  If most
people/organizations are only using Java for "throw-away" projects, then
it is not very painful to move on to a programming language which is
deemed more abstract, and generally better overall.

Personally, I have not encountered any commercial applications or
operating systems written in Java.   Those domains would probably
constitute non-throw-away projects (though some of them should be thrown
away).  There are many other kinds of non-throw-away projects though.

Re: Ada vs C++ vs Java

[dennison]

In article <nobody-1301990909100001@adp8470-1-15.pixi.net>,
  nobody@0.0 (Peter) wrote:
> Personally, I have not encountered any commercial applications or
> operating systems written in Java.   Those domains would probably
> constitute non-throw-away projects (though some of them should be thrown
> away).  There are many other kinds of non-throw-away projects though.
>

That doesn't mean they don't exist. I know of at least one communications
company (Vivyx) that does 90% of their systems development work in Java. I
suspect there are many more out there.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Michael J. Tobler]

Peter wrote:
[snip]
> 
> Personally, I have not encountered any commercial applications or
> operating systems written in Java.   Those domains would probably

Then that tells me you dont read the trade rags
or keep up with various tools in the industry
besides what you use. There are MANY tools written
in pure Java.  Look at Application Servers, or
how about Together/J (UML design tool), etc

You can go here
http://www.cetus-links.org/
or 
http://www.javasoft.com/
to see what people are building in Java.

-- 
<<<<<<<<<<< Blue Skies >>>>>>>>>>>>
<       Michael J. Tobler         >
< remove "no-spam"when replying   >
< mailto:mtobler@no-spam-ibm.net  >
< http://www.webbrew.com/toblermj >
<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>

Re: Ada vs C++ vs Java

[Larry Kilgallen]

In article <369E5BB9.F7F45FAC@no-spam-ibm.net>, "Michael J. Tobler" <mtobler@no-spam-ibm.net> writes:
> Peter wrote:
> [snip]
>> 
>> Personally, I have not encountered any commercial applications or
>> operating systems written in Java.   Those domains would probably
> 
> Then that tells me you dont read the trade rags
> or keep up with various tools in the industry
> besides what you use. There are MANY tools written
> in pure Java.  Look at Application Servers, or
> how about Together/J (UML design tool), etc

Peter did not write "I have not read about".

Peter wrote "Personally, I have not encountered", meaning he himself
coming across it on a computer he worked on or near.

There is a great tendency these days to confuse reading with real
experience.

Larry Kilgallen

Re: Ada vs C++ vs Java

[dewar]

In article <369E5BB9.F7F45FAC@no-spam-ibm.net>,
  "Michael J. Tobler" <mtobler@no-spam-ibm.net> wrote:
> Then that tells me you dont read the trade rags
> or keep up with various tools in the industry
> besides what you use. There are MANY tools written
> in pure Java.  Look at Application Servers, or
> how about Together/J (UML design tool), etc

Actually these kind of lists are not very persuasive in
indicating that a language is being widely used. They can
show that a language has *some* significant use, but it is
hard to get the scale right to know that they are saying
anything about widespread use. For example, Pascal has some
very important and sigtnificant uses (go visit the Borland
page to read about them), but I think few would regard
Pascal as a widely used language.

Similarly, the lists of Ada uses are impressive in
effectively convincing you that Ada has important and
significant use in many domains, but few would regard it
as a language which is in widespread use.

So the question is not whether Java has some significant
use, it is whether it is really challenging the position of
COBOL, C++ and other genuinely widespread languages.

Certainly Java is not about to disappear, just as it is
clear that Ada will not disappear, but whether it can make
it from a niche to be a really major player in the general
application market remains to be seen.

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[robert_dewar]

In article <369E5BB9.F7F45FAC@no-spam-ibm.net>,
  "Michael J. Tobler" <mtobler@no-spam-ibm.net> wrote:
> Then that tells me you dont read the trade rags
> or keep up with various tools in the industry
> besides what you use. There are MANY tools written
> in pure Java.  Look at Application Servers, or
> how about Together/J (UML design tool), etc

Actually these kind of lists are not very persuasive in
indicating that a language is being widely used. They can
show that a language has *some* significant use, but it is
hard to get the scale right to know that they are saying
anything about widespread use. For example, Pascal has some
very important and sigtnificant uses (go visit the Borland
page to read about them), but I think few would regard
Pascal as a widely used language.

Similarly, the lists of Ada uses are impressive in
effectively convincing you that Ada has important and
significant use in many domains, but few would regard it
as a language which is in widespread use.

So the question is not whether Java has some significant
use, it is whether it is really challenging the position of
COBOL, C++ and other genuinely widespread languages.

Certainly Java is not about to disappear, just as it is
clear that Ada will not disappear, but whether it can make
it from a niche to be a really major player in the general
application market remains to be seen.

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Peter Sch�ller]

nobody@0.0 (Peter) writes:

> Personally, I have not encountered any commercial applications or
> operating systems written in Java.

JavaOS, NetBeans Developer, Hotjava, Java web server just to name a
few. A quick search at java.sun.com (they've got some kind of list
there, but I don't remember what it's called) will reveil a lot of
commercial applications written in Java.

In any case, I hope Java *really* suceeds. 

/ Peter Schuller
----------------
E-Mail: scode_ufp@usa.net

Re: Ada vs C++ vs Java

[Tucker Taft]

Leszek Sczaniecki (lsczan@concentric.net) wrote:

: We are about to start a big project, something about 250k lines of code.
: We are going to stick to it for next several years. We would like to
: make an educated choice for the underlying language. This language
: should
: - support object oriented programming
: - support parallel programming
: - lead to easily maintainable code
: - promote safe programming techniques
: - have significant support from commercial vendors (compilers, GUI
: design, testing sw)
: - be available for popular processors (such as 68xxx, PowerPC, etc.)
: - enjoy wealth of existing solutions
: - support "almost real time" execution
: - be suitable for design of embedded systems
: - have existing support for vxworks

: There is a legacy code written in Ada and our customer would prefer Ada
: 95. However, we became seriously concerned that there is not sufficient
: support for Ada in the commercial world. ...

I have attached two notes relating to this issue, the first about
the commercial support for Ada, and the second a marketing piece about 
the kinds of industries which are choosing Ada for their important
software systems.   These flyers are also available on the Ada 
Information Clearinghouse web site (www.adaic.org).

-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA
----------------------------------------------------------------------

            A d a    C o m p i l e r s   a n d   T o o l s

The following is a partial list of Hosts, Targets, and operating systems 
supported by various Ada compiler vendors:

    Hosts:  
       SPARC/Solaris, HP9000/HP-UX, RS6000/AIX, IBM390/MVS,
       Intelx86/Win-NT/9X, SGI/IRIX, Concurrent/PowerMAX, Intelx86/Linux,
       Intelx86/OS/2, PowerMAC/Tenon, VAX/OpenVMS, Alpha/OpenVMS,
       Intelx86/DOS, Alpha/DEC-Unix, Siemens-Nixdorf RM200/SINIX

    Targets: All the above hosts plus:
       PowerPC/VxWorks, PowerPC/Raven, PowerPC/Bare, Intelx86/PharLapETS,
       PowerPC/Integrity, HP7xx/HP-RT, MIPS/VxWorks, RAD6000/VxWorks,
       68K/VxWorks, 68K/OS9, Intelx86/VxWorks, ADI-21020/Bare, i960/HAOS,
       PowerPC/LynxOS, ADI-SHARC/Virtuoso, IBM390/CICS, Nighthawk 6800

The Hosts and Targets list is not complete, as some compilers
are used in-house without being officially validated, while others
are in the process of development.  In particular, there are a 
number of GNAT-derivatives being used for production work for targets
or hosts not listed above.

There are also Ada 95 compilers that generate Java byte codes, as well
as those that generate optimized ISO/ANSI C as their intermediate code,
allowing integration with JVM-based environments, as well as with any existing
ISO/ANSI-C-supportive environment.  In addition, there is the GNAT
compiler supported by Ada Core Technologies, which targets the
GNU "GCC" optimizer and backend.  As with GCC, the GNAT compiler operates 
under the "open source" principle (the GNAT front end is written
in Ada 95 itself).  Given these three integration approaches 
(JVM, ISO/ANSI C, and GCC), plus the existing retargetable
technologies of the other compiler vendors, an Ada 95 capability
is readily available on essentially any platform of interest now
or in the future.


The Ada compiler and tool market is served by a number of software vendors.  

The following vendors provide multiple Ada compilers (those marked with a
"*" are members of the Ada Resource Association -- www.adaresource.org):

    *Ada Core Technologies  (www.gnat.com)
    *Aonix (www.aonix.com)
    *AverStar (formerly Intermetrics)  (www.averstar.com)
    *DDC-I  (www.ddci.com)
    *Green Hills Software  (www.ghs.com)
     Irvine Compiler Corp (www.irvine.com)
    *O. C. Systems (www.ocsystems.com)
    *Rational Software (www.rational.com)
     RR Software (www.rrsoftware.com)
     TLD Systems

There are also companies who just offer compilers for their own
hardware or chips; for example:

    Analog Devices (for the SHARC) (www.analog.com)
    Concurrent (www.ccur.com)
    SGI (www.sgi.com)

There are also a number of tool companies which provide Ada-supportive tools;
for example:

    Ainslie Software (AdaJNI -- www.ainslie-software.com)
    Black & White Software (UIM/Ada -- www.blackwhite.com)
    GrammaTech (Ada-Assured -- www.grammatech.com)
    Integrated Computer Solutions (ICS Ada Xcessories -- www.ics.com)
    IPL (AdaTest -- www.iplbath.com)
    McCabe and Associates (McCabe QA/Test/Reengineer/2000 -- www.mccabe.com)
    Objective Interface Systems (ORBExpress/Ada -- www.ois.com)
    Praxis Critical Systems (SPARK -- www.praxis-cs.co.uk)
    Vector Software (AdaCAST -- www.vectors.com)

A number of the compiler vendors also sell Ada-supportive tools
The Ada compiler and tool market is approximately $100 Million.

Ada training and mentoring services are also available from many
of the above product companies, plus from various other companies 
and independent consultants.

For a sampling of projects that have used Ada successfully, see
http://www.adaic.org/projects/successes.html.
----------------------------------------------------------------------

                       C h o o s e   A d a :

               The Most Trusted Name in Software (tm)


For companies throughout the world, Ada is the programming language of 
choice for all the right reasons.  These companies know that Ada is their
most effective language for building fast, reliable, and adaptable systems,
on time.


                 When your software has to fly...
                         Choose Ada.

Ada is the language of the International Space Station, Boeing jets,
world-wide Air Traffic Control, and the French TGV high-speed train.
Ada's unique combination of efficiency, real-time control, and
built-in safety, make it the choice for high-flying, high-profile, 
high-performance systems that can't afford to fail.

                 When your deadlines are real...
                          Choose Ada.

Ada helps companies throughout the world deliver systems that
meet all their deadlines: coding deadlines, integration deadlines,
delivery deadlines, and real-time processing deadlines.  Ada's excellent 
support for separation of interface and implementation, coupled with very 
strong interface type checking, means that these companies find system 
integration and testing go extraordinarily smoothly and rapidly, and that 
their customers end up extremely satisfied with the delivered system.

                When there is no room for error...
                          Choose Ada.

Systems delivered using Ada have significantly lower error rates.  
This is because the Ada language supports all the most modern and 
effective software engineering techniques, while Ada compilers, right
out of the box, provide more compile-time and run-time consistency 
checking than those for other programming languages.  Ada compilers 
catch errors when they are least expensive to fix, before system 
integration time and deployment.  This is why companies in all kinds
of industries, including Financial Systems, Power Generation, Healthcare, 
Transportation, and Communications, trust Ada for their bet-the-business, 
software-intensive systems.

              When reality is more important than hype...
                          Choose Ada.

If all your programming team needs to do is build eye-candy for your 
new web-site, feel free to dabble with the latest toy language.  But if 
your programming team wants the power and control needed to build
high-performance, ultra-reliable, rapidly evolvable systems,
choose Ada, the language designed for building systems that really matter.

                   Get your priorities right...
                          Choose Ada:
               The Most Trusted Name in Software (tm).
                 
Ada has an active user community (www.acm.org/sigada), newsgroup 
(comp.lang.ada), web-sites (www.adaic.org; www.adahome.com), and 
is taught at colleges and universities throughout the world 
(www.acm.org/sigada/education).  

Ada is supported by a strong vendor community, represented by the Ada 
Resource Association (www.adaresource.org), including Ada Core Technologies 
(www.gnat.com), Aonix (www.aonix.com), AverStar/Intermetrics 
(www.averstar.com), DDC-I (www.ddci.com), Green Hills Software (www.ghs.com), 
OC Systems (www.ocsystems.com), and Rational Software (www.rational.com).

Ada compilers are available for a wide variety of hosts and targets
(www.adaic.org/compilers), and there are Ada compilers that integrate 
directly with Java virtual machines (JVMs) and with ANSI/ISO C compilers, 
providing additional portability and interoperability options.

Choose Ada for your company's next important system, for all the 
right reasons.


* "The Most Trusted Name In Software" is a trademark of the Ada Resource
Association

Re: Ada vs C++ vs Java

[Emil Rojas]

I  just thought I would tag in with the comment that its great to see that Ada is
alive
and well.  I new it was still required in some DoD projects but I had heard tales
if its demise.  I guess tales are never to be believed in this industry.

emil

Re: Ada vs C++ vs Java

[Herman]

Java, C++, C, Ada, Pascal, PL1, PL/M...
it is all Algol to me!

Leszek Sczaniecki wrote:
> 
> We are about to start a big project, something about 250k lines of code.
> We are going to stick to it for next several years. We would like to
> make an educated choice for the underlying language. This language
> should
> - support object oriented programming
> - support parallel programming
> - lead to easily maintainable code
> - promote safe programming techniques
> - have significant support from commercial vendors (compilers, GUI
> design, testing sw)
> - be available for popular processors (such as 68xxx, PowerPC, etc.)
> - enjoy wealth of existing solutions
> - support "almost real time" execution
> - be suitable for design of embedded systems
> - have existing support for vxworks
> 
> There is a legacy code written in Ada and our customer would prefer Ada
> 95. However, we became seriously concerned that there is not sufficient
> support for Ada in the commercial world. Given, that we will be stuck
> with our project for the next several years we would like to choose
> something that still will have adequate support few years down the road.
> Given all that we decided to check C++ and Java. I would appreciate
> greatly any comparisons, comments, hints, pointers to electronic and
> hard copy sources, warnings about traps and pitfalls, etc. that would
> help us thoroughly justify the language choice to our customer.
> 
> -leszek
> 
> PS
> If you are afraid that your response may start a religious war or that
> it is not of interest of your newsgroup please send me e-mail.

Re: Ada vs C++ vs Java

[Marin David Condic]

A good Fortran programmer can write Fortran code no matter what language
you give him. :-)

MDC


Herman wrote:
> 
> Java, C++, C, Ada, Pascal, PL1, PL/M...
> it is all Algol to me!
> 

-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

    "Nobody shot me."

        --  Last words of Frank Gusenberg when asked by police who
            shot him fourteen times with a machine gun in the Saint
            Valentine's Day Massacre.

Re: Ada vs C++ vs Java

[David R. Conrad]

On Wed, 13 Jan 1999 10:37:12 -0500,
 Marin David Condic <condicma@bogon.pwfl.com> wrote:
>A good Fortran programmer can write Fortran code no matter what language
>you give him. :-)

I was employed writing Turbo Pascal in the late eighties, and then on
another project I had to learn COBOL to maintain some accounting code,
and we had a guy who was an old hand at COBOL working with us.  He kept
bugging me to teach him some Pascal, and finally I did.

After he got to know Turbo Pascal somewhat, he said, "Oh, now I understand
why your COBOL code is so unusual -- you're writing Pascal in COBOL!"

I considered it one of the greatest compliments I've ever gotten as a
programmer that some sense of structured programming was coming through,
even when I was writing COBOL.  (Luckily, I haven't had anything to do
with COBOL since then.)

>Herman wrote:
>> Java, C++, C, Ada, Pascal, PL1, PL/M...
>> it is all Algol to me!

-- 
David R. Conrad <drc@adni.net>
This is why I love America -- that any kid can dream "I'm going to get
naked with the President" ... and that dream can actually come true.
What a great country!  -- Michael Moore

Re: Ada vs C++ vs Java

[robert_dewar]

In article <slrn79tbt9.7g4.drc@darwin.adni.net>,
  drc@adni.net (David R. Conrad) wrote:
> After he got to know Turbo Pascal somewhat, he said, "Oh,
> now I understand why your COBOL code is so unusual --
> you're writing Pascal in COBOL!"
>
> I considered it one of the greatest compliments I've ever
> gotten as a programmer that some sense of structured
> programming was coming through, even when I was writing
> COBOL.  (Luckily, I haven't had anything to do with COBOL
> since then.)

No, this is a criticism. I cannot imagine anything more
horrible than importing Pascal style into COBOL. It is of
course perfectly possible to write structured code in COBOL
(as a matter of fact one of my PhD students, Carma McClure,
who is now married to James Martin) wrote her thesis in
this area in the mid 70's.

But proper COBOL style is very different from Pascal style,
because COBOL has much nicer structuring tools for the
procedure division than Pascal. For example in COBOL you
would write:

 PROCESS-BALANCE.
   if Balance is negative then
      perform SEND-BILL
   else
      perform RECORD-CREDIT
   end if.

 SEND-BILL.
   ...

 RECORD-CREDIT.
   ...

This kind of in-the-small top down refinement with nice
names for sections of code makes well written COBOL easy
to read, and by contrast the Algol (and hence Pascal, C,
Ada, C++ etc) style of using nested if's is often much less
clear.

I really miss this ability to define local procedures and
use them easily in languages other than COBOL. Note that in
languages like Pascal, the syntax for simple procedure
definitions is far more verbose than in COBOL (where the
syntactic definition overhead for a procedure is the name
of the procedure and two periods), and worse, you have to
declare the procedure before you use it, exactly wrong for
this kind of called-only-once top-down-refinement approach.

Now it maybe that you don't agree that this is a nice style
and prefer the nested if's of C, but too bad! If you are
writing COBOL (or any other language) part of your job is
to learn the style that is considered standard and
desirable in that language.

Writing code that practioners in the language regard as
"unusual" and judge to be the result of importing
inappropriate foreign paradigms from other languages is
the sign of a poor programmer.

One of the great advantages of COBOL is that people who
know and understand the language well tend to write in a
very uniform style, so that people can easily read one
another's code. If you ever encountered convoluted use of
templates in C++, you will know what I mean by this failing
to be the case in some other languages.

Obviously you never really learned COBOL well, if you did
not understand that importing Pascal style is NOT the right
answer to anything. Consequently, your "Luckily" comment
is not surprising, it is always frustrating to program in
a language you do not understand!

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Bob Munck]

On Fri, 15 Jan 1999 16:07:31 GMT, robert_dewar@my-dejanews.com wrote:

>.... I cannot imagine anything more
>horrible than importing Pascal style into COBOL. 

I can; I've seen it.

A couple of decades ago I did the analysis and design of a
budget and funds-tracking system for a government agency.
They gave the implementation contract to one of their
captive contractors, a group that mostly did highly
sophisticated supercomputer programming in FORTRAN II.
They proceeded to code the accounting system in a couple
of hundred thousand lines of numerical-analysis style
FORTRAN II.  You cannot imagine what it looked like.

The ultimate flaw was the fact that the agency's budget was
in the billion dollar range.  The main data type, an amount
of money (in pennies) could therefore exceed the capacity
of the largest integer that the machine supported.  To handle
this, they quite naturally used floating point. (!!)

After a certain amount of excitement, we (SofTech) were given
back the project, and proceeded to write the system in COBOL.
Last I heard it was still in use, though I hope they've made it
Y2K compliant by now.

Bob Munck
Mill Creek Systems LC

Re: Ada vs C++ vs Java

[Michael J. Tobler]

In article <77np3q$e6h$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com 
says...
[snip]
> (as a matter of fact one of my PhD students, Carma McClure,
> who is now married to James Martin) wrote her thesis in
> this area in the mid 70's.

My understanding is that you are a professor. (Correct me if I'm rwong :)

> But proper COBOL style is very different from Pascal style,
[snip]
> This kind of in-the-small top down refinement with nice
> names for sections of code makes well written COBOL easy
> to read,

"Nice names" and well-written programs are not reserved for COBOL 
programs. You can create a mess in any language. COBOL doesnt force you to 
write "well-written" applications. Or more maintainable code.

> and by contrast the Algol (and hence Pascal, C,
> Ada, C++ etc) style of using nested if's is often much less
> clear.

That's a matter of style. If you "nest" more than three levels
of "if-else" statements, then your logic needs to be re-investigated. I 
find it odd that you lump Algol, Pascal, C, Ada, C++ into the same group. 
Why is that?

> I really miss this ability to define local procedures and
> use them easily in languages other than COBOL. Note that in
> languages like Pascal, the syntax for simple procedure
> definitions is far more verbose than in COBOL (where the
> syntactic definition overhead for a procedure is the name
> of the procedure and two periods), and worse, you have to
> declare the procedure before you use it, exactly wrong for
> this kind of called-only-once top-down-refinement approach.

What it all boils down to is what you're comfortable with. You should use 
the language that best fits the project or problem at hand. I work on 
projects that may require three or four implementation languages to arrive 
at the finished product.  Of course, in the academic world, you dont have 
to concern yourself with that noise :)

> Now it maybe that you don't agree that this is a nice style
> and prefer the nested if's of C, but too bad! If you are
> writing COBOL (or any other language) part of your job is
> to learn the style that is considered standard and
> desirable in that language.

True, but real programs dont hover around the structure of
nested if-else's - what's the hang up on if-else's???

> Writing code that practioners in the language regard as
> "unusual" and judge to be the result of importing
> inappropriate foreign paradigms from other languages is
> the sign of a poor programmer.

Not necessarily...it means that the programmer is unfamiliar with the 
territory and doesnt have the proper guidance to properly implement a 
solution. That usually comes from "one-way-street" teachers and managers.

> One of the great advantages of COBOL is that people who
> know and understand the language well tend to write in a
> very uniform style, so that people can easily read one
> another's code. If you ever encountered convoluted use of
> templates in C++, you will know what I mean by this failing
> to be the case in some other languages.

Believe me, I have seen "convoluted" COBOL, it is not restricted to the 
"other" languages you list.

> Obviously you never really learned COBOL well, if you did
> not understand that importing Pascal style is NOT the right
> answer to anything. Consequently, your "Luckily" comment
> is not surprising, it is always frustrating to program in
> a language you do not understand!

Obviously, you never really learned C++ or C or other languages you list 
to properly assess them. Better yet, you dont understand that different 
languages require different paradigms and thought processes. You can't 
possibly compare COBOL to C++ or Java or Algol or Ada or Modula-3. I 
understand what you're saying: that you cant apply Pascal programming 
techniques to COBOL. At the same time, you cant put COBOL in the trophy 
case and say other languages are inadequate.

> 
> Robert Dewar

-- 
<<<<<<<<<<<<<<<<  Blue Skies  >>>>>>>>>>>>>>>>
< Michael J. Tobler: mtobler@no-spam-ibm.net >
<   **remove "no-spam-" when replying**      >
<     http://www.webbrew.com/toblermj        >
< MJTobler:Instant Messenger;  28038932:ICQ  >
<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>

Re: Ada vs C++ vs Java

[Al Christians]

"Michael J. Tobler" wrote:
> 
> programs. You can create a mess in any language. COBOL doesnt force 
> you to write "well-written" applications. Or more maintainable code.
> 

But by some surprising coincidence, a certain COBOL compiler did
go to some lengths, perhaps unintentionally, to promote the coding
style that Robert Dewar has recently advocated in this thread.  It
would mis-compile code if the IF-THEN-ELSE structures were nested 
too deeply.

Al

Re: Ada vs C++ vs Java

[Michael J. Tobler]

In article <36A045FF.EBA4370@easystreet.com>, achrist@easystreet.com 
says...
> 
> "Michael J. Tobler" wrote:
> > 
> > programs. You can create a mess in any language. COBOL doesnt force 
> > you to write "well-written" applications. Or more maintainable code.
> 
> But by some surprising coincidence, a certain COBOL compiler did
> go to some lengths, perhaps unintentionally, to promote the coding
> style that Robert Dewar has recently advocated in this thread.  It
> would mis-compile code if the IF-THEN-ELSE structures were nested 
> too deeply.

"Mis-compile"?  Or didnt allow it?  If the compiler didnt accept multiple 
if-else construct, then the compiler writer wasnt doing thier job - they 
are making the assumption that a programmer "wont do this". This, in my 
book, is unacceptable.

-- 
<<<<<<<<<<<<<<<<  Blue Skies  >>>>>>>>>>>>>>>>
< Michael J. Tobler: mtobler@no-spam-ibm.net >
<   **remove "no-spam-" when replying**      >
<     http://www.webbrew.com/toblermj        >
< MJTobler:Instant Messenger;  28038932:ICQ  >
<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>

Re: Ada vs C++ vs Java

[robert_dewar]

In article <MPG.110a5f23b94a3ea798a0cd@news3.ibm.net>,
  mtobler@no-spam-ibm.net (Michael J. Tobler) wrote:

> "Mis-compile"?  Or didnt allow it?  If the compiler didnt
> accept multiple if-else construct, then the compiler
> writer wasnt doing thier job - they are making the
> assumption that a programmer "wont do this". This, in my
> book, is unacceptable.

Well yes, I think everyone agrees with this in practice,
and I certainly interpreted the post to mean what it said
(miscompile).

However, it is worth noting that almost all real compilers
do have capacity limits on various things, and I suppose it
is not inconceivable that a COBOL compiler would have a
smaller capacity limit on nested if's -- certainly the
judgment on where to set capacity limits is based on
typical usage patterns.

Note that Realia COBOL is one of the few compilers (the
only one I know of) that have NO limits of ANY KIND. If
you have enough disk space, then Realia COBOL will compile
any program.

Note that typically COBOL compilers have much *larger*
limits on the maximum size of programs. Whereas typical
C style is to have many small files, single files of
100,000 or more lines are not unknown in the COBOL world
(not very good practice certainly, but a compiler writer
is in the business of catering to actual practice, not
idealized practice, as Michael notes.

Of course there is NEVER any excuse for miscompiling a
construct that the compiler accepts!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[robert_dewar]

In article <36A045FF.EBA4370@easystreet.com>,
  Al Christians <achrist@easystreet.com> wrote:
>
>
> But by some surprising coincidence, a certain COBOL
> compiler did go to some lengths, perhaps unintentionally,
> to promote the coding style that Robert Dewar has
> recently advocated in this thread. It would mis-compile
> code if the IF-THEN-ELSE structures were nested too
> deeply.

That is not at ALL surprising. As anyone knows in the
compiler field, compilers are very complex programs that
typically have a lot of bugs initially. These bugs tend
to get ironed out by experience with actual user programs.
Since deeply nested if's are very seldom used in COBOL
(this is not just a style that I advocate, it is pretty
much universal practice to avoid deeply nested if's in
COBOL), it is not at all surprising that there should be
bugs there.

Indeed unusual code, whether generated by students who do
not know what they are doing, programs that generate code
automatically, or incompetent programmers importing
atypical coding styles, is most likely to break compilers,
another reason for sticking to very standard style!

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[robert_dewar]

In article <MPG.1109dc294de4c73d98a0ae@news3.ibm.net>,
  mtobler@no-spam-ibm.net (Michael J. Tobler) wrote:
> In article <77np3q$e6h$1@nnrp1.dejanews.com>,
> robert_dewar@my-dejanews.com
> says...
> [snip]
> > (as a matter of fact one of my PhD students, Carma
> > McClure,
> > who is now married to James Martin) wrote her thesis in
> > this area in the mid 70's.
>
> My understanding is that you are a professor. (Correct me
> if I'm rwong :)

Half right and half wrong :-) I am a professor, but I also
am president of a software company (that specializes in
Ada), and I have written well over a million lines of
delivered commercial code in many languages.
>
> > But proper COBOL style is very different from Pascal
> > style,
> > This kind of in-the-small top down refinement with nice
> > names for sections of code makes well written COBOL
> > easy
> > to read,
>
> "Nice names" and well-written programs are not reserved
> for COBOL  programs. You can create a mess in any
> language. COBOL doesnt force you to
> write "well-written" applications. Or more maintainable
> code.

You make a general apple pie comment, but you seem to have
missed the very specific technical comment I was making
regarding giving names to small sections of code, something
that is typical of COBOL style, and not of Pascal style.

> > and by contrast the Algol (and hence Pascal, C,
> > Ada, C++ etc) style of using nested if's is often much
> > less clear.
>
> That's a matter of style. If you "nest" more than three
> levels of "if-else" statements, then your logic needs to
> be re-investigated. I  find it odd that you lump Algol,
> Pascal, C, Ada, C++ into the same group.  Why is that?

Because they are all derived more or less directly from
Algol-60 in this respect, and all have much the same feel
with respect to nested if's. Your (very reasonable for
these languages) rule of not nesting more than three levels
pretty much applies uniformly to all these languages.

The point is that in COBOL, even nesting three levels would
normally be considered very poor style. That's because the
style of local refinement that it allows means that, unlike
the case in say C, it is convenient to avoid *any* if
nesting at all, and many COBOL programmers do avoid nesting
(it is not uncommon for coding standards to forbid it). If
you tried to forbid nested if's in C, you would create a
horrible mess.

> > I really miss this ability to define local procedures
> > and use them easily in languages other than COBOL. Note
> > that in languages like Pascal, the syntax for simple
> > procedure definitions is far more verbose than in COBOL
> > (where the syntactic definition overhead for a
> > procedure is the name of the procedure and two
> > periods), and worse, you have to
> > declare the procedure before you use it, exactly wrong
> > for this kind of called-only-once top-down-refinement
> > approach.
>
> What it all boils down to is what you're comfortable
> with. You should use the language that best fits the
> project or problem at hand.

Again, an applie pie statement that misses the very
specific technical note I was making with regard to local
refinements. Obviously no one chooses C vs COBOL on this
issue, but such a choice would be made on all sorts of
grounds.


> I work on projects that may require three or four
> implementation languages to arrive  at the finished
> product. Of course, in the academic world, you dont have
> to concern yourself with that noise :)

Well as I noted above, my very extensive programming
experience is hardly of the academic variety. Yes, most
large projects do require mixed languages. To make another
technical point here, it is quite suprising that of the
commonly used languages, only Ada makes an effort to
accomodate this need in a portable manner. Someone once
asked on the comp.lang.cobol group how to interface COBOL
to C. The answer is that there is *no* portable way of
doing this, just as there is no portable way of interfacing
Fortran to C (here I am talking about direct interfacing,
not interfacing via something like CORBA, or via ASCII
files). I noted that the only portable way of interfacing
from COBOL to C is to use Ada as an intermediary, since Ada
does define COBOL to Ada interfacing and C to Ada
interfacing (in both directions).

Certainly mixed-language programming is important, and of
course many of my large projects have involved that. The
Realia COBOL compiler [now sold by Computer Associates]
(for which I wrote the backend, optimizer, debugger and
run-time library) was a mixture of COBOL and 8086
assembler.

The GNAT compiler (www.gnat.com) that my company (Ada Core
Technologies) supports and maintains is an example of a
large Ada and C program (Ada for the front end, a mixture
of Ada and C for the front-back-end interface, and C for
the backend).

So interfacing between languages and mixed-language
programming is certainly familiar to me, although again
I do not see what it has to do with the very specific point
I was making (which was a reaction to someone thinking it
was a good idea to import Pascal structuring techniques
into COBOL).

> > Now it maybe that you don't agree that this is a nice
> > style and prefer the nested if's of C, but too bad! If
> > you are writing COBOL (or any other language) part of
> > your job is to learn the style that is considered
> > standard and desirable in that language.
>
> True, but real programs dont hover around the structure
> of nested if-else's - what's the hang up on if-else's???

"True" to the point I was making -- fine, that's the only
thesis I was arguing!

As for nested if-else's, since when is it a "hang up" in
the field of programming language design to take a close
look at one particular feature which is instructive. You
seem to be taking my post as a general treatise on the
differences between Pascal and COBOL. Of course it is
nothing of the kind. I was just giving one interesting
illustrative examples of the way in which COBOL style is
very different from Pascal. There are of course (as you
must know if you are an experienced COBOL programmer)
dozens of other examples I could have chosen.

> > Writing code that practioners in the language regard as
> > "unusual" and judge to be the result of importing
> > inappropriate foreign paradigms from other languages is
> > the sign of a poor programmer.
>
> Not necessarily...it means that the programmer is
> unfamiliar with the  territory and doesnt have the proper
> guidance to properly implement a  solution. That usually
> comes from "one-way-street" teachers and managers.

Sorry, but for me, unfamiliarity and incorrect training
make a poor programmer. If I hire a plumber and he is
unfamiliar with what he is doing, and makes a mess as a
result, he is a poor plumber. Saying someone is a poor
programmer does not mean they are a bad person, or lack
intelligence. It just means they lack competence in
programming. This can indeed be the result of poor
training.

> > One of the great advantages of COBOL is that people who
> > know and understand the language well tend to write in
> > a very uniform style, so that people can easily read
> > one another's code. If you ever encountered convoluted
> > use of templates in C++, you will know what I mean by
> > this failing to be the case in some other languages.

> Believe me, I have seen "convoluted" COBOL, it is not
> restricted to the "other" languages you list.

Again, a general applie pie statement! Yes of course, but
if you are really familiar with the typical worlds of
commercial C++ and COBOL programming as I am, then I am
surprised you do not agree there is a difference here.
First COBOL is much more prescriptive than C++ when it
comes to, e.g. layout, but it's more than that. There is
typically one way of doing things in COBOL, where there
may be many in C++, and in practice, COBOL style tends to
be much more uniform.>

> > Obviously you never really learned COBOL well, if you
> > did not understand that importing Pascal style is NOT
> > the right answer to anything. Consequently, your
> > "Luckily" comment is not surprising, it is always
> > frustrating to program in a language you do not
> > understand!

> Obviously, you never really learned C++ or C or other
> languages you list to properly assess them. Better yet,
> you dont understand that different languages require
> different paradigms and thought processes. You can't
> possibly compare COBOL to C++ or Java or Algol or Ada or
> Modula-3.h

Actually people compare languages all the time, this thread
is an example. I actually know C++ and C well, and indeed I
know many languages well and have used them in large
commercial applications I have delivered. There are many
comparison points that are of interest.

Yes, of course it is the case that you think differently
in different languages. That actually, if you read a little
more carefully what I wrote, was the point! I was
criticizing someone who felt that it was "the greatest
complement" to have imported foreign Pascal thinking into
COBOL. Such inappropriate importing of foreign style is
a horribly frequent form of poor programming (a recent
very common form of this is importing C style into C++,
particularly easy to do, since C++ is more or less a
superset -- the result is all sorts of junk low level
thinking which is inappropriate in a C++ context).

But if you are in the language design field as I am (I was
chair of the Algol-68 maintenance committee for many years,
I was one of the authors of the Ada 9x design document, and
a member of the review team for Ada 9x, and have also
played a major role in the development of IITRAN and SETL,
as well as designing the SPITBOL dialect of SNOBOL4), then
you definitely look for interesting points in various
languages to understand if they are applicable in a design
effort for some particular language.

For the particular, very narrow, very specific, point that
I was making in my post, which I think you have missed by
interpreting it as some general statement, I think the
local refinement notation of COBOL is quite interesting and
could be applied to other languages. Indeed it has been,
see Koster's CDL language, and the original design of
SETL-1. See also Lambert Meerten's paper for the
Novosibirsk meeting of IFIP WG2.1 that discusses this
specific point, and the resulting design of the ABC
language.

> I understand what you're saying: that you cant apply
> Pascal programming techniques to COBOL.

Yup, that's the one point I was making!!!

> At the same time, you cant put COBOL in the trophy
> case and say other languages are inadequate.

No one did that. I merely commented on one tiny little
feature of COBOL that I find convenient and that I miss
in other languages. There are of course many giant
features, like recursion, that I miss in COBOL, compared
to other languages! No trophy cases around here, although
I tend to find that people in the programming language
field know far too little about COBOL, and tend to dismiss
it without knowing much about it, which is a pity, since it
has a number of interesting ideas, some of which can be
imported usefully into other languages. For an example of
such importation, see the Information Systems Annex of
Ada 95, which I helped to design.

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

COBOL/Top-Down prog'g (was: Ada vs C++ vs Java)

[Nick Roberts]

Consider the following Ada equivalent of Robert's COBOL example:


procedure Send_Bill;
procedure Record_Credit;

...

procedure Process_Balance is
   ...
begin
   ...
   if Balance < 0 then
      Send_Bill;
   else
      Record_Credit;
   end if;
   ...
end Process_Balance;

...

procedure Send_Bill is
   ...
begin
   ...
end Send_Bill;

procedure Record_Credit is
   ...
begin
   ...
end Record_Credit;


Hopefully this illustrates Robert's point that declaring lots of procedures
in Ada has more code overhead. But, it also illustrates that the lower-level
(more 'refined') code can be placed after the higher level that refers to
it: with the catch of having to include forward declarations.

I hope this example also shows what a really clear way of programming this
'stepwise refinement' can be. Personally, I would recommend this as a good
style of programming in both Ada and COBOL, in most circumstances. (Of
course, like everything in life, you can overdo it!)

Consider the following fragment of Ada code


   if Balance < 0 then
      if Alternative_Credit + Balance < 0 then
         if Husband.Sister.Uncle.Niece not in Family.Friends then
            if Day = Tuesday then
               if Mood = Really_Bad then
                  Send_Stinking_Credit_Letter;
               else
                  Send_Normal_Credit_Letter;
               end if;
            else
               Schedule_Credit_Letter;
            end if;
         else
            Slip_In_A_Loan_On_The_Quiet((100.00-Balance);
         end if;
      else
         Send_Warning_Letter;
         Schedule_Emergency_Loan(-Balance);
      end if;
   else
      Record_Credit(Balance);
   end if;


This is terrible spaghetti code. And not a 'goto' in sight! Now consider a
COBOL 77 equivalent:


PROCESS-BALANCE.
    if BALANCE is positive, perform POSITIVE-BALANCE.
    if BALANCE is negative, perform NEGATIVE-BALANCE.
    note if BALANCE is zero, no action taken.

POSITIVE-BALANCE.
    move BALANCE to CREDIT-AMOUNT.
    perform RECORD-CREDIT.

NEGATIVE-BALANCE.
    subtract BALANCE from 0 giving DEFICIT.
    if CREDIT-AVAILABLE is less than DEFICIT,
        perform INSUFFICIENT-CREDIT,
        else perform ENOUGH-CREDIT.

INSUFFICIENT-CREDIT.
    if STATUS of NIECE of UNCLE of SISTER of HUSBAND = 'FRIEND',
        perform FRIENDLY-LOAN,
        else perform NASTY-LETTER-TIME.

FRIENDLY-LOAN.
    add 100 to DEFICIT giving LOAN-AMOUNT.
    perform SNEAK-A-QUICK-LOAN-WHILE-NOBODY-LOOKING.

NASTY-LETTER-TIME.
    if MOOD = 'VBAD',
        move 'BOTH LEGS' to WHICH-BONE,
        else move 'A FINGER ' to WHICH-BONE.
    move DEFICIT to LETTER-AMOUNT.
    if DAY = 'TUE', perform NASTY-LETTER-TUESDAY,
        else perform NASTY-LETTER-NON-TUESDAY.

NASTY-LETTER-TUESDAY.
    perform SEND-NASTY-LETTER.

NASTY-LETTER-NON-TUESDAY.
    perform SCHEDULE-NASTY-LETTER.

ENOUGH-CREDIT.
    move DEFICIT to LOAN-AMOUNT.
    perform ARRANGE-EMERGENCY-LOAN.
    perform SEND-WARNING-LETTER.


I think this example makes two things stand out: the Ada example is
obviously more compact, but the COBOL, with its many self-documenting labels
(and extra variables), is much more readable code. You can imagine an Ada
equivalent derived from the above COBOL, and you can also image a possible C
version of the original Ada nested 'if's, more compact still, and even less
readable.

I hope I have gone a little way towards enlightening those of you who may
have scoffed at Robert's assertion that writing COBOL in a 'COBOLish' manner
is better than trying to write COBOL in 'Pascalese', and that COBOL has some
better features. There are definitely some advantages to the COBOL
language - when the code is written well, and in COBOL's native style - over
other (supposedly more advanced) languages. There are also, without doubt,
problems: having to pass parameters in global variables; the lack of a
(visual) 'stopper' at the end of a procedure; the lack of structured
constructs (a problem until COBOL 90). The 'ALTER' verb was a total classic.
Nobody ever used it, fortunately (did they?).

I think the fact that Pascal, Ada, C, and other block-structured languages
allow a mixture of styles - nesting structures directly, and breaking code
down into named constituent parts (functions/procedures) - means that the
programmer is given the ability to choose a good compromise between the
compactness of one style and the clarity of the other. As ever, it is up to
the skill of the programmer to actually choose a good compromise.

Finally, consider a one-line C declaration for the factorial function:


int fact(int i) { if (i < 0) halt(9) else return i < 2? 1 : i *
fact(i-1); };


C can be a very neat language, sometimes.

-------------------------------------------
Nick Roberts
-------------------------------------------

robert_dewar@my-dejanews.com wrote in message
<77np3q$e6h$1@nnrp1.dejanews.com>...
[about COBOL style of coding]

Re: COBOL/Top-Down prog'g (was: Ada vs C++ vs Java)

[robert_dewar]

In article <78i6m0$505$2@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> Consider the following Ada equivalent of Robert's COBOL
> example:

Thankyou for your very clear and extended description of
what I was trying to say (in a probably over-cryptic
manner :-)

Robert

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Patrick Wibbeler]

Or Her.

Marin David Condic wrote in message <369CBDA8.D3673C68@pwfl.com>...
>A good Fortran programmer can write Fortran code no matter what language
>you give him. :-)
.

Re: Ada vs C++ vs Java

[Marin David Condic]

I guess I never mastered the art of genderless English ;-) In future
posts of mine, where you see the word "he/him" please substitute
"he/she/them/it" as you consider appropriate. And if I ever warn you
that there is a "man eating tiger" outside, please do not assume that it
is safe for women and children to leave the building. :-)

MDC

Patrick Wibbeler wrote:
> 
> Or Her.
> 
> Marin David Condic wrote in message <369CBDA8.D3673C68@pwfl.com>...
> >A good Fortran programmer can write Fortran code no matter what language
> >you give him. :-)
> .

-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

    "Airplanes are interesting toys but of no military value."

        --  Marechal Ferdinand Foch, Professor of Strategy,
            Ecole Superieure de Guerre.

Re: Ada vs C++ vs Java

[Peter Amey]

Marin David Condic wrote:
> 
> I guess I never mastered the art of genderless English ;-) In future
> posts of mine, where you see the word "he/him" please substitute
> "he/she/them/it" as you consider appropriate. And if I ever warn you
> that there is a "man eating tiger" outside, please do not assume that it
> is safe for women and children to leave the building. :-)

If you told me there was a "man eating tiger" outside I would go and ask
him if it tasted nice.  A "man-eating tiger" is a much more dangerous
animal :-)

Sorry

Peter

-- 
---------------------------------------------------------------------------   
      __         Peter Amey, Product Manager
        )                    Praxis Critical Systems Ltd
       /                     20, Manvers Street, Bath, BA1 1PX
      / 0        Tel: +44 (0)1225 466991
     (_/         Fax: +44 (0)1225 469006
                 http://www.praxis-cs.co.uk/

--------------------------------------------------------------------------

Re: Ada vs C++ vs Java

[P.S. Norby]

Marin David Condic wrote:
> 
> I guess I never mastered the art of genderless English ;-) In future
> posts of mine, where you see the word "he/him" please substitute
> "he/she/them/it" as you consider appropriate. And if I ever warn you
> that there is a "man eating tiger" outside, please do not assume that it
> is safe for women and children to leave the building. :-)

Tell that man to quit eating tigers... they are an endangered species!

-- 
P.S. Norby

"No excuses.  No embarrassment.  No apologies...
 Ada -- the most trusted and powerful programming language
 on earth, or in space." -- S. Tucker Taft
 
\\\    \\\    \\\    \\\    \\\    \\\    \\\    \\\    \\\ 
( :)   ( :)   ( :)   ( :)   ( :)   ( :)   ( :)   ( :)   ( :)
///    ///    ///    ///    ///    ///    ///    ///    /// 
(Speaking only for myself)

Re: Ada vs C++ vs Java

[Ken]

Patrick Wibbeler wrote:
> 
> Or Her.
> 

 Like there isn't already too much political correctness in the world.
Besides, most female programmers I know would choose a more up to date
language than Fortran, like C, C++, or Java, depending on the situation
they are programming in.

Re: Ada vs C++ vs Java

[Scott Johnson]

Ken wrote:
> 
> Patrick Wibbeler wrote:
> >
> > Or Her.
> >
> 
>  Like there isn't already too much political correctness in the world.
> Besides, most female programmers I know would choose a more up to date
> language than Fortran, like C, C++, or Java, depending on the situation
> they are programming in.

What's wrong with Fortran?

If you are writing a control system, or a UI, or an OS kernel,
the answer of course is "plenty".

If you are writing code for number-crunching, though, Fortran
(or FORTRAN for the purists who insist that the current version
of the language is an abomination--an argument I will avoid) is still
a great language.  Its lack of aliasing makes it VERY easy to
parallelize, and allows many optimizations which are unsafe in C.
(Though C9X may change the latter situation...)

Plus, the numerics libraries available for FORTRAN are quite powerful.

Scott

Re: Ada vs C++ vs Java

[Robert Garskof]

Patrick Wibbeler wrote:

> Or Her.
>
> Marin David Condic wrote in message <369CBDA8.D3673C68@pwfl.com>...
> >A good Fortran programmer can write Fortran code no matter what language
> >you give him. :-)
> .

him / her = hes
she / he = se

Problem solved.



--
/**
 * Robert Garskof - Software Developer
 * Southern New England Telephone (SNET)
 * E-Mail   : rgarskof@snet.net
 * Web Page : http://www.snet.com
 */

Re: Ada vs C++ vs Java

[Jay O'Connor]

Robert Garskof wrote:
> 
> Patrick Wibbeler wrote:
> 
> > Or Her.
> >
> > Marin David Condic wrote in message <369CBDA8.D3673C68@pwfl.com>...
> > >A good Fortran programmer can write Fortran code no matter what language
> > >you give him. :-)
> > .
> 
> him / her = hes
> she / he = se
> 
> Problem solved.

No...


him / her = im/er

she / he = s/1 = s


:-)

> 
> --
> /**
>  * Robert Garskof - Software Developer
>  * Southern New England Telephone (SNET)
>  * E-Mail   : rgarskof@snet.net
>  * Web Page : http://www.snet.com
>  */


Take care
Jay O'Connor
joconnor@roadrunner.com

Re: Ada vs C++ vs Java

[Marin David Condic]

Jay O'Connor wrote:
> 
> Robert Garskof wrote:
> >
> > Patrick Wibbeler wrote:
> >
> > > Or Her.

> >
> > him / her = hes
> > she / he = se
> >
> > Problem solved.
> 
> No...
> 
> him / her = im/er
> 
> she / he = s/1 = s
> 
> :-)
> 
All of this PC, genderless English is a ludicrous affectation, up with
which, I will not put! :-)

I guess I'll never pass that Manditory Diversity Training class the
company keeps sending me to... :-)

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

    "Airplanes are interesting toys but of no military value."

        --  Marechal Ferdinand Foch, Professor of Strategy,
            Ecole Superieure de Guerre.

Re: Ada vs C++ vs Java

[Joshua fit de wall]

On Thu, 28 Jan 1999 12:45:27 -0500, Marin David Condic
<condicma@bogon.pwfl.com> wrote:

>All of this PC, genderless English is a ludicrous affectation, up with
>which, I will not put! :-)
>
>MDC

Perhaps it's time to abandon this Darwinian hangover of spoken
language; it just hasn't worked out.

Any society that can reasonably call itself advanced would communicate
via cat-juggling and kitty semaphores.

Re: Ada vs C++ vs Java

[Herman]

Just to add to the confusion:

In Hebrew, she is he and me is who...
(ma ze?)

have fun,

Herman

Joshua fit de wall wrote:
> 
> On Thu, 28 Jan 1999 12:45:27 -0500, Marin David Condic
> <condicma@bogon.pwfl.com> wrote:
> 
> >All of this PC, genderless English is a ludicrous affectation, up with
> >which, I will not put! :-)
> >
> >MDC
> 
> Perhaps it's time to abandon this Darwinian hangover of spoken
> language; it just hasn't worked out.
> 
> Any society that can reasonably call itself advanced would communicate
> via cat-juggling and kitty semaphores.

Re: Ada vs C++ vs Java

[Ruth Ivimey-Cook]

In article <36B0A237.EDAB57DE@pwfl.com>, condicma@bogon.pwfl.com says...
> Jay O'Connor wrote:
> > 
> > > him / her = hes
> > > she / he = se
> > >
> > > Problem solved.
> > 
> > No...
> > 
> > him / her = im/er
> > 
> > she / he = s/1 = s
> > 

I prefer the solution used by several large companies: alternate using he 
and she, or Jack and Jill if using names, for each significant chunk 
(chapter, paragraph -- whatever workd). It seems odd at first but it 
reads quite well.

I do get irritated by books that use male names thougout, though.

Ruth

-- 

Ruth Ivimey-Cook
Cambridge, UK

Re: him/her: was: Ada vs C++ vs Java

[robert_dewar]

I always groan when I see mail heavily cross-posted to
comp.lang.ada and other language groups, because the
other groups seem even worse than cla in terms of
newbies who are obvivious to what they are doing.

This thread on how to deal with the s/he situation has
been massively cross-posted to:

comp.lang.ada,
comp.lang.c++,
comp.vxworks,
comp.lang.java,
comp.java.advocacy,
comp.realtime,
comp.arch.embedded,
comp.object,
comp.lang.java.programmer

I would bet that most of the posters don't even know what
cross-posting *is*, let alone bothered to check. Certainly
they did not bother to trim groups.

If you cannot stop yourself following up irrelevant
threads, then at the very least change the subject line
so that

(a) those following the relevant thread do not have to put
up with irrelevant nonsense.

(b) people can easily kill the subthread and its followups

Please don't pollute technical newsgroups with
non-technical irrelevant nonsense.

(note that I am not saying the material here is nonsense in
general, perhaps there is a group where it is relevant, but
it is irrelevant nonsense in technical language groups!)


In article <MPG.111e767d86fa801a9896b5@sharra.demon.co.uk>,
  ruthc@sharra.demove.demon.co.uk wrote:
> In article <36B0A237.EDAB57DE@pwfl.com>,
condicma@bogon.pwfl.com says...
> > Jay O'Connor wrote:
> > >
> > > > him / her = hes
> > > > she / he = se
> > > >
> > > > Problem solved.
> > >
> > > No...
> > >
> > > him / her = im/er
> > >
> > > she / he = s/1 = s
> > >
>
> I prefer the solution used by several large companies:
alternate using he
> and she, or Jack and Jill if using names, for each
significant chunk
> (chapter, paragraph -- whatever workd). It seems odd at
first but it
> reads quite well.
>
> I do get irritated by books that use male names thougout,
though.
>
> Ruth
>
> --
>
> Ruth Ivimey-Cook
> Cambridge, UK
>

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Peter Amey]

Leszek Sczaniecki wrote:
> 
[snip]
> There is a legacy code written in Ada and our customer would prefer Ada
> 95. However, we became seriously concerned that there is not sufficient
> support for Ada in the commercial world. Given, that we will be stuck
> with our project for the next several years we would like to choose
> something that still will have adequate support few years down the road.
> Given all that we decided to check C++ and Java. I would appreciate
> greatly any comparisons, comments, hints, pointers to electronic and
> hard copy sources, warnings about traps and pitfalls, etc. that would
> help us thoroughly justify the language choice to our customer.

I would like to suggest that the long life of your project is a reason
_for_ choosing Ada rather than a reason to avoid it.  Ada has proved
very stable even with introduction of Ada 95.  Much of your legacy code
will compile unchanged and you can "objectify" it as you need to and as
you go along.  An Ada prgoram written 15 years ago would still be
maintainable, perhaps even unchanged, today.

More commercially-driven languages by contrast change and mutate much
faster.  If a supplier had chosen the commercial or fashionable language
of choice that same 15 years ago then maintenance and enhancement would
have been much harder - perhaps even involving a complete rewrite.  Even
a change of C++ or Java compiler vendor might create significant amounts
of work.  

Peter

-- 
---------------------------------------------------------------------------   
      __         Peter Amey, Product Manager
        )                    Praxis Critical Systems Ltd
       /                     20, Manvers Street, Bath, BA1 1PX
      / 0        Tel: +44 (0)1225 466991
     (_/         Fax: +44 (0)1225 469006
                 http://www.praxis-cs.co.uk/

--------------------------------------------------------------------------

Re: Ada vs C++ vs Java

[Marin David Condic]

A very good point. When Ada first hit the market in 1983, the popular
languages were a multitude of C dialects, Fortran, Cobol, and maybe some
Pascal. Here we are today where the hot languages are C++, Java and
maybe some others. But all that Ada83 code will still compile today with
minimal fuss even thought processors and operating systems have changed
dramatically. That and the fact that Ada was specifically designed for
very large, very long-lived projects and you've got some pretty solid
reasons why this should be the choice for projects which aren't into
building throw away code.

MDC

Peter Amey wrote:
> 
<snip>
> 
> More commercially-driven languages by contrast change and mutate much
> faster.  If a supplier had chosen the commercial or fashionable language
> of choice that same 15 years ago then maintenance and enhancement would
> have been much harder - perhaps even involving a complete rewrite.  Even
> a change of C++ or Java compiler vendor might create significant amounts
> of work.
> 
<snip>

-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

    "Nobody shot me."

        --  Last words of Frank Gusenberg when asked by police who
            shot him fourteen times with a machine gun in the Saint
            Valentine's Day Massacre.

Re: Ada vs C++ vs Java

[Chris Gray]

On Wed, 13 Jan 1999, Marin David Condic wrote:

> A very good point. When Ada first hit the market in 1983, the popular
> languages were a multitude of C dialects, Fortran, Cobol, and maybe some
> Pascal. 

Don't forget CORAL-66 ...

-- 

  Eur. Ing. Chris Gray MBCS C. Eng.       chris.gray@smartmove.be

Re: Ada vs C++ vs Java

[Tom Maier]

Chris Gray <chris@smartmove.be> wrote:

>On Wed, 13 Jan 1999, Marin David Condic wrote:
>
>> A very good point. When Ada first hit the market in 1983, the popular
>> languages were a multitude of C dialects, Fortran, Cobol, and maybe some
>> Pascal. 
>
>Don't forget CORAL-66 ...
>

...and PLM.

Tom

Re: Ada vs C++ vs Java

[Brent A Ellingson]

Tom Maier (sminstruments@mindspring.com) wrote:
: Chris Gray <chris@smartmove.be> wrote:

: >On Wed, 13 Jan 1999, Marin David Condic wrote:
: >
: >> A very good point. When Ada first hit the market in 1983, the popular
: >> languages were a multitude of C dialects, Fortran, Cobol, and maybe some
: >> Pascal. 
: >
: >Don't forget CORAL-66 ...
: >

: ...and PLM.

And, of course, 1984 saw the introduction of Common Lisp.  You 
will find a number of people who will _strongly_ advocate Common 
Lisp, for many of the same reasons given here for Ada.  Just to 
be sure no-one is confused, obviously those people would have a 
number of different reasons, too.

Unfortunately, I don't really think enough information was
given by the original poster to make a truly worthwhile 
recommendation...

--
Brent Ellingson (bellings@badlands.NoDak.edu)
"It is amazing how complete is the delusion that beauty is goodness." 
                                                 -- Leo Tolstoy

Re: Ada vs C++ vs Java

[Ola Liljedahl]

Marin David Condic wrote:
> 
> A very good point. When Ada first hit the market in 1983, the popular
> languages were a multitude of C dialects, Fortran, Cobol, and maybe some
> Pascal. Here we are today where the hot languages are C++, Java and
C doesn't have to be 'hot' to be extremely popular anyway.
Probably more popular (i.e. actually being used) than C++, Java and Ada.
Most C compilers have modes for Kernighan&Ritchie C, ANSI C and maybe
even PCC (portable C compiler). So your 15 year old C program will
compile with a minimum of fuss.

> maybe some others. But all that Ada83 code will still compile today with
> minimal fuss even thought processors and operating systems have changed
> dramatically. That and the fact that Ada was specifically designed for
> very large, very long-lived projects and you've got some pretty solid
> reasons why this should be the choice for projects which aren't into
> building throw away code.

For some products/projects it is not meaningful to try to re-use ten
year old code. Technologies (hardware and software) changes.
Requirements changes. To utilize the most of the available hardware
you need to redesign your system and rewrite your code. If you are
not leading edge somebody else will be. Some other company with the
best brains and the proper tools making it possible to churn out the
best and most interesting software while your product boasts that it
is still using that first list package you ever wrote. Everything dies.

In my personal opinion the much touted benefits of code re-use made
possible with object oriented languages is mostly hype, meaningful
in some cases but definitely not all.
--
	Ola Liljedahl
	olli@enea.se

Re: Ada vs C++ vs Java

[Marin David Condic]

Obviously a valid point. Remember though that the original post was
about a system that was expected to be long lived - in which case,
portability, reuse, long term support, etc. are all real concerns that
should be addressed.

I hear that the way Micro$oft develops software is to hack it together
in C as quickly as possible to get it to market early. When its time to
produce version N+1, they basically throw out the existing stuff and
start over again. In that mode, there is very little, if anything, that
resembles "maintenance". They make throw-away code and they do it in C.

Now here's a question: Just because you are making throw-away code, is
there some reason that you *can't* do that in Ada? You don't need the
advantages of maintainability or reusability, but maybe you could take
advantage of the reliability, etc. which might mean your apps would ship
with fewer bugs. Granted, you may never intend to fix the bugs, but it
would seem that software with a reputation for fewer bugs ought to have
a competitive edge over less reliable products.

I know of no reason why applications developed in C cannot be done
equally as well or better in Ada. I do not find C to be somehow
inherently "faster" in development time. If anything, I find it slower.
And even when I've got development of throw-away code going on, I've
found that development gets significantly leveraged by the presence of
lots of Ada utility packages we've got lying around here which would be
difficult to duplicate in C. I've got metrics that have demonstrated
faster development time for Ada vs C and I know that there have been a
number of studies in both acedemia and industry which back that claim
up.

MDC

Ola Liljedahl wrote:
> 
> For some products/projects it is not meaningful to try to re-use ten
> year old code. Technologies (hardware and software) changes.
> Requirements changes. To utilize the most of the available hardware
> you need to redesign your system and rewrite your code. If you are
> not leading edge somebody else will be. Some other company with the
> best brains and the proper tools making it possible to churn out the
> best and most interesting software while your product boasts that it
> is still using that first list package you ever wrote. Everything dies.
> 


-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

    "Nobody shot me."

        --  Last words of Frank Gusenberg when asked by police who
            shot him fourteen times with a machine gun in the Saint
            Valentine's Day Massacre.

Re: Ada vs C++ vs Java

[Ola Liljedahl]

Marin David Condic wrote:
> 
<snip>
> 
> Now here's a question: Just because you are making throw-away code, is
> there some reason that you *can't* do that in Ada? You don't need the
> advantages of maintainability or reusability, but maybe you could take
> advantage of the reliability, etc. which might mean your apps would ship
> with fewer bugs. Granted, you may never intend to fix the bugs, but it
> would seem that software with a reputation for fewer bugs ought to have
> a competitive edge over less reliable products.
Throw-away code yes but still high quality developed in very short
time (time to market is always decreasing). And possibly Ada IS this
proper tool making it possible for you to be first (and best) every
time.

My posting did actually try to say two different things: first C is
not last years language hype but unusable today (to the contrary) and
second you might not need to reuse your code for decades, for some
projects it IS actually ok to use this year's language hype if this
tool chain as a whole will get you to the goal faster. These two
points are not related or maybe they are anti-related.
> 
> I know of no reason why applications developed in C cannot be done
> equally as well or better in Ada. I do not find C to be somehow
> inherently "faster" in development time. If anything, I find it slower.
> And even when I've got development of throw-away code going on, I've
> found that development gets significantly leveraged by the presence of
> lots of Ada utility packages we've got lying around here which would be
> difficult to duplicate in C. I've got metrics that have demonstrated
> faster development time for Ada vs C and I know that there have been a
> number of studies in both acedemia and industry which back that claim
> up.
What kind of utility packages?
--
	Ola Liljedahl
	olli@enea.se

Re: Ada vs C++ vs Java

[Marin David Condic]

Ola Liljedahl wrote:
> 
> Marin David Condic wrote:
> > I know of no reason why applications developed in C cannot be done
> > equally as well or better in Ada. I do not find C to be somehow
> > inherently "faster" in development time. If anything, I find it slower.
> > And even when I've got development of throw-away code going on, I've
> > found that development gets significantly leveraged by the presence of
> > lots of Ada utility packages we've got lying around here which would be
> > difficult to duplicate in C. I've got metrics that have demonstrated
> > faster development time for Ada vs C and I know that there have been a
> > number of studies in both acedemia and industry which back that claim
> > up.
> What kind of utility packages?
> --
A wide assortment. Lots of the "hacker" programs we slap together as
"throw away" code tend to be for VMS or Unix and are command line
oriented. We've built up packages which do things like all the standard
data structures in a variety of flavors (stacks, queues, lists, etc.),
string manipulation tools (mostly to make up for Ada83 deficiencies -
Ada95's string packages are pretty comprehensive.) command line
processing tools for parsing, Ada source manipulation things (lexical
analysis, etc), and the list goes on. We've developed reusable tools for
some specialized applications, which wouldn't be of much use to anyone
but us. For instance, we built a very large system called "Pictures to
Code" and this maintains a development library in a large database.
Naturally, we've built packages which do a variety of library
manipulations and such which get reused all the time as we build
specialized little hacked programs for the users. We've even done a
variety of things for our real time controls which are generic reuse
tools - A/D and F/D converter code, monitor code, bus interface code,
etc. have all been things where we see enough hardware similarity to
make reusable packages. Unfortunately, most of our real time projects
are in Ada83 rather than Ada95, so we have not built up much experience
in using tagged records, etc. for reuse.

I'm sure that a number of the tools we have could be built in other
languages. Reuse has been around since Fortran and naturally a lot of
our mathematical stuff is no big mystery and could be done in just about
any language. But with Ada83 giving us generics and Ada95 with tagged
types, we have been able to leverage reuse a lot farther than otherwise
might be the case. A lot of it depends on how application specific your
reuse tools are. Certainly we beat to death the data structures & string
manipulation in almost any domain. Command line stuff is not applicable
to all domains, so it gets used less, etc. YMMV...

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

    "Nobody shot me."

        --  Last words of Frank Gusenberg when asked by police who
            shot him fourteen times with a machine gun in the Saint
            Valentine's Day Massacre.

Re: Ada vs C++ vs Java

[Crazy Pete]

> > Given all that we decided to check C++ and Java. I would appreciate
> > greatly any comparisons, comments, hints, pointers to electronic and

> have been much harder - perhaps even involving a complete rewrite.  Even
> a change of C++ or Java compiler vendor might create significant amounts
> of work.  

First of all, given the number of groups to which this was 
crossposted, I am not sure if the original asker will see this.  (I 
have trimmed about half of the groups out the reply!)   Now that C++ 
has an ISO standard that is unlikely to change, mutability is probably
not a reason to use Ada.  I know nothing of Ada, so I will not comment
further.  Java is by far a simpler language than C++.  If you have a 
team of seasoned C++ programmers, you probably should go with C++ as 
it is by far the more powerful language.  For example a real weak spot
in Java is its' inability to support the "Resource Acquisition is 
Initialization" technique used so extensively in C++.  (Stroustroup, 
"The C++ Programming Language", 1997  pp364-71)  However, if you are 
all inexperienced with C++, or even worse, intend to learn as you go, 
you are MUCH better off with Java.  Other things being the same, Java 
is preferred for smaller applications (and almost mandatory for Web 
Browser based applets) where portability is most important.  C++ is 
preferred for larger systems where resources and performance are 
critical.

Best of Luck

Peter

Re: Ada vs C++ vs Java

[Markus Kuhn]

Here my quick comparison between Ada95, Java, and C++, from someone
who has used all three languages:

Complexity:

C++ is by far the most complicated and most difficult to learn
of the three languages, Java is perhaps somewhat simpler to learn
than Ada95, though I think that generally Java and Ada95 provide
roughly an equal level of complexity. Rumours that some eminent
academics spread in the early 1980s that Ada is "much too complex"
become laughable to anyone who has read both the Ada 95 and C++
ISO standards.

Object Orientation:

All three are full OO languages. Ada was originally a procedural
languages, and the Ada95 OO extensions are clearly an add-on
feature. Nothing in Ada forces you to program using OO concepts,
but if you want to do OO programming then all the mechanisms you need
are there. The Ada terminology is a bit different than the classical
OO terminology, for instance a "class" is called a "tagged record"
in Ada95. Many typical modern OO features such as overloading,
exceptions and name spaces were already in Ada83 long before anyone
was talking about OO, therefore only minor extensions where necessary
in Ada95 such as class inheritance. C++ is like Ada95 an add-on OO
language that enables but does not enforce OO-style interfaces, while
Java forces the programmer right from the beginning into an OO corset.
Both Ada95 and Java avoid the pitfalls of multiple inheritance, Java
using interfaces and Ada95 using include inheritance.

Security and Low-Level Access:

Both Ada and Java support a pointer-arithmetic free programming
style that allows to use the compiler as a powerful tool to detect
the most dangerous memory corruption errors. Java forces the
programmer to use only high-level garbage collected data structures,
while Ada allows them to be used, but for special low-level tasks
(device drivers) also provides carefully controlled means to bypass
the security features and to all the low-level hacking that is
possible in Assembler and C(++). Ada is even more comfortable than
C in many respects with regard to low-level bit manipulation, because
it provides strict control over record layouts and memory arrangement.
One distinguishing feature of Ada is that it gives very good
low-level control about numerical types and numerical precision
in a very portable way. C/C++ programmers have to use a lot of dirty
tricks or configuration files to obtain assurances that Ada
programmers can just specify directly to the compiler.

Concurrency:

Both Ada and Java have good language support for multi-threading
and synchronization, while C++ leaves this to the OS and library
with lots of portability problems arising (Ada and Java programmers
do not have to worry about Win32 vs. POSIX.1 threads).

Support:

All three langauges are today well supported by the industry and
are going to be around for a very long time. There is no doubt
that you will get well maintained C++, Ada95, and Java development
environments in 30 years from now, because the existing code base
for all these languages has reached critical mass. There are
production quality open source development environments available
for all three languages.

Efficiency:

Java was designed primarily to run on intermediate code interpreters.
It aims for portability and not so much for efficiency. Ada and C++
both produce fairly efficient code. It has been my experience that
the Ada language encourages a somewhat safer clearer programming style
and that therefore due to this style change, my Ada code is typically
around 20% slower than my C code (but also easier to read for others).
It is possible in Ada to produce exactly the same machine code that a
C compiler can produce (at least with gcc and gnat), however if you
try to do this, your Ada program might look a bit unnatural and
becomes as unreadable as an optimized C code. In practice, the difference
is only worth the effort in small inner loops in numerics or signal
processing code, where raw assembler is often the best choice.

Library support:

This is probably the only weak spot of Ada. The ISO Ada95 standard
library has a few bizarre features (e.g., the handling of form feeds
in Ada.Text_IO), and most significantly, Ada still lacks an ISO
standardized equivalent of the STL, even though the language is
perfectly suited to define one. C++ has the advantage of inheriting
all existing C library interfaces. Ada95 has simple mechanisms to
call C libraries, but in practice this works only nicely for exported
functions and variables, but not for the preprocessor constants that
are often an important part of a C API. However one can use tools that
semiautomatically convert C's .h files into proper Ada bindings, and
therefore access to C libraries is not too critical in practice
for Ada95 programmers.

In general: Ada95 is compared to C++ and Java certainly underhyped,
which should not keep you from having a good look at the language.
It nicely combines the security and concurrency of Java with the
efficiency of C++ and of all three languages it provides the best
support to design maintainable long-living programs where many
other people will have to read your source code. With the recently
gained maturity of the GNU compiler, I believe that Ada95 will
have a bright future.

Markus

-- 
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>

Re: Ada vs C++ vs Java

[Peter]

In article <77nhuv$29c$3@pegasus.csx.cam.ac.uk>, mgk25@cl.cam.ac.uk
(Markus Kuhn) wrote:

> Here my quick comparison between Ada95, Java, and C++, from someone
> who has used all three languages:
> 
> Object Orientation:
> 
> All three are full OO languages. 

Uhhh... well actually none of those languages are full OO languages
because the primitive data types in them aren't objects.

> One distinguishing feature of Ada is that it gives very good
> low-level control about numerical types and numerical precision
> in a very portable way. C/C++ programmers have to use a lot of dirty
> tricks or configuration files to obtain assurances that Ada
> programmers can just specify directly to the compiler.

I would like to find out more about how Ada handles this.  Where does the
Ada standard live?

Re: Ada vs C++ vs Java

[David C. Hoos, Sr.]

Peter wrote in message ...
>In article <77nhuv$29c$3@pegasus.csx.cam.ac.uk>, mgk25@cl.cam.ac.uk
>(Markus Kuhn) wrote:
>
>> Here my quick comparison between Ada95, Java, and C++, from someone
>> who has used all three languages:
>>
>> Object Orientation:
>>
>> All three are full OO languages.
>
>Uhhh... well actually none of those languages are full OO languages
>because the primitive data types in them aren't objects.
>
>> One distinguishing feature of Ada is that it gives very good
>> low-level control about numerical types and numerical precision
>> in a very portable way. C/C++ programmers have to use a lot of dirty
>> tricks or configuration files to obtain assurances that Ada
>> programmers can just specify directly to the compiler.
>
>I would like to find out more about how Ada handles this.  Where does the
>Ada standard live?
The 32-bit Windows Help version of the standard is available on my FTP
site at ftp://ada95.com/pub/rm95-winhelp/

A hypertext version is available at http://www.adahome.com/rm95/

Other formats and additional documentation is available at
http://www.adaic.org/standards/ada95.html

Re: Ada vs C++ vs Java

[Larry Kilgallen]

In article <nobody-1501991145090001@adp8471-1-14.pixi.net>, nobody@0.0 (Peter) writes:
> In article <77nhuv$29c$3@pegasus.csx.cam.ac.uk>, mgk25@cl.cam.ac.uk
> (Markus Kuhn) wrote:

>> One distinguishing feature of Ada is that it gives very good
>> low-level control about numerical types and numerical precision
>> in a very portable way. C/C++ programmers have to use a lot of dirty
>> tricks or configuration files to obtain assurances that Ada
>> programmers can just specify directly to the compiler.
> 
> I would like to find out more about how Ada handles this.  Where does the
> Ada standard live?

Follow the links from www.adahome.com, but I would recommend starting
with something called the "Rationale" which is a bit more expository.

Since portability of numeric types started with Ada83 and is old hat
to Ada folk, you might consider some of the other documents as well.

Larry Kilgallen

Re: Ada vs C++ vs Java

[Tucker Taft]

Peter (nobody@0.0) wrote:

: ...
: > One distinguishing feature of Ada is that it gives very good
: > low-level control about numerical types and numerical precision
: > in a very portable way. C/C++ programmers have to use a lot of dirty
: > tricks or configuration files to obtain assurances that Ada
: > programmers can just specify directly to the compiler.

: I would like to find out more about how Ada handles this.  Where does the
: Ada standard live?

The Ada 95 standard is accessible on-line through the Ada Information 
Clearinghouse site, www.adaic.org, as well as www.adahome.com, also known 
as the "Home of the Brave Ada Programmers" ;-).

--
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Ada vs C++ vs Java

[Bob Cousins]

In comp.arch.embedded, Leszek Sczaniecki wrote:

>We are about to start a big project, something about 250k lines of code.
>We are going to stick to it for next several years. We would like to
>make an educated choice for the underlying language. This language
>should...

Well, thank you for starting yet another holy war, it's so much more fun than
researching the languages and coming to your own conclusions ;-)

I won't comment on the language issues, apart from saying that it does not
appear that Java will meet you requirements. Either of Ada or C++ will easily
meet your requirements.

Really, choice of very similar languages is a small issue, and for a project of
this size far more significant factors are project management and the quality of
the engineers.

If you want to be radical, let the engineers choose both the language and more
importantly write the project plan. A good engineer will choose the appropriate
langauge and commit to his or her own plan. If you haven't got good engineers,
the project will have problems anyway...
-- 
Bob Cousins, Software Engineer.
http://www.lintilla.demon.co.uk/
"We demand that we may, or may not, be philosophers!"

Re: Ada vs C++ vs Java

[jim.hyslop]

In article <369e09ff.3246197@news.supernews.co.uk>,
  bob@lintilla.demon.co.uk (Bob Cousins) wrote:
> In comp.arch.embedded, Leszek Sczaniecki wrote:
>
> >We are about to start a big project, something about 250k lines of code.
> >We are going to stick to it for next several years. We would like to
> >make an educated choice for the underlying language. This language
> >should...
>
> Well, thank you for starting yet another holy war, it's so much more fun than
> researching the languages and coming to your own conclusions ;-)

Actually, I would love to see an objective comparison of various languages,
with a list of each language's strengths and weaknesses.  An objective
comparison of that type would aid in a proper selection of the proper tool
for the job.

> I won't comment on the language issues, apart from saying that it does not
> appear that Java will meet you requirements. Either of Ada or C++ will easily
> meet your requirements.
>
> Really, choice of very similar languages is a small issue, and for a project
of
> this size far more significant factors are project management and the quality
of
> the engineers.

An issue to consider is the human aspect of this - how many developers are
currently familiar with the language of choice?  One of the main reasons
COBOL is still so prevalent is that it is not always easy to retrain
programmers in a different language.  Many of them do not *want* to switch
languages.

> If you want to be radical, let the engineers choose both the language and more
> importantly write the project plan. A good engineer will choose the
appropriate
> langauge and commit to his or her own plan. If you haven't got good engineers,
> the project will have problems anyway...
Ideally, a good engineer will choose the appropriate language.  In many cases,
though, engineers will choose the language they are familiar with.


Jim
Note to recruitment agencies:  I delete unsolicited email from
recruitment agencies without reading it, so don't even bother.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[robert_dewar]

In article <77l2nq$46r$1@nnrp1.dejanews.com>,
  jim.hyslop@leitch.com wrote:
> An issue to consider is the human aspect of this - how
> many developers are currently familiar with the language
> of choice?  One of the main reasons COBOL is still so
> prevalent is that it is not always easy to retrain
> programmers in a different language.  Many of them do not
> *want* to switch languages.

Maybe *a* reason but certainly not the main reason or even
one of the main reasons. The reason that COBOL is still
widely used is that it is still one of the best choices
for the kind of programs it is used for. The complete lack
of efficient scaled decimal arithmetic for example makes
C or C++ or Java much less appropriate. Yes, you can
approximate such facilities with libraries, but you lose
efficiency, and clarity (for example there is no way to
graft high precision decimal literals into C).

This is just one strong point of COBOL, there are many
others. Most people expressing the above kind of opinion
typically are not COBOL experts!

Robert Dewar
Ada Core Technologies

(who is in the pretty unusual position of being both a
COBOL expert and an Ada expert, having written compilers
for both of these languages :-)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[dennison]

In article <369e09ff.3246197@news.supernews.co.uk>,
  bob@lintilla.demon.co.uk (Bob Cousins) wrote:
> In comp.arch.embedded, Leszek Sczaniecki wrote:
>
> >We are about to start a big project, something about 250k lines of code.
> >We are going to stick to it for next several years. We would like to
> >make an educated choice for the underlying language. This language
> >should...
>
> I won't comment on the language issues, apart from saying that it does not
> appear that Java will meet you requirements. Either of Ada or C++ will easily
> meet your requirements.

Not true. C++ has no language support for concurrency. That leaves Ada.



T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada vs C++ vs Java

[Pete Becker]

Leszek Sczaniecki wrote:
> 
> We are about to start a big project, something about 250k lines of code.
> We are going to stick to it for next several years. We would like to
> make an educated choice for the underlying language. This language
> should
> - support object oriented programming
> - support parallel programming
> - lead to easily maintainable code
> - promote safe programming techniques
> - have significant support from commercial vendors (compilers, GUI
> design, testing sw)
> - be available for popular processors (such as 68xxx, PowerPC, etc.)
> - enjoy wealth of existing solutions
> - support "almost real time" execution
> - be suitable for design of embedded systems
> - have existing support for vxworks

Interesting choice of requirements. Only the last seems at all related
to being suitable for the actual task that you are going to perform.

-- 
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com

Re: Ada vs C++ vs Java

[Scott Johnson]

Pete Becker wrote:
> 
> Leszek Sczaniecki wrote:
> >
> > We are about to start a big project, something about 250k lines of code.
> > We are going to stick to it for next several years. We would like to
> > make an educated choice for the underlying language. This language
> > should
> > - support object oriented programming

I'm rather unfamiliar with Ada, so I won't discuss it.

C++, of course, does support OO.  It ain't a PURE OO language--it
owes much to C, which is a structural langauge, and the current
library promotes generic programming much more than true OO programming.
Also, there are lotsa pitfalls to avoid, and if ya need distributed
objects, C++ alone won't cut it.  (CORBA, anyone?) But for closed-system
OO that is efficient and well-supported, C++ does quite well.

Java is a more "pure" OO language.  Since your laundry list :) missed
the programming paradigm most fashionable these days--component
programming--Java provides better native support for this than does
C++.  

> > - support parallel programming

How do you mean?  All of 'em, if ya use a multithreading OS on a 
multiprocessing machine, with appropriate libraries, can be used to
write code that can run on multiple processors.  The partitioning you
get this way is course-grained (threads, essentially), and you got
to do the partitioning yourself, but it works.  Java has threading built
in to the native library; C and C++ require you to use OS libraries
to achieve multithreading.

Or were you looking for something where you can specify an algorithm
and the compiler will automagically partition it among processors?  
If you are doing heavy-duty number crunching, the language you probably
want is Fortran (or FORTRAN) :).  If you are mainly doing control 
and/or UI tasks, fine-grained parallelism ain't gonna buy you much of
anything.

> > - lead to easily maintainable code

This depends as much on the competence of your engineering staff. 
However, Java has the advantage of a binary interface standard, where
C and C++ do not.  Generally, the output of different C compilers can
be linked together without problems; this is NOT true for different
C++ compilers.


> > - promote safe programming techniques

Java does this in spades--in fact, many reasonable-but-possibly-abused
techniques are banned in Java.  Not becuase Sun thinks programmers are
idiots, of course, but because this is a requirement to support Java's
security model.

C and C++, on the other hand, will gladly allow you to shoot yourself
in the foot.  Safe code can be written in 'em, but so can dangerous
code.


> > - have significant support from commercial vendors (compilers, GUI
> > design, testing sw)

In the vxWorks space, C/C++ are the clear winners here.  Diab data,
Green Hills, Metroworks, and Cygnus/FSF all provide C/C++ compilers that
target vxWorks.

Java ports to vxWorks are much more limited--and not as mature as their
PC/workstation counterparts.

GUI libraries are another issue altogether.  Given that vxWorks is
deployed, most of the time, in environments without a GUI, this is
a major weakness--for either language.  Wind River/Zinc has a few
solutions (RtX-Windows, UGL), none of 'em are particularly great.  

All the AWT implementations I've seen targeting vxWorks rely on one 
of the above libraries.

> > - be available for popular processors (such as 68xxx, PowerPC, etc.)

C/C++ compilers are available for all of the above.

PowerPC java virtual machines are available from various sources, 68k
ones are probably harder to find.

> > - enjoy wealth of existing solutions

Solutions to do what?  

> > - support "almost real time" execution

Either you are real time, or ya ain't.  C and C++ can certainly be used 
to write deterministic code; though the lack of formalization of these
means that you'll have a lot of testing to do to prove it.

Java is currently worthless for real-time; because of the garbage
collector.  I've heard stories about supposed real-time garbage
collectors (which don't block other threads from running, or do so
for a bounded amount of time)--but you still have to prove that you
never run out of memory if you do that.  With Java, you CANNOT create
objects on the stack--so there is no way of avoiding dynamic memory
allocation.

> > - be suitable for design of embedded systems

C and C++ certainly are.

Java may be, depending on how deeply embeeded you are talking about.
Given that you have mentioned things such as GUI support, and have
asked about processors such as powerPc, it sounds like you will have
some CPU horsepower and memory at your disposal.  Including a JVM,
an implementation of the Java library, and an underlying GUI library
is going to add about 2-3 Mb to your program size, and that's an 
efficient (but full) implementation.  Things like PersonalJava or 
EmbeddedJava reduce this figure, but you will still need a bunch of 
memory.

Much more than you will for a C/C++ implementation.

> > - have existing support for vxworks

I've been assuming vxWorks throughout the document...see above for 
my comments.
 
> Interesting choice of requirements. Only the last seems at all related
> to being suitable for the actual task that you are going to perform.

Agreed.  Much of the above seems to be a list of buzzwords...do they
really correspond to product requirements?  

What is it you are trying to build, if I may ask????

Scott

Re: Ada vs C++ vs Java

[Larry Kilgallen]

In article <369F0118.7870@nospam.aracnet.com>, Scott Johnson <sj_nospam@nospam.aracnet.com> writes:

> I'm rather unfamiliar with Ada, so I won't discuss it.


>> > - support parallel programming
> 
> How do you mean?  All of 'em, if ya use a multithreading OS on a 
> multiprocessing machine, with appropriate libraries, can be used to
> write code that can run on multiple processors.  The partitioning you
> get this way is course-grained (threads, essentially), and you got
> to do the partitioning yourself, but it works.  Java has threading built
> in to the native library; C and C++ require you to use OS libraries
> to achieve multithreading.


But if you _did_ have familiarity with Ada (even Ada83) you would know
that Ada has tasking built in to the language.  Thus, based on your
Java comments, C++ is the only one of the three contenders that does
not have built in support for threads/tasking.

To say that a language supports a concept only if the machine involved
has a library to perform that function seems of little value.  Sort of
like saying that a language automatically supports Cobol compilation
given a "Compile_Cobol" library routine.

Larry Kilgallen

Re: Ada vs C++ vs Java

[Matthew Heaney]

Scott Johnson <sj_nospam@nospam.aracnet.com> writes:

> C++, of course, does support OO.  It ain't a PURE OO language--it
> owes much to C, which is a structural langauge, and the current
> library promotes generic programming much more than true OO programming.
> Also, there are lotsa pitfalls to avoid, and if ya need distributed
> objects, C++ alone won't cut it.  (CORBA, anyone?) 

There are indeed real-time orbs written in Ada.  However, if your vendor
supports the Distributed Systems Annex, then programming with
distributed objects is possible, directly in the language.  For
Ada-to-Ada IPC, you can't beat the DSA.
-- 
Those who believe in the supernatural should be required to learn
computer programming.  This would force them to discover that things
which appear at first to be completely mysterious and incomprehensible,
in fact have a logical (and usually simple) explanation.  --J.B.R. Yant

Re: Ada vs C++ vs Java

[James Kanze]

Scott Johnson wrote:
|> Since your laundry list :) missed
|> the programming paradigm most fashionable these days--component
|> programming--Java provides better native support for this than does
|> C++.

What native support?  The main component-based programming idiom in Java
is beans, which is mainly a set of programming conventions, which could
in principle be used in C++ or any other language.

--
James Kanze                                           GABI Software, S�rl
Conseils en informatique orient� objet  --
                          --  Beratung in industrieller Datenverarbeitung
mailto: kanze@gabi-soft.fr          mailto: James.Kanze@dresdner-bank.com

Re: Ada vs C++ vs Java

[Scott Johnson]

James Kanze wrote:
> 
> Scott Johnson wrote:
> |> Since your laundry list :) missed
> |> the programming paradigm most fashionable these days--component
> |> programming--Java provides better native support for this than does
> |> C++.
> 
> What native support?  The main component-based programming idiom in 
> Java is beans, which is mainly a set of programming conventions, which > could in principle be used in C++ or any other language.

Inner classes for one.  While they can be replicated in C++ (see
a thread in comp.std.c++ for more on this one), they require a bit
more work.

Standard techniques for things like object serialization and
introspection for another.  This can also be done in C++ of course,
and can be done automagically if you use various distributed object
and/or component technologies.  (Of course, then you are writing lots
of code in some IDL which gets compiled into C++; with Beans, you write
your code in Java.)

Both of the above have C++ solutions.  What does not have a good
C++ solution, is a key part of Java, and is very important if component
based programming is to be a reality--a standard binary interface.  You
can't even (usually) link two C++ libraries together if they weren't
compiled by the same compiler--this is IMHO a **MAJOR** weakness for
C++--at least in this application.  

About the only vendor I can think of that does this well--and I hate
to admit it--is Microsoft.  When you not only own a monopoly share
of the OS market for a particular architecture, but own the vast 
majority of the development tool market, you can get away with this.
:)

Actually, I'm surprised that other key silicon/OS vendors haven't tried
to get together and specify C++ ABIs for various architectures--I'm
not aware of any formal standardization along these lines.  
After all, my current project at work uses a MPC860 processor, and
there is a nice, universally accepted standard as to how registers
are allocated in functional programs; how stack frames are construted,
how structs are laid out, the size and alignmnent of the fundamental
types, etc--allowing me to link C code compiled with gcc to C code
compiled with CodeWarrior or Diab Data or Green Hills.

Unfortunately, there ain't no standard I'm aware of that says how the
this pointer gets passed, or how exception-capable stack frames are set
up, or how classes are laid out, or how virtual functions and virtual
base classes are handled, or how function names are mangled, etc.

Now that the work on standardization of the language and libraries are
finished--this would be major benefit.  

Scott

Re: Ada vs C++ vs Java

[Siamak Kaveh]

Craig Garrett wrote in message <01be3f5e$26453ca0$5704fbd1@longslide>...

...  Ada is right behind it in that support, (well, ok, FORTRAN has alot of
support too, but that is just for the legacy code and die-hard programmers
that are over 40 years old and never did learn how to program in a real
language, so they are stuck with it ...


I bet you don't know anything about FORTRAN 95 ( the latest ISO standard)
and/or High Performance Fortran (HPF) and upcoming standard FORTRAN 2000. If
you are brave put your lines in (comp.lang.fortran)

Re: Ada vs C++ vs Java

[Craig Garrett]

> I bet you don't know anything about FORTRAN 95 ( the latest ISO standard)
> and/or High Performance Fortran (HPF) and upcoming standard FORTRAN 2000.
If
> you are brave put your lines in (comp.lang.fortran)

I bet the programmers that have been using FORTRAN since 1960 havent heard
anything about 95 or 2000 either :)
   - Craig

Re: Ada vs C++ vs Java

[Ken Keys]

Craig Garrett wrote:
 
> I bet the programmers that have been using FORTRAN since 1960 havent heard
> anything about 95 or 2000 either :)

You would lose that bet.

KLK

Re: Ada vs C++ vs Java

[Bruce Detter]

This thread seems to have generated a lot of interest (and a lot of
interesting and informative reading).

I think your question misses the real issue for a project such as yours.
Project management is far more important than the tool you chose for
implementation.  Programmers and languages come and go (you may have to
integrate current code with new code in some as yet unspecified language
with personnel who never worked on the current code).  But if the project is
properly managed (all documentation maintained, coding styles enforced,
programmers and engineers kept current on training, etc.) then the choice of
languages is of secondary importance.

That being said, I think your choices are between Ada, C++, and Java.
(Actually, using all three might be appropriate depending the use, each has
its advantages).  The pool of Ada programmers available to you is much
smaller that either of the other two, but in general an Ada programmer will
have a better understanding of OO.  C++ has the largest pool of programmers,
but 'real' C++ OO programmers are fairly rare.  Unfortunately, far too many
'C++' programmers are just enhanced C coders with minimal OO understanding.
Java, as an embedded system development environment, is still in its infancy
(As is Windows CE, not to be compared to VxWorks).
I believe project management and the architecture development tools
(Rational Rose, ObjectTime, etc.) you choose are more critical than the
language(s) you choose.  I also believe that one common language is not
always the best solution.  Determine what your objectives are, then choose a
tool or resource that can best fulfil each objective.  A short term cost hit
on more resources and tools up front can mean long term savings (but be
smart about it, know why you're spending the extra money/time)

Something to think about...

Bruce Detter
Senior Software Engineer
Lockheed Martin WDL

Leszek Sczaniecki wrote in message <369C1F31.AE5AF7EF@concentric.net>...
>We are about to start a big project, something about 250k lines of code.
>We are going to stick to it for next several years. We would like to
>make an educated choice for the underlying language. This language
>should
>- support object oriented programming
>- support parallel programming
>- lead to easily maintainable code
>- promote safe programming techniques
>- have significant support from commercial vendors (compilers, GUI
>design, testing sw)
>- be available for popular processors (such as 68xxx, PowerPC, etc.)
>- enjoy wealth of existing solutions
>- support "almost real time" execution
>- be suitable for design of embedded systems
>- have existing support for vxworks
>
>There is a legacy code written in Ada and our customer would prefer Ada
>95. However, we became seriously concerned that there is not sufficient
>support for Ada in the commercial world. Given, that we will be stuck
>with our project for the next several years we would like to choose
>something that still will have adequate support few years down the road.
>Given all that we decided to check C++ and Java. I would appreciate
>greatly any comparisons, comments, hints, pointers to electronic and
>hard copy sources, warnings about traps and pitfalls, etc. that would
>help us thoroughly justify the language choice to our customer.
>
>-leszek
>
>PS
>If you are afraid that your response may start a religious war or that
>it is not of interest of your newsgroup please send me e-mail.
>
>

Re: Ada vs C++ vs Java

[John Birch]

On Fri, 15 Jan 1999 10:35:43 -0800, "Bruce Detter"
<bruce.detter@lmco.com> wrote:

>This thread seems to have generated a lot of interest (and a lot of
>interesting and informative reading).

Indeed

>I think your question misses the real issue for a project such as yours.
>Project management is far more important than the tool you chose for
>implementation.  Programmers and languages come and go (you may have to
>integrate current code with new code in some as yet unspecified language
>with personnel who never worked on the current code).  But if the project is
>properly managed (all documentation maintained, coding styles enforced,
>programmers and engineers kept current on training, etc.) then the choice of
>languages is of secondary importance.

Well.... <counting to ten>

This is a bit like saying it doesn't matter if you build a bridge from
wood, steel or glass as long as the project manager is good!
While project management may be of great importance on a large
project, the number of good project managers (to bad ones) is probably
in the same ratio as _you_ put good C++ programmers. Your paragraph
sounds a bit like an advocation of the 'straight jacket' approach to
projects, i.e. keep the programmers in their place we'll tell them
what's good for them.

Whilst documentation is fine, enforcement of coding standards is a
very emotive issue. If we're simply talking about commenting and
header blocks then I have little argument, but in many shops - coding
style is taken a lot further than that. 

BTW I'm all for training too.

But... the most critical part to the success of any large project is a
good design, that is well understood, abstracted into several layers
so that management, projects and engineering staff can see the level
of detail they require. Now part of realising a good design is
choosing the appropriate tools for the job. This includes the
methodology used, the testing strategy, the design notation, and the
language (not an exhaustive list by any means). Just having the right
person to monitor progress and facilitate comunication between client,
management and workers will not make a damm's worth of difference in a
project that does not have a sound technological basis.

BTW if you anticipate a high degree of 'churn' amongst the developers,
perhaps that should tell you something about the development strategy.
IMHO people leave companies because they disagree with something
(their managers, the design, the salary or the conditions). It's
actually quite hard to get rid of a well motivated developer working
on a project which he believes in!

>That being said, I think your choices are between Ada, C++, and Java.

Wow, insight here, I think this was the original question; which
langauge should I choose from Ada C++ and Java ;-)

<snip>

> C++ has the largest pool of programmers, but 'real' C++ OO programmers are fairly rare.

Agreed

>  Unfortunately, far too many
>'C++' programmers are just enhanced C coders with minimal OO understanding.

More accurately, most of them have no knowledge of C and minimal OO
understanding :-)

>Java, as an embedded system development environment, is still in its infancy
>(As is Windows CE, not to be compared to VxWorks).
>I believe project management and the architecture development tools
>(Rational Rose, ObjectTime, etc.) you choose are more critical than the
>language(s) you choose.

You're not by any chance a project manager are you?

>I also believe that one common language is not
>always the best solution.  Determine what your objectives are, then choose a
>tool or resource that can best fulfil each objective.  A short term cost hit
>on more resources and tools up front can mean long term savings (but be
>smart about it, know why you're spending the extra money/time)

Oh I see from your sig that you're not, so I don't understand why you
think the language choice is unimportant. In a C++ shop, choosing Ada
could result in a rapid lack of staff ;-). OTOH choosing Java for a
mission critical, hard real-time embedded application could be a RW
disaster too! Or are you saying that by choosing the right project
manager / methodology this would not happen?

I'm trying (and probably failing miserably) not to be too anti PM, but
all my experience to date has been that PM's make effective fire
starters, but are very poor at putting them out (a job they generally
leave for engineers ;-) Besides from your first paragraph I get the
impression that the PM should control the project rather than assist
it. I personally favour the 'inverse management hierarchy' ideas of
project control. I.e. the Software / Hardware engineers produce the
goods for the client, everybody else in the company should be working
to help them!

Forgive me if this posting appears somewhat inflammatory, but your 
first para really got my dander up.



regards John B.

Re: Ada vs C++ vs Java

[Bruce Detter]

Sorry about that....  I did oversimplify my thoughts and you caught some of
my "gaps".   Let me state right up front, PM cannot possibly work (be
anything other than a paperpushing nightmare) without the SW engineers
"buying into" the plan.  In my mind (dangerous territory) PM is a tool to
help the engineer focus on the job at hand if properly used.  I think my
concept of PM is very close to your 'inverse management hierarchy' idea in
that the management plan is developed and agreed to by the engineers
involved.
There should be some means of keeping the HW/SW engineers on the same page
rather than the engineer developing in isolation only to find out in code
review they were "off base".  I believe development tools are now available
to minimize the intrusion to the engineer, let the engineers coopertatively
manage their own project, and permit management to see what the progress and
activities are without bothering the engineers.
Getting a little wordy here, so the upshot is more teamwork/cooperation from
management down, less "us vs. them" attitude.

BCD3
John Birch wrote in message <36a32a9d.12623551@news.demon.co.uk>...
>On Fri, 15 Jan 1999 10:35:43 -0800, "Bruce Detter"
><bruce.detter@lmco.com> wrote:
>
>>This thread seems to have generated a lot of interest (and a lot of
>>interesting and informative reading).
>
>Indeed
>
>>I think your question misses the real issue for a project such as yours.
>>Project management is far more important than the tool you chose for
>>implementation.  Programmers and languages come and go (you may have to
>>integrate current code with new code in some as yet unspecified language
>>with personnel who never worked on the current code).  But if the project
is
>>properly managed (all documentation maintained, coding styles enforced,
>>programmers and engineers kept current on training, etc.) then the choice
of
>>languages is of secondary importance.
>
>Well.... <counting to ten>
>
>This is a bit like saying it doesn't matter if you build a bridge from
>wood, steel or glass as long as the project manager is good!
>While project management may be of great importance on a large
>project, the number of good project managers (to bad ones) is probably
>in the same ratio as _you_ put good C++ programmers. Your paragraph
>sounds a bit like an advocation of the 'straight jacket' approach to
>projects, i.e. keep the programmers in their place we'll tell them
>what's good for them.
>
>Whilst documentation is fine, enforcement of coding standards is a
>very emotive issue. If we're simply talking about commenting and
>header blocks then I have little argument, but in many shops - coding
>style is taken a lot further than that.
>
>BTW I'm all for training too.
>
>But... the most critical part to the success of any large project is a
>good design, that is well understood, abstracted into several layers
>so that management, projects and engineering staff can see the level
>of detail they require. Now part of realising a good design is
>choosing the appropriate tools for the job. This includes the
>methodology used, the testing strategy, the design notation, and the
>language (not an exhaustive list by any means). Just having the right
>person to monitor progress and facilitate comunication between client,
>management and workers will not make a damm's worth of difference in a
>project that does not have a sound technological basis.
>
>BTW if you anticipate a high degree of 'churn' amongst the developers,
>perhaps that should tell you something about the development strategy.
>IMHO people leave companies because they disagree with something
>(their managers, the design, the salary or the conditions). It's
>actually quite hard to get rid of a well motivated developer working
>on a project which he believes in!
>
>>That being said, I think your choices are between Ada, C++, and Java.
>
>Wow, insight here, I think this was the original question; which
>langauge should I choose from Ada C++ and Java ;-)
>
><snip>
>
>> C++ has the largest pool of programmers, but 'real' C++ OO programmers
are fairly rare.
>
>Agreed
>
>>  Unfortunately, far too many
>>'C++' programmers are just enhanced C coders with minimal OO
understanding.
>
>More accurately, most of them have no knowledge of C and minimal OO
>understanding :-)
>
>>Java, as an embedded system development environment, is still in its
infancy
>>(As is Windows CE, not to be compared to VxWorks).
>>I believe project management and the architecture development tools
>>(Rational Rose, ObjectTime, etc.) you choose are more critical than the
>>language(s) you choose.
>
>You're not by any chance a project manager are you?
>
>>I also believe that one common language is not
>>always the best solution.  Determine what your objectives are, then choose
a
>>tool or resource that can best fulfil each objective.  A short term cost
hit
>>on more resources and tools up front can mean long term savings (but be
>>smart about it, know why you're spending the extra money/time)
>
>Oh I see from your sig that you're not, so I don't understand why you
>think the language choice is unimportant. In a C++ shop, choosing Ada
>could result in a rapid lack of staff ;-). OTOH choosing Java for a
>mission critical, hard real-time embedded application could be a RW
>disaster too! Or are you saying that by choosing the right project
>manager / methodology this would not happen?
>
>I'm trying (and probably failing miserably) not to be too anti PM, but
>all my experience to date has been that PM's make effective fire
>starters, but are very poor at putting them out (a job they generally
>leave for engineers ;-) Besides from your first paragraph I get the
>impression that the PM should control the project rather than assist
>it. I personally favour the 'inverse management hierarchy' ideas of
>project control. I.e. the Software / Hardware engineers produce the
>goods for the client, everybody else in the company should be working
>to help them!
>
>Forgive me if this posting appears somewhat inflammatory, but your
>first para really got my dander up.
>
>
>
>regards John B.
>

Thanks everyone! (was Re: Ada vs C++ vs Java)

[Martijn Lievaart]

[ Replying here because the original message is unavailable on my
newsserver. I intended to reply to the original message. ]

I just want to thank everyone participating in this thread for making it a
hugely informative thread without evolving into holy wars. It seems we *are*
getting better at that!

Cheers,
Martijn
--
My reply-to address is intentionally set to /dev/null
reply to mlievaart at orion in nl

Re: Thanks everyone! (was Re: Ada vs C++ vs Java)

[John Birch]

Martijn Lievaart wrote in message <781psh$1j1@news3.euro.net>...

>I just want to thank everyone participating in this thread for making it a
>hugely informative thread without evolving into holy wars. It seems we
*are*
>getting better at that!

Yep, I certainly learnt something! <abashed emoticon eating humble pie>

Now, anybody know of a good embedded C++ compiler? Last time I used C++ it
was MS version 7 in an embedded environment! Perhaps that's soured my
grapes. I keep hearing things about gcc, is it any good for hard embedded
work?

regards John Birch

(at home - please send e-mails [if necessary] to johnb at invision dot co
dot uk)

Re: Thanks everyone! (was Re: Ada vs C++ vs Java)

[Bob Cousins]

In comp.arch.embedded, John Birch wrote:

>Martijn Lievaart wrote in message <781psh$1j1@news3.euro.net>...
>
>>I just want to thank everyone participating in this thread for making it a
>>hugely informative thread without evolving into holy wars. It seems we
>*are*
>>getting better at that!
>
>Yep, I certainly learnt something! <abashed emoticon eating humble pie>
>
>Now, anybody know of a good embedded C++ compiler? Last time I used C++ it
>was MS version 7 in an embedded environment! Perhaps that's soured my
>grapes. I keep hearing things about gcc, is it any good for hard embedded
>work?

This reminds me of Peter Ustinov's answer to the question "Which film did you
most enjoy making?", the answer being "my next one".

If you can apply what you have learned from other languages to writing a better
program in a new language, you've cracked it.
-- 
Bob Cousins, Software Engineer.
http://www.lintilla.demon.co.uk/
"We demand that we may, or may not, be philosophers!"

Re: Thanks everyone! (was Re: Ada vs C++ vs Java)

[Scott Johnson]

John Birch wrote:
> 
> Martijn Lievaart wrote in message <781psh$1j1@news3.euro.net>...
> 
> >I just want to thank everyone participating in this thread for making it a
> >hugely informative thread without evolving into holy wars. It seems we
> *are*
> >getting better at that!
> 
> Yep, I certainly learnt something! <abashed emoticon eating humble pie>
> 
> Now, anybody know of a good embedded C++ compiler? Last time I used C++ it
> was MS version 7 in an embedded environment! Perhaps that's soured my
> grapes. I keep hearing things about gcc, is it any good for hard embedded
> work?


Works fine for me.  Of course, my "embedded" environment is a 
PowerPC machine with 32MB of RAM, running vxWorks.  :)

gcc has the advantage of source, so porting it to different environments
(assuming a backend for the architecture in question) isn't hard.
Full ANSI support isn't quite complete as of 2.8.x (egcs gets a little
better), but this probably isn't an issue with a hard embedded
environment.

Keep in mind that C++ requires a bit more support from the
implementation (in other words, the OS or whatever you have that acts
like an OS) than does C.  With embedded targets, the compiler driver
cannot resolve static constructors and destructors automagically like
it can on a peecee or Unix box; you will have to arrange for this.
Dealing with exceptions may also be a bit problematic.  OTOH, if you
dispense with the gargantuan standard libraries (or at least the 
parts of it that get really big), the generated code shouldn't
be significantly worse than a C compiler.

Scott

Re: Ada vs C++ vs Java

[Dr. Hubert B. Keller]

Reading a lot of the mails raised up to me the idea that
             a lots of the people talking about Ada don't know
             a lot about tasking especially with Ada.
Sorry, but this idea was really coming up.

Hubert B. Keller
PS: I'm working since 1984 with ADA in many projects with intensive tasking
(basically SRT).
      For hard real time see Annex D and the Ravenscar Profile
(www.aonix.de)

Re: Ada vs C++ vs Java

[Bob Cousins]

In comp.arch.embedded, Dr. Hubert B. Keller wrote:

>Reading a lot of the mails raised up to me the idea that
>             a lots of the people talking about Ada don't know
>             a lot about tasking especially with Ada.

95 % of people who advocate a language haven't actually used other languages
they compare it against, but have only seen briefly or heard about them. In my
experience C and C++ advocates are least likely to know other languages
sufficently well to justify any opinions.

[Removed some irrelevant groups]
-- 
Bob Cousins, Software Engineer.
http://www.lintilla.demon.co.uk/
"We demand that we may, or may not, be philosophers!"

Re: Ada vs C++ vs Java

[Roedy Green]

On Fri, 22 Jan 1999 18:48:23 GMT, bob@lintilla.demon.co.uk (Bob
Cousins) wrote:

>95 % of people who advocate a language haven't actually used other languages
>they compare it against, but have only seen briefly or heard about them. In my
>experience C and C++ advocates are least likely to know other languages
>sufficently well to justify any opinions.

I guess you could put it mathematically the degree one one's certainty
that a given lanuage is best of all purposes is inversely proportional
to the number of languages one has used.

It works pretty much the same was as religion.


For the JAVA GLOSSARY and the CMP Utilities: <http://mindprod.com>
--
Roedy Green,  Canadian Mind Products 
-30-