Teaching new tricks to an old dog (C++ -->Ada)

[Jerry Coffin]

Dr. Adrian Wrigley wrote:

[ ... ]

one snippet from a Google search: [ ... ]
"C++ programs typically have roughly six times the lifetime ownership
costs of equivalent programs written in C, Ada or Fortran, and fewer
than one third of programming projects begun in C++ are completed."

Unfortunately, quotes like this tend to mean a lot less than they
initially look like they might. Considering the first item: what
constitutes "equivalent programs"? I've never in my life seen two
programs (at anything beyond the VERY most trivial level) that were
actually equivalent -- even when/if the same person/people attempt(s)
to reproduce an identical program, it's nearly inevitable that during a
rewrite at least a few things change, sometimes for the worse (second
system effect) and sometimes for the better (more experience,
refactoring, etc.)

Now, in fairness, I should add that in my own experience C++ programs
_have_ had higher long-term costs than (initally) roughly similar
programs I've written in other languages. That sounds bad, but in
reality it's exactly the opposite -- the reason the others had lower
long-term costs was that they were enough less maintainable that they
were discarded and replaced much sooner. Doing some looking through my
company database it looks like our C++ programs have cost just under
twice as much on average as their counterparts written in other
languages -- but their average useful lifetime has been better than
three times as long (so far -- most of the C++ programs are still in
regular use).

The real measure is not the long term cost of a particular program, but
the long-term cost of carrying out a particular task. Unfortunately,
that's generally much more difficult to measure, and (worse) attempts
at measuring it are much less common.

Looking at the second part, we get an even worse problem. I would
postulate that a typical programming project is basically a business
venture. Studies have shown for _years_ that the vast majority of
business ventures fail -- but most fail simply due to inadequate
startup capital, so they simply can't stay in business long enough to
become profitable.

Programming languages fit into this fairly nicely: when Ada is chosen,
it's mostly by a relatively large company with adequate funding that
hires experienced managers, has a clear goal and a reasonable idea of
how to reach it.

At the opposite end of the spectrum, if you look at an unfunded startup
consisting of one or two guys straight out of college who are certain
that in six months they're going to become billionaires by creating the
next Netscape, their language of choice is most likely Java, with C++
in second place, and Ada basically not even in the picture at all.

It takes only minimal business acumen to figure out which project is
more likely to succeed -- but even less to realize that IF each had
chosen the other language, the answer would be unaffected.

 

[Martin Krischik]

You can't just go willy-nilly making base classes virtual.
For one thing, constructor arguments for virtual bases must
be provided by the most derived class.

I don't consider that to be a disadvantage - I do it anyway.

For another, why do
you imagine that there is something wrong with having two
separate "C" base classes in your example?

That of course depends on the situation. In so far is C++ right to provide
both options. I only criticise the default which is based on speed and not
on what is right most of the time.

From my 10+ years of experience I know that you need virtual inheritance in
95% of the cases where a diamond inheritance tree is involved. However,
because static inheritance is default 99.9% of all inheritance is static.

And worse: If it is a 3rd party lib you can't even fix it.

Martin

 

[Martin Krischik]

In this type of discussions people always does the same: in the langauage
they like they talk about all features they know and the most recent
version of the language is considered, in the language they dislike, only
the most commonly used features are taken into account, and 'but many
people still use old versions' is mentioned. In a language the best
paractices are suppossed to be used for anything in the world, in the
other one talk about the worse programmers and programs they have seen.

