Re: The trouble with Ada... (60 lines)

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!csc.ti .com!tilde.csc.ti.com!mksol!mccall@ucbvax.Berkeley.EDU (fred j mccall 575-3539]

In <92Sep22.205921edt.47893@neat.cs.toronto.edu> tlai@cs.toronto.edu (Tony Wen 
Hsun Lai) writes:

>In article <1992Sep22.172353.23907@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com
 (fred j mccall 575-3539) writes:
>>In <15467@suns4.crosfield.co.uk> pdg@crosfield.co.uk (paul goffin) writes:
>[stuff deleted]
>>You can 'hack' in any language, and bad code
>>can be written in every language.  Convincing yourself that Ada is
>>some kind of 'magic bullet' is a good way to produce some bad code. 
>>
>>>In Ada, those coding errors are quickly exposed by the compiler.
>>>Worse, it's actually difficult when using Ada to write any code
>>>at all if you don't have a very good idea about the total
>>>design.  That means you have to address the "difficult bit" first.
>>>(I think that's what Ada was all about!)
>>
>>Not at all.  You do it wrong just the way you would do it wrong in C;
>>divide the problem into sub-parts and then do the easy ones.

>But in practice, different languages often suggest different styles or
>different approaches to solving problems, so the types of bad code that are
>prevalent will be different.  Also, different language communities have
>different mentalities; the "superhacker" mentality is presumably harder
>to find among Ada programmers than C programmers.  A language isn't
>completely responsible for the programmers' mentalities, but it does have
>an effect.

Are you suggesting that you let language impact your design?  How
Politically Incorrect of you!  :-)

Anyway, I don't think the 'superhacker' mentality is any less
prevalent in Ada -- it is just justified differently.  After all, how
many people have you heard assert that SIMPLY BECAUSE THEY ARE USING
ADA they will not have this or that error?  Sounds like an
unreaasonable faith in a 'magic bullet' to me; just another wya to
justify the 'superhacker' syndrome.

Yes, language will somewhat impact your approach to a problem, but
this should happen only insofar as taking into account SHORTCOMINGS of
the language is an impact.  This is another one of those
mythology-breaking things.  The 'popular wisdom' says that
requirements, design, and implementation should be separate (this is
changing as people realize that making software is done best as an
iterative process, where the stages overlap and are periodically
revisited).  However, it does you little good to come up with a great
design that meets the requirements in theory, but which is so
difficult (or impossible) to implement in the language you have to use
that you would have been better off doing things some (theoretically)
less-optimal way.

The point, of course, is that good code is possible in all languages.
Likewise bad code.  Insisting that a LANGUAGE is better without
specifying WHO and WHAT is to be produced is simply a semantically
null statement.

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.