Subject:
|
Re: Case-sensitivity in programming languages
|
Newsgroups:
|
lugnet.publish
|
Date:
|
Wed, 17 Feb 1999 20:25:27 GMT
|
Viewed:
|
1620 times
|
| |
|
|
[I suppose this should move to off-topic. Oh well.]
On Wed, 17 Feb 1999 19:24:34 GMT, lehman@javanet.com (Todd Lehman)
wrote:
> In lugnet.publish, blisses@worldnet.att.net (Steve Bliss) writes:
> > [...]
> > I also don't like my programming languages to be case sensitive, for
> > more-or-less the same reason. I think it's illogical for a program to
> > choke on the keyword 'if', but accept 'IF' with no problem.
> > [...]
>
> Well, one of the reasons many high-level languages are case-sensitive is that
> it vastly increases flexibility and expressiveness. Languages such as Lisp,
> Forth, PostScript, Perl, etc. with advanced string manipulation capabilities,
> dynamic run-time typing, late binding, etc., all let you define functions and
> treat them as if they were built-in language features. Same goes for operator
> and method overloading. These extension mechanisms, usually using symbol
> tables, make use of the same code used for dictionaries (e.g., hashes or
> associative arrays). This is an extremely flexible and powerful paradigm, the
> effectiveness of which would be severely hampered by case-insensitivity.
If you say so.
> Notwithstanding, a language could certainly employ an uppercasing or
> lowercasing filter in the symbol table lookup, but then you'd have to introduce
> extra syntax into the grammar to specify when you wanted case-sensitive lookups
> and when you wanted case-insensitive lookups.
>
> Anyway, on the surface, it may seem restricting when a language differentiates
> between 'if' and 'IF', but if the language has any real extensibility in it,
> it would actually be restricting not to differentiate.
I'll disagree that it only *seems* restricting *on the surface*. When I
read "assert(x)" and "ASSERT(x)", my brain thinks they mean the same
thing. I've used systems where they actually mean different, I just
avoid writing anything that would rely on that approach.
Way back in CS101, proto-CS-geeks were taught that it would be evil to
write programs using identifiers whose names differed only by the case
of their characters. Using x and X as different variables is a bear to
debug.
I admit I dislike languages where keywords are case-sensitive because of
my own preferences. I don't want to have to keep hitting the shift
and/or caps-lock. Give me an editor that fixes the casing for me, and
I'd be happy(ier).
> Older languages like C,
> C++, Pascal, FORTRAN, BASIC, etc., however, don't really benefit much from
> case-sensitivity, ...
Which was the domain (range?) of languages I was considering.
> ... except maybe for human-readability issues such as macros
> conventionally being uppercase in C, so that, say, ASSERT(x) really means
> something different from assert(x).
I maintain that human readability is enhanced by case-insensitivity.
ASSERT and assert should be the same thing.
I agree that the convention of macros being all-caps is fine and conveys
information to the reader. It just shouldn't be conveying information
to the compiler.
Steve
|
|
Message has 1 Reply:
 | | Re: Case-sensitivity in programming languages
|
| (...) Well, I dunno, maybe those languages wouldn't be severely hampered by case- insensitivity. I always thought that was the reason they were designed to be case-sensitive. (...) OK, yes, that's certainly a readability restriction. What I meant (...) (25 years ago, 18-Feb-99, to lugnet.publish)
|
Message is in Reply To:
| | Case-sensitivity in programming languages
|
| (...) Well, one of the reasons many high-level languages are case-sensitive is that it vastly increases flexibility and expressiveness. Languages such as Lisp, Forth, PostScript, Perl, etc. with advanced string manipulation capabilities, dynamic (...) (25 years ago, 17-Feb-99, to lugnet.publish)
|
58 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
