Newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.c,comp.lang.modula3,comp.lang.modula2,comp.lang.eiffel,comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!purdue!haven.umd.edu!news.umbc.edu!eff!blanket.mitre.org!agate!howland.reston.ans.net!gatech!newsfeed.internetmci.com!nntp-hub2.barrnet.net!pacbell.com!amdahl.com!amd!netcomsv!uu4news.netcom.com!netcomsv!uu3news.netcom.com!ix.netcom.com!netcom.com!beatty.slip.netcom.com!beatty
From: beatty@netcom.com (Derek Lee Beatty)
Subject: Re: whither style
Message-ID: <4cnmqu$2fg@beatty.slip.netcom.com>
Sender: netnews@mork.netcom.com
Nntp-Posting-Host: beatty.slip.netcom.com
Organization: none
X-Newsreader: Alexandra.app (Version 0.81)
References: <cmanDK7x13.5KM@netcom.com> <30e26364.2569895@news1.wolfe.net> <4bvae4$fl6@beatty.slip.netcom.com> <4c0a6d$4hs@news.irisa.fr>
Date: Sun, 7 Jan 1996 05:48:14 GMT
Lines: 99
Xref: glinda.oz.cs.cmu.edu comp.lang.ada:39508 comp.lang.c++:167862 comp.lang.c:169720 comp.lang.modula3:5798 comp.lang.modula2:13869 comp.lang.eiffel:12420 comp.lang.smalltalk:33158

jezequel@stormbringer.irisa.fr (Jean-Marc Jezequel) wrote:
>
>Please note that most of the HN (Hungarian Notation) discussion
>is led in the C and C++ context only.  In Eiffel or Smalltalk,
>where everything is an object, it would be really *stupid* to use
>such a restricted notation: types such as Integer or Float are
>nothing special w.r.t the language, and they are no more important
>than e.g., linked_list_of_hash_table_of_foo.

Although I know little about Eiffel, I'm quite cognizant of Smalltalk's type 
system, and I concede from that (rather narrow) viewpoint Integer and Float 
are not special.  However, from the standpoints of utility or simplicity of 
concept, there is something fundamental about concepts such as Number or 
Symbol, and from the standpoint of efficiency, there is something fundamental 
about hardware-supported types.

This actually brings up an interesting question: is the appropriateness of a 
naming convention related more to the nature of the problem domain, or more 
to the nature of the programming language?  Maybe the former.  Every 
well-written moderate or large software system I've seen is layered, and the 
higher levels make use of problem-domain abstractions.  These abstractions 
are largely independent of the programming language.  This then argues that 
the importance of type distinctions, and consequently the visibility they 
should have in the source code, is a function of the problem domain.

In my work, one hallmark is multiplicity of representation.  External 
constraints very often dictate that I maintain numerous representations of 
the same underlying thing.  Maintaining this correlation consistently and 
clearly in the source code is important.  There HN is useful because we can 
use the same "base name" for both representations, and let the "Hungarian" 
prefix distinguish them.

Certainly, we could invent our own naming convention to solve the problem, 
but why bother when an existing naming convention serves well?  This frees 
our attention so we can turn to more important concerns (like how to reduce 
the number of different representations).

>Beside, languages such as Smalltalk, Ada, Modula, Eiffel are not
>half-backed about typing:  either they are not typed (actually
>dynamically type), or strongly typed. In both cases, HN is mostly
>irrevelant. Idem for allocation classes, global vs. local, etc.:
>in Eiffel for instance you do not have to mess with this low level
>stuff (but you can if you want so).

As to typing, I have to disagree, having found HN quite useful on a project 
where I used ANSI C with full "function prototypes" (why couldn't C call them 
something more reasonable like "interface defintions") where strong typing 
was enforced.  But as I said above, the utility of HN could be more a 
function of my problem domain.

As to allocation, inattention to storage management is probably the source of 
much of the perceived inefficiency of advanced languages relative to 
lower-level ones like C++.  Garbage collection allows one to ignore storage 
management for too long---after all, by construction there are no 
memory-mangement bugs---until the memory footprint has ballooned.  In a 
virtual-memory environment, once your working set exceeds the capacity of the 
translation lookaside buffer, performance plummets.  (That said, I still 
prefer GC; it lets me worry about memory management only when that is truly 
necessary; without it I must be ever vigilant.)

As to scope, surely if you're smart enough to use Eiffel you're not using 
global variables, or at least not very many of them, or at least not without 
some clear way to distinguish them.  Actually, I'm a bit surprised that 
Eiffel has global variables, but you brought them up.

>Since you are in a really modular language (Ada*, Modula*, Eiffel,
>Smalltalk) the declaration of a variable type should be located
>close to its uses. And if your program unit is longer than a few
>tens of lines (which is poor style in e.g., Eiffel), *any* decent
>environment would show you a variable's type only by clicking on
>it.

It sometimes seems difficult for people who do research or writing about 
programming (as opposed to those who actually do programming) to realize, but 
not all activities related to programming are conducted in "programming 
environments."  Code is discussed in email, and in company-private 
newsgroups, and in meetings called "code reviews" which typically are done 
from printed listings.  And yes, a good environment will show me a variable's 
type just by clicking on it, but with HN I know the type just by *looking* at 
it, and looking is even easier than clicking.  

>So in conclusion, HN really are
>...
>>programming conventions ... developed to compensate for language flaws, are 
>...
>
>thus mostly relevant to C and C++. So please keep the discussion
>in these groups.

Were that to be done, this thread would die just when it is becoming more 
interesting.  The assertion has been made that language and technology better 
solve the problem that HN attempts to address.  I disagree because I prefer 
three tools to two (and I'm not convinced that language is relevant at all).  

-- 
Derek Lee Beatty	  _
beatty@netcom.com      	_| ~-,
Austin, Texas          	\, * )
			  \_(