You are right. Most languages come together now: Fortran 2003 ist object
orientated, C99 got dynamic arrays, Ada 2005 got an STL clone. And to most
of us none of it is available right now :-( .

Mind you: I have got all three ISO standards for Ada, C and C++. And I do
take an interest in all of them.

And the "never learned any new tricks" is taken from real live experience.
Not a theoretical argument: It actualy realy happend.

Martin

 

[Martin Krischik]

Of course it does. Diamond diagram is as valid for interfaces as for
implementations (data). If you allow interfaces to be derived from other
interfaces (I don't know if Ada 2005 will), then:

C -> A (both are interfaces)
C -> B (both are interfaces)

Let X implements both A and B. Now: A's C of X = B's C of X?

Where is the problem? There is no data in C, C only consists of its tag (or
virtual function table). But the tag (or virtual function table) is a
singelton and A's C and B's C are both the same.

And even if the tag is physically copied - after elaboration it's constant
as well - so even than it's only a waste of space but still makes not
difference.

And that is indeed the way Java gets around the MI problems.

Martin

 

[Martin Krischik]

Martin Krischik wrote:

I did not thought up the code, I just typed a quick, limited
demonstration.

Well, I actualy got the working version ;-) - well array is a bit out of
date (no namespaces for the IBM compiler) an need fixing.

Martin

 

[Dmitry A. Kazakov]

Where is the problem? There is no data in C, C only consists of its tag (or
virtual function table). But the tag (or virtual function table) is a
singelton and A's C and B's C are both the same.

That's the point, whether they be same or not is to be defined solely by X,
not per language design.

Forget about data, it is irrelevant. Primitive operations are data and data
are primitive operations. If C has abstract Foo, then may/shall X implement
X.A.C.Foo and X.B.C.Foo differently? Is it the same primitive operation of
X or is it two different operations? Or else, will Foo's dispatching table
split into two branches or not?

The answer is: it depends on the design. Because both variants are needed.

 

[Martin Krischik]

--->> At first, in this and other messages you had set the follow-ups to
--->> comp.lang.ada which means we can not follow the discussion
--->> anymore!]

Sorry about that. Knode is a bit restrictive on cross posts.

ISO C++ defines no threading facilities so far (but *care has been
taken* to be easy implementing the algorithms and container operations
as thread-safe).

The only multithreading I know is the .NET lock-based multithreading. I
can't understand how in such an environment you can expect to catch
exceptions reliably. I can only assume that Ada's built in
multithreading mechanism is not lock-based.

