From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,af40e09e753872c X-Google-Attributes: gidfac41,public X-Google-Thread: f8c65,30e368bdb3310fe5 X-Google-Attributes: gidf8c65,public X-Google-Thread: 109fba,30e368bdb3310fe5 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,30e368bdb3310fe5 X-Google-Attributes: gid1014db,public X-Google-Thread: 114809,7e30d0f1157403e6 X-Google-Attributes: gid114809,public X-Google-Thread: 1008e3,30e368bdb3310fe5 X-Google-Attributes: gid1008e3,public X-Google-Thread: 103376,30e368bdb3310fe5 X-Google-Attributes: gid103376,public From: jhd@herold.franken.de (Joachim Durchholz) Subject: Re: whither style Date: 1996/01/08 Message-ID: <60SqRiBF3RB@herold.franken.de>#1/1 X-Deja-AN: 134548785 references: <30e26364.2569895@news1.wolfe.net> content-type: text/plain; charset=ISO-8859-1 mime-version: 1.0 newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.modula2,comp.lang.modula3,comp.lang.smalltalk Date: 1996-01-08T00:00:00+00:00 List-Id: 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 ##