Lambda the Ultimate

"Having case sensitive identifiers can make code more readable, through the use of naming conventions."

Programs, perhaps even more than most prose, are "write once, read many times". Independent of naming conventions, the consistency enforced by case sensitive programming languages adds to their readability, because the same entity is always written the same way.

I suppose a rule contributing more strongly to readability would be to have case sensitivity, but also to disallow any identifiers in a given namespace from differing only by case. Anyone know of any languages with that sort of rule?

I suppose a rule contributing more strongly to readability would be to have case sensitivity, but also to disallow any identifiers in a given namespace from differing only by case. Anyone know of any languages with that sort of rule?

Sounds like Windows file system (is it NTFS I have on my XP?).

NTFS is not case sensitive and yes that is what you have on your XP 'puter.

Visual Studio with VB.NET, I know will correct the case of a variable based on prior usage.
I don't know if there is similar functionality for C# (but I am pleased to be finding out soon).
So maybe the best case does exist, but I doubt it.

I hate sloppy coders and am very meticulous with the formatting of my code. I don't mind being reminded when I mistype a variable name. If you are strugling with case senitivity, I suggest you be sure to use a good IDE. Color coding is invaluable for me when I am trying to remember a php function name. Code completion is great, except for when it is annoying (depends on my mood I guess).

Case sensitity does not prevent you from creating UgLY CodE, imo. I agree that consistent conventions are already a sort of case sensitivity, but ultimate my point is that we are humans, and not machines. The code should serve us, not the other way around.

To my way of of thinking, program code is supposed to enable a human-centric way of representing a solution to a computing problem. Enforcing case sensitivity does not increase the power of the expressiveness of the language, instead (for me) it becomes a stumbling block, albeit minor, to the successful solution to the problem. To me, it's a step backwards towards assembly language.

My biggest gripe is still that it allows the TYPE type style of declaration, like HWND HWnd. God, that irritates me to no end, and it appears perfectly acceptable to many C/C++ programmers.

I appreciate accuracy and consistency in program code as much as the next guy, but when the compiler is being anal about the case of a letter, it takes away from the expression of the problem and instead forces you to focus on the vagaries of the tool.

When you use a screwdriver, you shouldn't have to be worried about the intracies of the tool itself - the tool should allow you to solve the problem at hand without creating problems that are due to the design of the tool itself.

Imagine a left-handed screw-driver.... luckily screwdrivers are case-ignorant :-p

My biggest gripe is still that it allows the TYPE type style of declaration, like HWND HWnd. God, that irritates me to no end, and it appears perfectly acceptable to many C/C++ programmers.

What's your problem with that?
I mean, it depends on the context, but if I have a function like:
void SetWindowTitle(HWND hWnd, const wchar_t* title);
What's wrong with that?
I think that's similar to naming a counter variable 'i': If the meaning is clear from the context, what's wrong with it? Calling it "iCounter" doesn't really make it more readable.

To me, C-style declarations can be read as "reserve some storage for one of these; and label that reserved storage with this identifier for future reference." It's as if there's an implicit indefinite article associated with the type, and a definite article with the variable name: so declaring "FOO foo" to me seems similar to allowing anaphoric reference to just "the otherwise-anonymous FOO that I built earlier". Strong medicine, and, as in natural language, it should not be used unless the role of the anonymous entity is absolutely unambiguous.

I'm suspecting its the PASSWORD=password clause in the SQLish query, but I don't know PL/SQL well enough to know whether PASSWORD is interpreted as a variable name (same as password) due to the two names matching each other (modulo case); or whether the left side of a = in the query string is parsed differently than the right.

It appears to me that the problem is not really the case-ignorance of the language per se, but because the language allows you to inline the query members in a typeless fashion (even when you have "identical" params) instead of for example putting the whole query into a string type and executing the string type.

In my opinion the compiler should have at least generated a warning on the duplicate name, because ultimately it's a logic error.

There is nothing typeless about that piece of code, PL/SQL is statically typed, as the code is compiled and executed inside the DB it's fully statically checked against the schemas of the relevant tables. SQL queries are as much part of the syntax as any other entity in PL/SQL, in fact, the language is a procedurally extended SQL.

I don't fully understand your final comment, so pick your answer, but is any of the comments below appropos? If not, please correct me.

This tautology would be obvious to a computer, but I think it's not too hard to imagine a similar scenario where the computer couldn't help you.

The problem here is combination of case insensitivity and shadowing, disallowing the second would obviously have prevented this particular problem as well as introducing case insensitivity.

But I really believe both of these 'fixes' ignores the fundamental issue, that things that are the same should look the same, because we might rely as much on the 'shape' of the words as the actual letters of them when reading. But then, I also find human language/computer language rules such as names/types should always be capitilized sensible and helpful as well. They irk me on a logical level, but work for me on a psychological level.

I refer to the "typeless fashion" of the language according to the way that it allows you to ambigously use field names as if they were identifiers, without any specific type. The problem would have been avoided if the SQL field identifiers were typed, for example:

