wtwolfe@hubcap.clemson.edu (Bill Wolfe) (03/15/90)
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
jharkins@sagpd1.UUCP (Jim Harkins) (03/16/90)
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."
macrakis@marat.osf.fr (Stavros Macrakis) (03/20/90)
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