Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!netcomsv!jls From: jls@netcom.COM (Jim Showalter) Newsgroups: comp.object Subject: Re: Functions without side effects (was Old confusion) Message-ID: <1991Jun23.023559.7391@netcom.COM> Date: 23 Jun 91 02:35:59 GMT References: <1991Jun19.173 <1991Jun21.013944.23970@netcom.COM> <4174@ssc-bee.ssc-vax.UUCP> Organization: Netcom - Online Communication Services UNIX System {408 241-9760 guest} Lines: 102 > Jim, Jim, Jim. Come on now, play fair. How about: > prnt(/* This Comment */ "I love *commented* parameter names", > /* With This Spacing */ 5, > /* On This Device */ lsptr, > /* In This Font */ hlvtca); Ah, but in THIS case, you have a MULTIPLE point of maintenance: the client of a class/method/function has to redocument via comments the meaning of each argument at every point of call. Sure, you can remember to do this if you are diligent and a practitioner of good community hygiene, but who has the time for THAT?--certainly not the average C hacker. If you have function prototypes with formal parameter names and named parameter association, the names only have to be designed in one and only one place, by the DESIGNER of the class/method/function, and used for free by all clients from then on (and, if you are fortunate enough to be using real tools, they can automatically add all of the names and prompt for the values at the point of call, so you don't have to type anything except the name "print" itself). Again--nothing is impossible if enough manual effort is expended, but if you believe that the majority of C hackers bother to expend such effort, I've got some great swampland to sell you in Florida. Incidentally, it was never my intention to PROVE that formal parameter names and named parameter association is a good thing--I think the fact that Stroustrup added at least the former to C++, that ANSI C adds the former to C, that both are present in Modula-3, and that (I believe) both are present in Eiffel says something about their usefulness. > BTW, why such wonderously readable *variable* names for the Ada > example: >] Print (This_Comment => "I love named parameter names", >] With_This_Spacing => 5, >] On_This_Device => Devices.Laserprinter, > ^^^^^^^^^^^^^^^^^^^ >] In_This_Font => Fonts.Helvetica); > ^^^^^^^^^^^^^^^ > and such terse variable names for the C example: >] prnt("I love named parameter names",5,lsptr,hlvtca); Well, in the case of Ada such names tend to be the default, since the first segment of the name is the name of the package, and the second segment is the name of the entity exported from the package. This is almost directly analogous to . in C++ and several other languages. If you're complaining that the words themselves are too long and readable in the Ada example and deliberately short and cryptic in the C example, I offer the following challenge: take 50 KSLOC of Ada from an arbitrary source and count up the number of times you encounter a name that ISN'T very readable, is lengthy as opposed to scrunched up like a vanity plate with all the vowels missing, etc, and post to the net the relative proportion of such things relative to those that are readable. I've been working with Ada programs of various sizes at companies ranging from just shy of totally incompetent to quite good for the past four years, and I'd say that 99.9% of the time all names are chosen with care. Call it a culturally-shared value. Really--go look at some Ada code and report back. As for the C example, be real. Yes, people CAN write readable code in C, and some even pride themselves on it. On the other hand, it has been my experience working with C hackers and UNIX weenies for over a decade that many shared cultural values that should have had a stake driven through their heart in 1964 survive to this day. You may, like a fish asked to describe water, be unware of these values, but they're real and they stink, and as something of a fish in a different pond, I can rather accurately observe and describe the water in which YOU swim. Consider, for example, the lovely naming used in UNIX itself: the semantic content of such commands as "awk", "sed", "grep", "elm", "nn" blah blah blah is effectively nil. This is WHY, if you've ever stopped to wonder about it, neophytes complain that UNIX is cryptic and hard to learn--because it IS. It is a hacker's dream operating system, written by hackers, used by hackers, and extended by hackers. Non-hackers--ordinary every day people who are just trying to get WORK done atop UNIX--don't find UNIX charming or sophisticated or productive or all those other words hackers used to describe it so glowingly...quite the contrary, they HATE the damned thing, and that explains why they embrace graphical, menuing interfaces that isolate them from the grunge of the underlying UNIX command syntax. This misplaced love of cryptic, vowel-less, hard to understand, encoded names filtered into and infiltrated the C culture at large (not surprising, given the incestuous relationship between C and UNIX), and became a culturally shared value. It survives to this day. I can go on to lambast UNIX's cryptic command line arguments, but I think I've made as much of my point as I'm ever going to make in a forum that is essentially hosted on UNIX and read by zillions of C hackers. >|~~~~~~ Seattle: America's most attractive city... to the *jetstream* ~~~~~~| Nice .sig! -- *** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 **** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *