NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/lang/misc/3029

Text File | 1992-09-11 | 3.9 KB | 73 lines

Newsgroups: comp.lang.misc
Path: sparky!uunet!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!lanl!cochiti.lanl.gov!jlg
From: [e-mail] (Jim Giles)
Subject: Re: Opinions on case sensitivity in programming languages?
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: Los Alamos National Laboratory
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 11 Sep 1992 18:27:55 GMT
Lines: 61

In article <[e-mail]>, [e-mail] (Tony Davie) writes:
|> [...]
|> Case sensitivity is a throwback to the days when the only input to a computer
|> was a teletype or a punched card. There is no excuse for languages to be case
|> insensitive nowadays, EXCEPT when connecting to machines which may have such
|> equipment attached to them. This makes it sensible to make names of machines
|> on a network, for instance, case-insensitive.

There's no excuse for a language to adopt a feature which impairs user
productivity rather than improving it.  Which of these case in/sensitivity
does is hard to tell.  One: there have been no human-factors experiments
(that I know of) which address the issue.  Two: user opinions are next to
worthless - it is a commonplace observation among human-factors researchers
that the users are usually the *poorest* judges of what features effect
their own productivity and in what ways.

I can only offer my own experience that there is often confusion and
dissent among programmers who use differing case conventions.  These
problems don't arise (obviously) in case insensitive languages.  So,
for languages in which a specific case convention is not universally
accepted (maybe even enforced by the language itself), case sensitivity
is *probably* an inhibitor of productivity.  This *may* be offset if
case sensitivity has additional advantages due to the specific nature
and purpose of the language involved.  Like in a symbolic math
package (Macsyma, Reduce, Mathematica, etc.) which should be case
sensitive because conventional math notation is (they should also
be font sensitive; allow other alphabets - like Greek; be sensitive
to position - like having true super- and subscripts; be sensitive
to font size, boldness, italics; etc. - all of which add considerable
complexity to keyboard entry).  Without all of the latter parenthetic
capabilities, mere case sensitivity, even for math uses, is of dubious
value.

I'm afraid that case sensitivity, for most programming environments, is
about as appropriate as color sensitivity would be.  This is, as I stated
in the first paragraph, only an opinion - there is no objective basis
for decisions on this issue.

Interestingly, there was a language which was both case sensitive and
color sensitive.  Madcap (since called Modcap - by developers who lost
their sense of humor about the project and began taking themselves
very seriously) required a two-color ribbon teletype.  The blue (or
black on some models) was for program text, anything in red was
treated as commentary.  Case sensitivity was also interesting: all
identifiers had to be initial caps, all the rest lower case.  In this
way, they could implement multiplication as justaposition of identifiers
without an explicit operator.  `ThetaPi' was clearly `Theta' times `Pi',
while `Thetapi' was clearly a single seven letter identifier.  No other
use of case was allowed.  The language was also sensitive to the degree
of indentation, and had several other peculiarities - some of which
have not been duplicated in expressive power since: like their looping
construct.

Note that since case had a clearly defined *syntactic* meaning (the
appropriate level for case sensitivity to matter), the Madcap use
was probably not too bad.  Certainly it would never have led to
dissention or confusion among users - they *couldn't* use conflicting
conventions.

--
J. Giles