Ada has two multithreading paradigms implemented. There are protected types
which are lock based (but you don't start new threads with them) and task
types which are rendezvous based (these are the types which actualy start
new threads):

http://en.wikibooks.org/wiki/Programming:Ada:Tasking

In rendezvous based mutitheading two task meet at rendezvous points (hence
the name). An exeptions happening inside a rendezvous points need to be
handled by both theads participating at the redevous.

Also: expections happening inside the "contructor" (C++ talk - the Ada terms
are different) of an task type need to be handeled by the originating
thread. Reason: the newly created thread is ready the handle exeptions
since it is only in its contruction phase.

At first I it was quite difficult for me to understand rendezvous based
multithreading - I was only used to lock based multithreading from C (OS/2)
C++ (OCL) and Java (java threads). But once I understand how it works I
found it far easier to use and more stable in respect of dead locks. It
also works with all all operating system I know of.

But I think it would be quite a challenge to create rendezvous based
multithreading on top of C++ templates - and yet keep it easy to use for
the programmer.

With Regards

Martin

 

[Martin Krischik]

That's the point, whether they be same or not is to be defined solely by
X, not per language design.

Forget about data, it is irrelevant. Primitive operations are data and
data are primitive operations. If C has abstract Foo, then may/shall X
implement X.A.C.Foo and X.B.C.Foo differently? Is it the same primitive
operation of X or is it two different operations? Or else, will Foo's
dispatching table split into two branches or not?

The answer is: it depends on the design. Because both variants are needed.

Yes, I see your point and foregot something here (silly me): At least one A
ore B need to be an interfaces as well (If we consider the Java approch).
And that resolves is:

If A is interface than X.A.C.Foo
If B is interface then X.B.C.Foo
If A and B are interfaces then X.Foo

Whatever the situation there is only one Foo.

Of course I do see the advantages of full MI as well.

Martin

 

[Dr. Adrian Wrigley]

On Thu, 24 Mar 2005 22:28:22 -0800, Jerry Coffin wrote:

....

Programming languages fit into this fairly nicely: when Ada is chosen,
it's mostly by a relatively large company with adequate funding that
hires experienced managers, has a clear goal and a reasonable idea of
how to reach it.

I was particularly focusing on large software projects. These always
have high levels of resources - perhaps $100m+. Something like
a Social Security administration system, or an Air Traffic Control
system. The stakeholders really can't afford to have projects
collapsing at the rate of 50%-70%.

At the opposite end of the spectrum, if you look at an unfunded startup
consisting of one or two guys straight out of college who are certain
that in six months they're going to become billionaires by creating the
next Netscape, their language of choice is most likely Java, with C++
in second place, and Ada basically not even in the picture at all.

It takes only minimal business acumen to figure out which project is
more likely to succeed -- but even less to realize that IF each had
chosen the other language, the answer would be unaffected.

You are saying that the large software projects have a significantly
lower failure rate? And this is obvious to those with business
acumen? And obvious that the large project's success is independent
of the language choice?

I have not come across any studies that support these "obvious"
findings. But I haven't looked into this very much, and I'd
be pleased to have pointers to such studies.

Curiously, if the C++ community says language choice is irrelevant
to project success, but the Ada community says it matters, perhaps
managers should always hedge their bets by choosing Ada(?)

I was at a seminar by the project leader of the Canadian ATC system
a few years ago. He explained all the management and engineering
approaches taken to get the best outcome. He seemed very proud
to have developed one of the most robust, well budgeted, successful
projects in its class. This is contrasted to the "issues" which
have arisen in the new US ATC system, or the UK system.
At the end I asked "was language choice a factor in success and which
languages were used?". He replied that it was almost entirely Ada,
and this played a big role in the positive outcome. But he didn't
seem to want to introduce the issue in his presentation, because
it could be so controversial.

But again, this is anecdotal evidence.

More tangibly (but at the small end of the scale):

another snippet:

"In one of the few times a manager has performed the same project
several times using similarly experienced teams but with different
programming tools, the use of Ada significantly boosted project
success rates. At SUNY Plattsburgh, Professor John McCormick has
assigned the same real-time programming project to his class for nine
years."

"Working in teams of three or four, McCormick's students must write
15,000 lines of code to control a system that would need about 150
switches to operate using hardware alone. In the five years students
used C, no team completed the project -- even when more than half of
the code was provided. With Ada, however, half of the teams completed
the project before any support code had even been written. With some
support code now provided, three out of four teams finish the project."

In summary:
It simply isn't good enough for a language community to claim
language choice is irrelevant, without giving real-world evidence.
And why would such a claim attract us to the community?

If choice is claimed to be irrelevant, why focus on small-scale
issues like arrays vs. containers or contract vs. non-contract
template models?

Or to put it another way:
How come "more expressive" templates, "better exception handling",
or "less verbose" syntax is not claimed to improve project success?

Maybe I (still) don't get it.

 

[Dmitry A. Kazakov]

But I think it would be quite a challenge to create rendezvous based
multithreading on top of C++ templates - and yet keep it easy to use for
the programmer.

We did it in our proprietary C++ library, and without any templates, BTW.
The pattern is:

1. A rendezvous queue type either to derive task objects from or to mix-in.
A task periodically polls the queue, it can also wait for a queuing event.

2. An abstract rendezvous object type to queue. User-defined rendezvous
objects were derived from there. When rendezvous happened a virtual method
was called.

We supported timed calls, and even a kind of re-queuing to mimic this
extremely useful feature of Ada 95.

Of course it is not as easy to use it as Ada's rendezvous, but it is usable
and works fine. The advantages rendezvous have over queues are that as in
Ada there is no need to marshal parameters here and there, no need in any
locks, no problem to have results.

The most difficult problem is exception handling. In Ada, rendezvous
exceptions are propagated in both caller and callee. This is impossible to
mimic in C++, because there seems no way to throw same-as-this exception in
C++. So we had to fuse all exceptions on the caller's side ...

 

[Martin Krischik]

We did it in our proprietary C++ library, and without any templates, BTW.
The pattern is:

1. A rendezvous queue type either to derive task objects from or to
mix-in. A task periodically polls the queue, it can also wait for a
queuing event.

2. An abstract rendezvous object type to queue. User-defined rendezvous
objects were derived from there. When rendezvous happened a virtual method
was called.

We supported timed calls, and even a kind of re-queuing to mimic this
extremely useful feature of Ada 95.

Of course it is not as easy to use it as Ada's rendezvous, but it is
usable and works fine. The advantages rendezvous have over queues are that
as in Ada there is no need to marshal parameters here and there, no need
in any locks, no problem to have results.

The most difficult problem is exception handling. In Ada, rendezvous
exceptions are propagated in both caller and callee. This is impossible to
mimic in C++, because there seems no way to throw same-as-this exception
in C++. So we had to fuse all exceptions on the caller's side ...

Cool. Sad that it is not open source.

Martin

 

[Georg Bauhaus]

One difference is a 1:1 correspondence of index values and
indexed items. This suggests not using p[-1] or somearray[1]
interchangeably:

There is one named index type.
There is one named array type.
The index type is used in the declaration of the array type,
stating the set of permissible array index values.

Again, one can easily define an array container that accepts user
defined indexes.

I have not seen one so far, only some handcoded range checking,
which is not the point. Handcoded range checking does not replace
the definition of a type in terms of two other types. Note carefully:
types. Range checking is not the same thing as a type. Neither in
source text read by a human, nor in source text read by a compiler.
Whatever the language is.

In C++ terms:

namespace Adalike {

template <typename T, typename Index>
class vector {
...
};
}

Can you see the essential and important difference?
Just like std::map, Adalike::vector has two (!) non-default
parameters: one for the item type, the other for the index
type. This is the essential difference between std::vector
and Adalike::vector.

The compiler will use the information present in Index
to establish properties of the Adalike::vector type such that
Adalike::vector indexing (an operation) is based on properties
of Index (Index is a type! It is not an algorithm base on min
and max int parameters).

This has something to do with making the base types int, long, etc.
class types. When they are class types, you can invoke their
methods, derive other number types, and then you can use
their interface to build an array that is using the information
provided by int or provided by a type derived from int.

Ada:

type Year_of_Interest is new Integer range 1815 .. 1914;

type History is array (Year_of_Interest) of String;


It is not possible to express this using types in C++:

class Year_of_Interest : int { // Not C++
...
};

typedef array<Year_of_Interest, std::string> History;

(Because there is no such thing as array<typename Index, typename T>
in STL afaik. Association is characteristic of map, not of vector
etc. This is different in Ada, where association is readily availably
by associating an index type with an array in an array type
declaration.)

The philosophical question that arises is *why no one
has done it to this day*.

It has been done for associative containers only. It could be done for
array-like containers if C++ had introduced the base types as base
classes.

However I am going to make such one in some weekend (perhaps this!) to
see if I can find any real use of it. Doing it sounds really simple:


template<class T, const int MIN, const int MAX >

A solution will have this parameterization and checks:

class Array: public vector
{
// Only provide definitions for operator at() and operator[] that
// really *only* explicitly call the base ones with the proper index.
// And the few constructors doing the same, *only* explicitly passing
// the *same* arguments to the base constructors.

// Check indexing precondition Index::contains(v) in at(v) and
// operator[](v).

};

I think it is *that* simple.

O.K., I'll wait.

For more diverse things, maps are suitable (I guess in Ada too).

Maps are not needed here, in Ada and other languages supporting
different kinds of arrays. For example, why should I use

std::map<someEnum, T>,

when I can use something much more efficient to express the
same concept, and still the thing is an array, technically?
In pseudo-C++ terms, Ada *does* provide

key_type is used only in maps!

In Ada, key_type *is* used in arrays, because that's a feature
provided by the language.

This is what I'm trying to explain.


Georg

 

[Dr. Adrian Wrigley]

In C++ terms:

namespace Adalike {

template <typename T, typename Index>
class vector {
...
};
}

Can you see the essential and important difference?
Just like std::map, Adalike::vector has two (!) non-default
parameters: one for the item type, the other for the index
type. This is the essential difference between std::vector
and Adalike::vector.

The compiler will use the information present in Index
to establish properties of the Adalike::vector type such that
Adalike::vector indexing (an operation) is based on properties
of Index (Index is a type! It is not an algorithm base on min
and max int parameters).

This has something to do with making the base types int, long, etc.
class types. When they are class types, you can invoke their
methods, derive other number types, and then you can use
their interface to build an array that is using the information
provided by int or provided by a type derived from int.

Ada:

type Year_of_Interest is new Integer range 1815 .. 1914;

type History is array (Year_of_Interest) of String;


It is not possible to express this using types in C++:

class Year_of_Interest : int { // Not C++
...
};

typedef array<Year_of_Interest, std::string> History;

(Because there is no such thing as array<typename Index, typename T>
in STL afaik. Association is characteristic of map, not of vector
etc. This is different in Ada, where association is readily availably
by associating an index type with an array in an array type
declaration.)



It has been done for associative containers only. It could be done for
array-like containers if C++ had introduced the base types as base
classes.

I think this expresses a key aspect quite well.

The C++ FAQ lite has some nice explanations:

http://www.parashift.com/c++-faq-lite/containers.html#faq-34.3

A key point is that C arrays are considered 'evil' to C++ programmers.

C arrays:
1) don't have their subscripts checked
2) often need heap allocation and manual deletion
3) cannot be returned (when 'auto')
4) are rather mixed up with bug-prone pointer based code

