Ada, Eiffel, & language evolution

Ada, Eiffel, & language evolution

[Bill Wolfe]

From recent e-mail (an Eiffel user): 
> Ada is some sort of dead end. It has nice
> abilities for data abstraction and is certainly a lot better than
> much else. But it hasn't dynamic binding and inheritance, and I
> fear for the result if you throw that in afterwards. Then you
> will end with old features that are just obsolete.

   There is a great need for a single production programming language 
   which supports good software and code engineering practices.  Ada's
   designers were the first to do something serious about it.  There is
   also the need to ensure that this language is modernized so that it
   does not become obsolescent, and Ada should do this as part of its
   controlled revision process.  If the language can revise itself often
   enough to incorporate new developments, yet be stable enough to keep
   up the incentive to make an investment in the current version, then
   it will have done everything that can reasonably be asked of it.

   It seems a little unfair to criticize Ada before its first opportunity
   to demonstrate its ability to incorporate new ideas (Ada 9X).  I know 
   that Eiffel and C++ are very much on the minds of the people who are
   part of the 9X revision team, and I think they should be given a fair
   chance before we decide that Ada is some sort of dead end.  It may in
   fact be the way to reach the kind of standardized, controlled evolution
   we need.  If Ada can't meet the need, and the rationale doesn't hold up,
   then OK, maybe we need to seek another solution and maybe Eiffel will be
   the answer.  But I have confidence that the Ada 9X designers will do a
   good job, and I know of no reason to assume otherwise.  In the meantime,
   both Ada and Eiffel can profit from each other's experiences.  


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: Ada, Eiffel, & language evolution

[Jim Harkins]

In article <8380@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes:
>   There is a great need for a single production programming language 
>   which supports good software and code engineering practices.

Yep, and there is great need for a single type of automobile.  Any idiot can
see that not only is it extremely dangerous for a person to go from driving
a Hyndai Excel to a Ford Aerostar, as a nation we are wasting an awful lot
of time both in learning new skills and in designing automobiles that differ
in several respects.  I think a good compromise would be the Ford Escort.
It's cheap, about $10,000, can seat 4 comfortably, can easily do 55 MPH,
gets about 25 MPG, and the back seat folds down so it can double as a pickup.
It's intuitively obvious to the most casual observer that anyone who
disagrees with this is for mayhem and bloodshed on our nations highways.

I think somebody said it best when they said that it's silly to think 1
sledgehammer fits all, and the procurement of a B2 bomber is fundamentally
different than the procurement of a hammer.  Same with software, I don't
think there will ever be a language where 1 size fits all.  But what do
I know, I'm one of those C programmers with a cavalier attitude anyway.


-- 
jim		jharkins@sagpd1

"My hope is that we can use tariffs to force Japan to open their markets to
 imported goods.  My fear is I'll be forced to buy lousy American made stuff."

Re: Ada, Eiffel, & language evolution

[Stavros Macrakis]

In article <668@sagpd1.UUCP>, jharkins@sagpd1.UUCP (Jim Harkins) writes:
> In article <8380@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill
Wolfe) writes:
> >   There is a great need for a single production programming language 
> >   which supports good software and code engineering practices.
> 
> Yep, and there is great need for a single type of automobile.  Any idiot can
> see that not only is it extremely dangerous for a person to go from driving
> a Hyndai Excel to a Ford Aerostar, as a nation we are wasting an awful
lot ...

Although Bill Wolfe is going a bit far, standardization certainly has a
lot going
for it.  As a matter of fact, your automotive analogy is an interesting one.

Consider that all of the following elements on a car are standardized (modulo
left- versus right- hand drive):

	Placement, color, intensity of all external lights.
		(shapes and sizes have some variation)

	Placement and general shape and function of:
		steering apparatus
		braking apparatus
		acceleration apparatus
		clutch apparatus (ifdef)
		turn signal

		basic instrumentation

	Others have two or three standards (isn't it annoying?):
		how to turn on and adjust the lights
		parking/emergency brakes
		gearshift
		horn

Isn't it nice to know that whether you're driving a two-cylinder or a
twelve-cylinder
sedan, station wagon, convertible, pickup truck, ...  With two-wheel or
four-wheel
drive ...  Made in North America, Europe, or Japan ...  with a front-
middle- or rear-
motor and front- rear- or four-wheel- drive, etc. etc.

Isn't it nice that you don't have to relearn the basics?  Isn't it nice
that you can
drive your Hyundai Excel and your Ford Aerostar with the same basic
reflexes?  Isn't
it nice that everyone can tell when you want to turn left and when
you're braking?

Changing even one element can cause a lot of confusion (I almost got into an
accident because some car had its parking brake where the clutch belonged).

This is obviously not a proof that we should standardize on any one programming
language, however I think it IS a demonstration of the value of
standardization.

	-s