Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!dptg!ulysses!andante!alice!garry
From: garry@alice.att.com (garry hodgson)
Newsgroups: comp.object
Subject: Re: Functions without side effects (was Old confusion)
Message-ID: <20462@alice.att.com>
Date: 26 Jun 91 19:28:06 GMT
References: <130242@tut.cis.ohio-state.edu> <4888@osc.COM> <72893@microsoft.UUCP> <1991Jun26.001847.24239@netcom.COM>
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 71

In article <1991Jun26.001847.24239@netcom.COM>, jls@netcom.COM (Jim Showalter) writes:

> How about this sort of thing
> (this is NOT intended to be a straw man piece of bad code--I see this
> stuff all the time, so unless the code I review is, in fact, submitted
> to me by men made of straw, this rates as a legitimate code sample):

> argl (4.5, 8, INCR, "bargl");

Clearly, the solution here is to hunt down the author and kill him.
I believe this solution is language independant.  And so much fun :-)

> The whole
> point of named parameter association is to provide the missing semantics
> at the point of call, to wit:

> argl (Azimuth => 4.5, Inclination => 8, Mode => INCR, Options => "bargl");

> Yes, this is still semi-dreadful, but it is a definite improvement over
> the first version, isn't it?

Indeed it is, if you can convince the (now-deceased :-) author to use it.
But anyone who would write code like that would be unlikely to take advantage
of an admittedly nice feature.  And many of the folks who would use it
don't necessarily need it.

I do, however, like the idea of specifying only those paramters you care
about, letting others use default values.  I believe this is supported.
C++ allows this to a limited extent, but since parameters are positional,
you're limited to the trailing ones getting defaults.

> Okay, true enough. I grant you that, much as I take issue with its
> warts, C++ DOES represent a golden opportunity to reboot the C/UNIX
> culture with a different mindset--one that recognizes the value of
> strong typing, abstraction, portability, maintainability, etc.

When I first started using C++, I thought "Thank God, I finally have
language support for all the stuff I've been trying to do in C all this time"
It was an easy sell, for me.  Other folks exemplify the
"Real Men can write Fortran in any language" methodology.  I doubt
there is any hope for them, short of early retirement.

> On the
> other hand, if the very same people who argue that formal names for
> parameters are "verbose" are going to be doing the writing in C++,
> what makes you think anything is going to change? 

See above ("Real Men...").

I agree with you, it seems, on most of what you're saying.
I just don't believe that language features can save those who 
don't want to be saved.  I briefly thought that C++ could help;
that by starting with a well-designed set of base classes one could
force good style upon users of those classes.  Then I saw a set
of "spaghetti-classes", the OO equvalent of "spaghetti-code",
and realized there was no hope...

I suppose I fall on the verbose side of the fence, myself.  I don't
touch type, but I do type quickly, and tend to cut/paste/snarf more than
type, anyway.  I take great pains to make my code readable, obvious,
and esthetically appealing.  This last point is very important to me,
and is, indeed, my main problem with Ada.  It just doesn't appeal to
my sense of esthetics.  I realize this may seem silly, but it is there
nonetheless.  So while I can see the value to an organization using
Ada, I just don't want to use it personally.

-- 
Garry Hodgson		One way or another,
AT&T Bell Labs		this darkness got to give...