Ada arrays almost completely eliminate these issues. Ada Arrays
are 'good' not 'evil'. The C++ response was to start again
with completely new (to C) container classes, trying to consign C
arrays to the realms of history. The problem is that C arrays
are essential to much C++ programming, because of the C libraries
commonly used, and because of obsolescent programming practices.

Curiously, "pointers are evil" and "macros are evil" too, according
to the FAQ. It's a pity that the evil wasn't destroyed or fixed
in the design of C++.

Ada has successfully (virtually) eliminated the evils of arrays,
pointers, and macros. The outcome is a language giving less choice
to programmers to use these evil ways. Maybe a C++ source code
checker (like 'lint') could prohibit the evil(?) That way, people
would be forced out of old C habits.

 

[Jerry Coffin]

Dr. Adrian Wrigley wrote:

[ ... ]

I was particularly focusing on large software projects. These always
have high levels of resources - perhaps $100m+. Something like
a Social Security administration system, or an Air Traffic Control
system. The stakeholders really can't afford to have projects
collapsing at the rate of 50%-70%.

Precisely -- you were originally discussing large projects, but nothing
in what you quoted from Google says it was doing the same. It's
_possible_ they were talking strictly about large, well-funded,
well-managed, (etc.) projects -- but nothing I saw in what you quoted
said or even suggested any such thing.

