Subject:
|
Re: Case-sensitivity in programming languages
|
Newsgroups:
|
lugnet.publish
|
Date:
|
Thu, 18 Feb 1999 14:35:38 GMT
|
Viewed:
|
1649 times
|
| |
|
|
On Thu, 18 Feb 1999 00:03:29 GMT, lehman@javanet.com (Todd Lehman)
wrote:
> In lugnet.publish, blisses@worldnet.att.net (Steve Bliss) writes:
> > > 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.
>
> 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.
I'm reading into your response that I wasn't very clear in my earlier
'if you say so'. I meant to say that I don't have much knowledge on the
languages and concepts you mentioned. I've been in a VB & SQL ghetto
for the last few years.
> > 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.
>
> Good thing for a linter to flag in most cases. But not something the language
> should inherently prevent, though, right?
Prevent? I'm more worried about what it should allow. Meaning it
should allow me to type somevar and SomeVar, and it should interpret
them as the same identifier. It should not prevent me from this.
Heck, I didn't even like my old Commodore-64's BASIC, where A$ and A%
were different variables. And on that system, there were only 962
different identifiers, [A-Z]([A-Z0-9]) (argh! I can't remember the
notation for 'zero or one occurrence'), so overloading was more
important/useful.
> > 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).
>
> There was an old version of QuickBASIC back in '87 I think which fixed case
> automagically as you typed...that was cool. It even went around through your
> program for you and changed foo$ to Foo$ if you changed it in one spot -- right
> on the fly! :-)
Yep. Visual Basic still does this. It provides an easy to check that
your typed input parses OK - if the editor doesn't fix the casing, then
you typed something worng. Now, I find it kinda weird to work in
non-syntax sensitive editors.
> > > 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.
>
> OK, I didn't gather that from your original message expressing distaste for
> case-sensitivity. (I read it as a general blanket statement about all
> programming languages...sorry.)
You only took it that way, because that's the way I said it. ;)
> > > ... 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.
>
> For everyone or for yourself?
For most people.
> > ASSERT and assert should be the same thing.
>
> So there is no value then in distinguishing between, say, pchArm and pCharm?
> Between Hedge and hEdge? Carts and cArts? pWages and pwAges? Those should
> all be pairwise equivalent?
But you wouldn't put Carts and cArts in the same program. Carts and
Arts or iCarts and cArts. pWages and pwAges make a better example to
argue about. ;)
There are sometimes advantages (my favorite is sIn, my generic input
string variable. Too bad it clashes with Sin()). Just not enough for
me.
> (I'm not a fan of Hungarian Notation, but I respect other people's choice to
> use it, and I understand its usefulness in the Win32 programming environment.)
I'm not sure why HN would be more useful in Win32? Of course, HN isn't
a standard, it's a concept of a standard. Seems like it would be more
useful in any language with an over-reliance on pointers.
> > 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.
>
> Would you concede that case-insensitivity might be a bad thing for certain
> classes of languages (Lisp/Scheme, Perl, Python, PostScript/Forth, etc.)?
It's certainly possible.
Steve
|
|
Message is in Reply To:
 | | 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)
|
58 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