SELECT ... WHERE "PASSWORD"=password,

That would remove the ambiguity (a field name is a string, afterall...).

The compiler/interpreter should be able to determine that the field identifier following the WHERE clause creates an ambiguity within the parameter list, and should issue a warning to that effect.

But in PL/SQL they are, basically, ordinary identifiers, and the FROM syntax is just another way of introducing a scope, like a function declaration. The dangerous part is probably that the declared identifiers introduced are, as you say, implicit rather than explicit, much like in Deplphi's (?) fabled WITH syntax. Which is well known to be dangerous.

An analogous example in a language without these kinds of expressions take stranger coding conventions, but still work.

function ValidUserLogin(USER :String, PASSWORD :String) begin
    password :String = PasswordOfUser(PASSWORD);
    return PASSWORD == password;
end

Also, a case-sensitive program will run regardless of compiler/interpreter case sensitivity. This is not true of a case-insensitive program.

(define E
  (lambda (x e)
    (if (pair? x) (E (car x) (E (cdr x) e)) (+ e 2))))

Aziz,,,

while not normally a source of inspiration for PL design, had the following policy:

* IDL files are case-sensitive: FOO is a different identifier than foo or Foo.

* Symbols may NOT differ only by case. If FOO is a valid identifier in a given scope; it is an error to introduce foo or Foo as identifiers.

This policy was probably necessary to deal with the numerous target languages, some case-sensitive and some not. Code which has THIS property (cases are used consistently, and no two symbols which differ only by case) may be safely used in either environment.

Since when does case sensitivity result in shorter variable names?

Oh, and because I'm a Pascal programmer by and large, I'm a "noob"?

Here's a clue. Catch.

I try and follow the Taligent method wherever I can, but ultimately it's a convention for clarity to humans, not the compiler. It has nothing to do with whether the language is case sensitive or not, afaic.

I use a very simple coding convention:

1) Class identifiers start with a capital and contain no underscores. Words are separated by capital letters.

2) local variables and methods are like class identifiers but with the first letter in lower case.

3) member fields are like local variables prefixed with 'm_'.

4) constants are in upper case with words separated by underscores.

Example:

class Foo {
    void method(int data) {
    }
    int m_data;
    static const MAX_SIZE = 3;
};

We used to have hungarian notation in our company, but we ditched it because it is very difficult to consistently follow it, and it gets in your way when you are thinking about the problem at hand.

issues of using Unicode for programming language identifiers: see Unicode Standard Annex #31 (rev 5), part of the Unicode 4.1 standard.

The Annex includes recommendations for case folding and case senstitivity, as well as other thorny Unicode issues (such as normalization). It doesn't make a recommendation for or against case sensitivity, though case folding--as noted above--is tricky in Unicode.

It doesn't address the issue of different code points (with different functions) being represented with visually similar glyphs (an issue which goes beyond letters--consider the large number of slashes, quotes, dashes, and parens defined in Unicode); though Unicode Technical Report 36 (which deals with script spoofing and numerous other security related issues) does deal with this (though from a security perspective).

Not all case insensitive languages are seen as toy or learning languages. Lisp for instance capitalizes all symbols unless they are defned with a special syntax or READ is altered. That makes it effectively case insensitive since the almost all symbols are case folded.

Case sensitivity is just a bit of semantics that you get used to, sort of like python's whitespace/block system.

Come to think of it, the requirement for compatibility with the expectations of the many millions of existing C and C++ programmers was obviously a much more significant force for case sensitivity. I was trying to get the idea over that a language may well be sub-optimal when viewed from any individual perspectives but can still be optimal when viewed as a whole. Case sensitivity is one of these perspectives.

Being an old Pascal programmer, my natural leaning is towards case insensitivity, however, as I get older I am tending to regard syntactic issues as irrelevant noise which just gets in the way of understanding what the program actually does (maybe I am transforming into a Lisp programmer!).

But what happens (in Java) if you declare two identifiers at the same scope, which differ only in case? I don't think the language itself cares, but given that package and class names map onto the filesystem of the underlying OS, and certain OS's (i.e. Windows) have case-insensitive filesystems, what happens?

That's why you have the naming conventions (well, among other reasons). If you stick to them, you'll only use CamelCase with classes, and you'll never have a class named Camelcase or camelcase or CAMELCASE anyway. Consistent rules for abbreviations help a lot here too.

But you're right, it can lead to big problems if you don't stick to conventions. I once had a compiler design class where the professor gave us two classes, Exp and EXP, both in the same package. They represented the same thing, but at two different phases in the compilation process. (Yeah, they should've been in different packages, but professors are lazy.) I had to rename the class and all usages before I could get it to compile on Windows (and actually, the copy overwrote the original class, so the first indication was a missing method on the class).

In practice, I've found this is only a problem in school, where the professors are too lazy and the students too arrogant to stick to naming conventions. In real programming jobs, you learn very quickly that you stick to the conventions or die. Your coworkers tend to make sure of it, if your deadlines don't. ;-)