[ ... ]

You are saying that the large software projects have a significantly
lower failure rate? And this is obvious to those with business
acumen? And obvious that the large project's success is independent
of the language choice?

I'm saying that those that are well funded and carefully managed have
lower failure rates, and yes, I'm reasonably certain this is fairly
obvious. I did not say that the project's success was independent of
the language choice -- I said that in these specific cases, the
language choice was exceptionally unlikely to affect the the outcome.

Language choice is a factor, but is far from the ONLY factor, and in
the overall scheme of things is a relatively minor factor.

I have not come across any studies that support these "obvious"
findings.

It seems unlikely to me that you'd find any number of studies, no
matter how explicit the findings, to be convincing. Just for an
obvious example, Ada advocates like to point out how Boeing chose Ada
for the control systems in the 777. By contrast, Airbus is currently
using the SCADE toolset which is a C IDE (though in fairness, the
programmers do little work directly in C).

Boeing has an extremely large market share, but has recently been
relatively stagnant, and recently seems to have retreated from pushing
the envelope and moving toward relatively small projects (e.g. the
7E7). Airbus is growing (mostly at Boeing's expense) and working on
some of the largest projects of their type ever contemplated (e.g. the
A380). Looking at safety statistics on the Boeing web site at:
http://www.boeing.com/news/techissues/pdf/statsum.pdf
doesn't seem to show any major problems with reliability or safety in
the Airbus designs (and it hardly seems likely that Boeing would cover
up their competitor's shortcomings).

I'm the last to attribute these facts directly to C vs. Ada, but it
doesn't seem to indicate that using Ada is particularly crucial to
either economic or technical success in this market, which places about
as high an emphasis on reliability as any. I'd also note that SCADE is
routinely used in other high-reliability markets as well, including
other transportation and nuclear plant control.

Curiously, if the C++ community says language choice is irrelevant
to project success, but the Ada community says it matters, perhaps
managers should always hedge their bets by choosing Ada(?)

First of all, I've seen nobody claim that language choice is
irrelevant. Second, I think a claim that choosing language X will
greatly improve chances of success (at least where X is replaced by
either C++ or Ada) says a great deal about the level of zeal vs. sense
in the speaker, and very little about the languages themselves.

In fairness, I should add that in _some_ cases, language choice really
can make a huge difference -- usually when one language is oriented
quite specifically toward the problem at hand. Obvious cases would be
things like databases or symbolic math, where a language aimed
specifically at the problem domain may reduce development time by
orders of magnitude.

"In one of the few times a manager has performed the same project
several times using similarly experienced teams but with different
programming tools, the use of Ada significantly boosted project
success rates. At SUNY Plattsburgh, Professor John McCormick has
assigned the same real-time programming project to his class for nine
years."

"Working in teams of three or four, McCormick's students must write
15,000 lines of code to control a system that would need about 150
switches to operate using hardware alone. In the five years students
used C, no team completed the project -- even when more than half of
the code was provided. With Ada, however, half of the teams completed
the project before any support code had even been written. With some
support code now provided, three out of four teams finish the

project."

The next time I have a tiny project to be developed by a small team
with no experience, I'll keep this in mind.

In summary:
It simply isn't good enough for a language community to claim
language choice is irrelevant, without giving real-world evidence.
And why would such a claim attract us to the community?

TTBOMK, nobody has said it's irrelevant -- I've said it's only one of
many factors, and rarely the ultimate determining factor. I, at least,
am attracted to people who make claims that appear to be honest and
reasonable, and mostly repeled by those whose claims seem based more
religious zeal than honesty, intelligence or simply good sense.

[ ... ]

How come "more expressive" templates, "better exception handling",
or "less verbose" syntax is not claimed to improve project success?

Other factors _dominate_, but do not _exclude_ language factors.

I don't mean it as an attack on you, but you really do seem _extremely_
prone to treating things as absolutes, and IME absolutes are really
quite rare.

 

[Hyman Rosen]

It's a pity that the evil wasn't destroyed or fixed
in the design of C++.

That would have taken the "C" out of C++. It might have
made for a better language, but no one would have used it.
Like Ada

Maybe a C++ source code checker (like 'lint') could prohibit the evil(?)
That way, people would be forced out of old C habits.

Never happen.

 

[Hyman Rosen]

Or to put it another way:
How come "more expressive" templates, "better exception handling",
or "less verbose" syntax is not claimed to improve project success?
Maybe I (still) don't get it.

To claim improved project success, you have to do some pretty difficult
basic research. Most of us here are programmers, not software engineering
researchers, so most of us at best have only anecdotal evidence. Therefore
when we compare languages we do so from the basis of things that affect us
as programmers.

 

[Jerry Coffin]

jayessay wrote:

[ ... ]

Lisp macros are _not_ a preprocessor and they are _vastly_ more
capable than what people typically think of when they see/hear
"macros". Lisp macros are full code analyzing and generating
constructs.

I very specifcally said they were not in a preprocessor, and merely
that they provide capabilities similar to those available in the
preprocessor in C++. It's true that they provide considerably more in
addition, but it's more or less beside the point -- which was that Ada
provides substantially less still.

Lisp only came into the conversation at all because it was implied that
the C preprocessor was _so_ unusual that nothing else provided even
vaguely similar capabilities. The substantially more capable Lisp
macros were mentioned only to point out that my comparison was not to
something utterly unique. I certainly did not mean to imply any
particularly strong similarity between C macros and those in Lisp. As
far as that goes, most assemblers have far more macro capability as
well -- but again, it's more or less beside the point.

Robert Duff made a comment a while ago about how silly most (I would
say without much hyperbole 99+%) of the points in these threads would
be to Lisp (and Smalltalk) folks. I couldn't agree more.

As usualy, I disagree -- and I also use Lisp part of the time, and have
not only used Smalltalk, but written a fairly substantial part of a
Smalltalk implementation.

Then again, I also remember watching/listening to arguments between
people using various flavors of Lisp (before CL came along) about
things like whether it was correct to equate an empty list with
"false". IIRC, I probably used Pascal at the time, and compared to the
differences between FORTRAN IV and Pascal, these differences could have
been seen as quite trivial.

Nonetheless, I didn't and don't see the arguments as silly from either
direction. I see people who have chosen particular areas in which to
pursue their vision of perfection. While I consider it perfectly
reasonable to disagree with them, I hope I never become so
self-satisfied or condescending as to pronounce their concerns or
vision as "silly" or anything like it.

 

[Wes Groleau]

The real measure is not the long term cost of a particular program, but
the long-term cost of carrying out a particular task. Unfortunately,
that's generally much more difficult to measure, and (worse) attempts
at measuring it are much less common.

Indeed. There have been a few times that someone has actually had
an Ada group and a group with another language tackle the same
requirements. This has not happened enough times for a clear
verdict. However, I can state that in AKK the (few) cases I am
aware of, Ada was the winner each time.

 

[Guest]

A key point is that C arrays are considered 'evil' to C++ programmers.

C arrays:
1) don't have their subscripts checked
2) often need heap allocation and manual deletion
3) cannot be returned (when 'auto')
4) are rather mixed up with bug-prone pointer based code

