endrizzi@sctc.com (Michael Endrizzi ) (08/15/90)
I walked into my current job an Ada addict. The people I work with
are all pretty much C/Unix hacks, so I thought I had the world
at my beckon. I watched and laughed in horror as they passed
untyped pointers, randomly recompiled modules because they
"knew" which ones were out of date, used pointer arithmetic
because C bit-fields did not align properly, etc, etc.
Reality hit.
I won't mention the name of the vendor in this column, but we
purchased a moderately priced Unix Ada environment. Word had
it that this package was "OK" but not great. No such luck.
I am living in a nightmare of internal compiler errors and
inconsistent data base errors.
This is why the survival of Ada is at stake:
1)Control
2)Cost
3)Complexity
1)Control: Programmers and our associated egos like to be in control
of our destinys. On paper, Ada is a powerful tool that automates
many of the manual checks (recompilation, type checking) that
other languages lack. By using this tool, we give up control.
Big egos don't like to give up control. And when that tool
doesn't work right, it's like being in a speeding car with
not steering wheel driving in the mountains.
C/Unix on the other hand is a hackers tool. If this don't
work right...well we all know how easy it is to flip a
few bits here and there to make it work.
2)Cost: Quality Ada environments are expensive and resource hogs.
You can't just sit at home and hack into the night on your
Mac/PC. You must have your $100,000 Rational with 200 Gigs
of storage parked in your basement to get a true Ada high.
I know on our system, I must balance elegance with "will
the damn thing even compile, fit on our disks, crowd out
other users, etc".
C/Unix on the other hand is basically free. GCC is probably
one of the highest quality C products and it is free. Unix
comes standard on some systems. Compile times, storage
requirements are reasonable in a multi-user environment.
3)Complexity: On paper Ada is addictive, elegant, true
solution to multi-person life-cycle software engineering.
In reality, I know of only 2 products that are usable:
1) Rational
2) DEC
(there might be others, but these are the ones most
talked about and I am familiar with). Ada merges several
technologies --multi-user database, parallel processing,
software engineering, compilers, user interfaces, etc.
The only way to support the integration of these technologies
is to have a platform that allows them to talk to one another.
The platform must either be customized (Rational) or of
high quality (DEC/VMS). Unix was/is/will always be a disaster
This then goes back to the cost issue.
Also, very few vendors are able to master these technologies.
Either they are too small to afford it or the egos are so
damn huge in the individual fields that they can't bring the
team together to build a quality product.
I am done rambling. I learned my lesson. Ada taught me many
great concepts and but also the realities of life.
au revoir Ada, :-( (sniffle,sniffle)
Dreez
=================================================================
=================================================================
Michael J. Endrizzi
Secure Computing Technology Corp.
1210 W. County Road E #100
Arden Hills, Mn. 55112
endrizzi@sctc.com
(612) 482-7425
*Disclaimer: The opinions expressed above are not of my employer
but of the American people.
=================================================================
=================================================================jcallen@Encore.COM (Jerry Callen) (08/16/90)
In article <1990Aug15.151935.8848@sctc.com> endrizzi@sctc.com (Michael Endrizzi ) writes: >This is why the survival of Ada is at stake: > > 1)Control > 2)Cost > 3)Complexity > >1)Control: Programmers and our associated egos like to be in control >of our destinys. On paper, Ada is a powerful tool that automates >many of the manual checks (recompilation, type checking) that >other languages lack. By using this tool, we give up control. >Big egos don't like to give up control. And when that tool >doesn't work right, it's like being in a speeding car with >not steering wheel driving in the mountains. I don't really view type checking as a loss of control; rather, as you pointed out, it automates an otherwise tedious part of my job. The ability to override the checking is there when you really need it, via unchecked_conversion, pragma interface, and (if you're lucky enough to be using a system supports it) machine code insertions. My ego has survived, and no one has ever accused me of having a small ego! :-) It _is_ really annoying when the tools let you down. In my experience, though, this happens pretty rarely, and I'd rather put up with the few failures than live without the conveniences. >C/Unix on the other hand is a hackers tool. If this don't >work right...well we all know how easy it is to flip a >few bits here and there to make it work. Actually, Ada/Unix can be a hacker's tool, too. At least, that's how _I_ often treat it. Judicious use of the overrides I mentioned above allow me to dig as deep a hole for myself as I wish. :-) >2)Cost: Quality Ada environments are expensive and resource hogs. Sigh. Some myths never die. I'm currently using Ada on an Opus PM8000 (Moto 88K board in a stock AT clone). Ada compilations zip right along; I can recompile about 100 medium-sized units (averaging a few hundred lines each) in about 10 minutes. I share this machine with several other users also doing Ada compilations. You'ld have to put a gun to my head to get me to move onto a VAX/VMS system and off this little PC (hey, this is _unix_, not VMS!). >C/Unix on the other hand is basically free. GCC is probably >one of the highest quality C products and it is free. No argument here. Gada, anyone? >Unix comes standard on some systems. Compile times, storage >requirements are reasonable in a multi-user environment. See above. >3)Complexity: On paper Ada is addictive, elegant, true >solution to multi-person life-cycle software engineering. >In reality, I know of only 2 products that are usable: > > 1) Rational > 2) DEC > >(there might be others, but these are the ones most >talked about and I am familiar with). I have biases I'd rather not reveal, but I think this list could be expanded. I'm reasonably happy with the system I'm using right now. (Actually, I don't much like some of the internals, but...) I have been happy with another system that actually has a more complex (but, surprisingly, much more usable) library system. >The platform must either be customized (Rational) or of >high quality (DEC/VMS). Unix was/is/will always be a disaster Hey! You knockin' Unix, buster? Themz fightin' words! :-) Nearly ALL of my Ada experience (aside from some unpleasantness involving large bluish machines...) has been on Unix. I love it. >Also, very few vendors are able to master these technologies. >Either they are too small to afford it or the egos are so >damn huge in the individual fields that they can't bring the >team together to build a quality product. Lots of truth to these words. Anyone who tries to tell you that an Ada compiler isn't more complex than a C compiler may also try to sell you a bridge. But some vendors _are_ doing it, or at least coming close. The technology is maturing. I think there was a tendency on the part of early Ada implementors to produce over-engineered systems that were, in fact, fragile resource hogs. But the shake-out is happening; the surviving vendors keep refining their products, and the compilers get better and better. Unfortunately, the bad first impressions linger, and not everyone burned by a bad compiler is willing to put up the bucks for a newer, better compiler. >I am done rambling. I learned my lesson. Ada taught me many >great concepts and but also the realities of life. > > au revoir Ada, :-( (sniffle,sniffle) Aw, shucks, don't give up on the old gal yet! :-) -- Jerry Callen jcallen@encore.com
eberard@bse.com (Edward V. Berard) (08/16/90)
In article <1990Aug15.151935.8848@sctc.com>, endrizzi@sctc.com (Michael Endrizzi ) writes: > > This is why the survival of Ada is at stake: > > 1)Control > 2)Cost > 3)Complexity > > 1)Control: Programmers and our associated egos like to be in control > of our destinys. On paper, Ada is a powerful tool that automates > many of the manual checks (recompilation, type checking) that > other languages lack. By using this tool, we give up control. This is an interesting observation. While I will admit that there may be some things which are easier to accomplish in C (and, of course, many things which are easier to accomplish in Ada), Ada provides you with all the control that C offers you -- and, very probably, much more. Just as an inexperienced C programmer might believe that some things are impossible -- or incredibly difficult -- in C, so would an inexperienced Ada programmmer think that some things were "impossible" in Ada. > And when that tool > doesn't work right, it's like being in a speeding car with > not steering wheel driving in the mountains. I very much agree. > C/Unix on the other hand is a hackers tool. If this don't > work right...well we all know how easy it is to flip a > few bits here and there to make it work. As someone who uses both C and Ada, and knows quite a few "C hackers," I think you are indulging in fantasy. I have seen plenty of C programs which destroyed not only themselves, but also their surrounding environment because the programmer "flipped a few bits here and there." Incompetence is programming language independent. > 2)Cost: Quality Ada environments are expensive and resource hogs. > You can't just sit at home and hack into the night on your > Mac/PC. You must have your $100,000 Rational with 200 Gigs > of storage parked in your basement to get a true Ada high. > I know on our system, I must balance elegance with "will > the damn thing even compile, fit on our disks, crowd out > other users, etc". Years ago I wrote an article about the problems with validated Ada compilers. The average quality at the time (5 years ago) was not all that great, but there were still some superstars. Today, with over 50 vendors particpating, the quality has improved noticeably. I _am_ at home at night programming (not "hacking") on my Mac with Ada, and using 2 different validated Ada compilers for the Mac OS. I am currently attempting to write code which deliberately breaks the Ada compilers I am using, and I am having nowhere near the problems you are having. (I might add that I am also _not_ using the same compiler vendor you are using.) > C/Unix on the other hand is basically free. GCC is probably > one of the highest quality C products and it is free. Unix > comes standard on some systems. Compile times, storage > requirements are reasonable in a multi-user environment. Please don't get sucked into the classic apples and oranges comparison of C and Ada systems: 1. If the most ardent Ada hater will grant that Ada provides far more capabilities than does C. (In fact, they often use this as an argument against Ada.) 2. C compiler vendors do not have to (re)validate their compilers. Validation does cost. 3. The marketplace for C compilers is greater than the marketplace for Ada compilers. The size of the market does indeed influence the cost of the product. (You, of course, know that C is almost 10 years older than Ada.) > 3)Complexity: On paper Ada is addictive, elegant, true > solution to multi-person life-cycle software engineering. > In reality, I know of only 2 products that are usable: > > 1) Rational > 2) DEC As I said before, your experience is limited. I happen to like both of the systems above, but others are at least acceptable. When I was teaching C, I used to have to assure some students that all C compilers were not incredibly buggy, and that not all C compilers generated huge object files. I explained to them that there were many C compiler vendors, and that quality varied widely. Even with a programming language which has been around for nearly 2 decades, new vendors constantly repeat the mistakes of the past. > Unix was/is/will always be a disaster > This then goes back to the cost issue. No comment. -- Ed ---------------------------------------------------------------------------- Edward V. Berard | Phone: (301) 353-9652 Berard Software Engineering, Inc. | FAX: (301) 353-9272 18620 Mateney Road | E-Mail: eberard@bse.com Germantown, Maryland 20874 | ----------------------------------------------------------------------------
endrizzi@sctc.com (Michael Endrizzi ) (08/16/90)
eberard@bse.com (Edward V. Berard) writes: >course, many things which are easier to accomplish in Ada), Ada >provides you with all the control that C offers you -- and, very >probably, much more. Just as an inexperienced C programmer might I disagree for a different reason. In C, the user is responsible for system build. In Ada, the library and assoc tools are responsible for system build. If the library is corrupt, if the tools don't work, you have lost control to the Ada environment. This is not true with C. Also, you are provided with a package that is shut tight with limited private types and is a central module used by the whole system. You need to have visibility to some data object in that package. Proper software engineering would require you to create a new routine. Reality says, "If you cause a recompilation of the whole system, you will piss off 20 programmers who are trying to work on a stable system". C let's you hack it in. You gain control. I'm NOT advocating this approach. I see it happen all the time and I get the willys. I'm just saying it is an advantage (puke ugh gag). >"C hackers," I think you are indulging in fantasy. I have >seen plenty of C programs which destroyed not only themselves, You misread my statement. I agree with you completely. >Please don't get sucked into the classic apples and oranges >comparison of C and Ada systems: I don't think that I am. I am trying to convince my company to switch from a glorified assembler "C" to a real software engineering tool. I have to compare the advantages/disadvantages of the two. Right now I don't have any advantages to show them. For those of you who don't know Ed, if you ever meet him ask him for a reference for some literary material. He will quote you book, paragraph, page, section, author, year, etc. Never would play poker with that man. Dreez ================================================================= ================================================================= Michael J. Endrizzi Secure Computing Technology Corp. 1210 W. County Road E #100 Arden Hills, Mn. 55112 endrizzi@sctc.com (612) 482-7425 *Disclaimer: The opinions expressed above are not of my employer but of the American people. ================================================================= =================================================================
vestal@SRC.Honeywell.COM (Steve Vestal) (08/18/90)
>In article <12490@encore.Encore.COM> jcallen@Encore.COM (Jerry Callen) writes: > [ massive quantities of stuff deleted ] > No argument here. Gada, anyone? I heard a Gnu Ada rumor awhile ago. Does anyone have any reliable information about this? Steve Vestal Mail: Honeywell S&RC MN65-2100, 3660 Technology Drive, Minneapolis MN 55418 Phone: (612) 782-7049 Internet: vestal@src.honeywell.com