Re: True faiths ( was Re: The true faith )

[Richard Riehle <richard@adaworks.com>]

Bruce Hoult wrote:

> In article <3C4DE2F3.9020904@mail.com>, Hyman Rosen <hyrosen@mail.com>
> wrote:
> > You don't get to redefine the problem so that your favorite technique
> > becomes the solution.
>
> Yes you do.  The aim is to solve the customer's problem.  They don't
> give a damn whether you copy objects or pass them by reference.  They
> don't even know what the options *mean*!

It depends on what you mean by customer.   A customer of a class/type
declaration is usually another programmer.    I am a member of that
class of customers, and I do care and I do know what the options mean.
One of the things I like about Eiffel is the careful attention given to the
design of the class contract.   I want to know, from that contract, what
to expect of my engaging it.   For example, what kinds of things can go
wrong, what are my responsibilities as a user of the contract,  and what
performance considerations I might want to consider in choosing a
particular contract.   And, yes, I want to know if it includes some form
of storage management, and have some idea of what that storage
management feature will have on my own program.

The next few observations remind me of something I once heard regarding
programming rules.   "Those who make up rules about programming tend
to be people who no longer write production programs."

> -- programs are hard to analyse for correctness because of GOTOs.
> Solution: don't use them

Generally  true.   Knuth has a lengthy article on this in his book, Literate
Programming.  To simply say, "Don't use go to, is a bit simplistic."   I
have seen perfectly good examples where, during fine tuning of a program,
someone has achieved significant performance improvement with a go to.
Some languages support goto-less programming better than others.   Some
eliminate the option altogether and also eliminate the benefits of it.   Go
to
is an option that should be used sparingly, almost never, but is handy when
you actually need it.   I realize one can "prove" that it is never needed.
So
be it.  Sometimes it just might be useful.

> -- programs are hard to analyse for correctness because of destructive
> assignment.  Solution: don't use assignment.

I understand this is a joke.  However, it conforms nicely to some of the
fundamental notions of functional programming.

> -- programs are often buggy because of off-by-one errors in loop
> control.  Solution: use implicit loops and/or mapping functions
> controlled by the size of the collection they are operating on.

Well, in Ada this never seems to be a problem.    In Eiffel it is never
a problem.    It is often a problem in programs that use the C family
of languages.   However, I think C# has a fix for this.

> -- programs are often buggy because of errors in memory management.
> Solution: automate memory management.

A naive suggestion, at best.   Which automated form of memory management
will you suggest?   There are many from which one can choose.  Each has
its own benefits, depending on the kind of software you are writing.   This
is
one of the things C++ gets right.   Ada also.   The problem of automated
memory management is one of the things that makes Java ill-suited to
many kinds of embedded, real-time software applications.   Jim Rogers
makes a good point about this vis a vis Ada.   In Ada, we have the option
of selecting the memory management model we wish to use, letting it be
automatic or not, and targeting each type to a different model of memory
management when that is a appropriate.   This is a level of flexibility
not typical of most other languages.   Yes, I know one can do this in C++,
but expressibile and expressive are not the same thing.  Ada is really
expressive in allowing this kind of automated memory management for
a given type.  That is as it should be since Ada is intended for safety-
critical, real-time embedded software systems.

Richard Riehle