And this doesn't even address the issues of multi-dimensional
arrays, which, in Ada, are true multi-dimensional arrays.

type Day is (Mon, Tue, Wed, Thu, Fri, Sat, Sun);
type Index is range 1..31;
type TwoDMatrix is array(Day, Index) of Boolean;

or if you wish,

type DayVector is array(Day) of Boolean;
type Month is array(Index) of DayVector;

and one is not limited to two dimensions for true arrays.

type ThreeDMatrix is array(1..20, 1..400, 1..2000) of Integer;
TDM1 : ThreeDMatrix;

...

for TDM1'Range(1)
loop
for TDM1'Range(2)
loop
for TDM1'Range(3)
loop
-- Do something to Integer element
end loop;
end loop;
end loop;

where the parenthetical values specify which dimension is being
evaluated.

Multi-dimensional array processing in Ada is so easy to do. Moreover,
it is easy, no trivial, to create generic templates to take advantage of
this capability to create portable, generalized, and and easy to use
generic components. Easier, I think, than the equivalent capability
in most other languages, especially C++.

Richard Riehle

 

[jayessay]

On Thu, 24 Mar 2005 17:59:39 -0500, jayessay wrote:

...

*I* think the evidence is now very strong that programming language
choice *is* massively important for overall success of large projects.

