🚀 go-pugleaf

Jeez, there are so many points here I'd like to give my 2c worth of I  
can't resist.

beatty@netcom.com wrote 07.01.96 on Re: whither style:

> 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.

There is definitely no such thing as a global variable in Eiffel.

> >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)...
>
> 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.

Good code is so short you see the declaration at a glance. And if I'm  
discussing lengthy code in an environment where I don't have an  
environment that shows me the declaration, then I just include it with the  
code. True, HN has its use there, but rather as a means of abbreviation.

> 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).

I prefer one good tool to a dozen of inappropriate ones.

I think HN is inappropriate for languages where you can change the  
representation of a type behind the scenes, simply because it's impossible  
to invent an abbreviation for every type that shows up in a project.

In my experience, such languages actually don't need HN; the compiler will  
catch all errors that HN is supposed to help avoid. This is because in  
these languages, the type of a variable or value precisely defines what  
operations are admitted for it. If you had a type zero-terminated-string  
in such a language, the compiler won't allow you to pass this to a routine  
that expects a string with a length descriptor.

For languages that have a more loose relation of types and routines,
you need to have some fast way of checking wether an operation is  
applicable. HN makes that check easier, so it has a point there.

-Joachim

--
Im speaking for myself here.
## CrossPoint v3.02 ##