I concur completely. Those who think otherwise largely fall back on
the old "Turing equivalent" argument which, since all the languages
under discussion are TE, is basically irrelevant.

The problem is a lack of scientific method in determining this,
resulting in a big analytical problem with (also massive)
confounding factors.

This is also true, but it is not something that will likely ever
change due to massive economic reasons. I suspect you understand this
by your "(..massive) confounding factors" comment.

one snippet from a Google search:
"Gartner is now saying 70% of all Java projects so far have failed"
but only "40% of all projects fail."

One of the problems here is that the vast majority of Java projects
are handled mostly by a horde (colony?) of "code monkeys".
Personally, I think Java sucks, but I don't think you can conclude
much from those stats though.

and
"C++ programs typically have roughly six times the lifetime ownership
costs of equivalent programs written in C, Ada or Fortran, and fewer
than one third of programming projects begun in C++ are completed."

This is _much_ more believable, but again such stats are intrinsically
suspect.

Can anybody post links quantifying how much better C++ is than C or
Ada (in terms of project cost and outcome)?

Sure, but again all these things are either a) toy examples, or b)
completely uncontrolled experiments leading to c) dodgy information.

Of course I enjoy programming in C/C++ very much, having

C, sure. C++? You have my sympathies.

total debugging time so much shorter in Ada (I've almost

I'm here because I still do follow Ada and cla a bit as I always
thought it was at least reasonbly well thought out. At the moment I
have the great fortune of using Common Lisp.


/Jon