Case-sensitivity: why -- or why not? (was Re: Damnation!)
Thomas Malik
340083143317-0001 at t-online.de
Sun May 28 14:14:46 EDT 2000
More information about the Python-list mailing list
Sun May 28 14:14:46 EDT 2000
- Previous message (by thread): Case-sensitivity: why -- or why not? (was Re: Damnation!)
- Next message (by thread): Case-sensitivity: why -- or why not? (was Re: Damnation!)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Late answer, but here i go: 1. By bringing the department of our bank into argument, i was saying, that even very conservative - thinking organizations are starting to use your (as it is) quite innovative programming language, because of the advantages it has. For a bank, one of the most important points is reliability in the IT systems, which, amongst others, can be achieved by a quite strict set of programming rules. If these rules completely break with some new programming language, or even with a new version of the language, it will have to be reconsidered it the language is going to be used. If the language itself provides for possibilities to write unreadable code (which case-insensitivity does, see below), it will be extremely difficult to share code with external programmers (we work a lot together with external consultants), i can assure you of this fact from experience. 2. in your mail, you are kind of mixing up a computer language (Python) with spoken/written language (english), i don't get the point here. I mean, if you were critisizing me for my spelling, i could bother or not, depending on whether i've slept well or not. With a computer program, that's a totally different point: a program will run correctly or not, depending ONLY on the correct syntax & semantics of the program. It's not a question of tolerance. 3. Removing case - sensitivity wouldn't reduce errors in any way, in contrary, it will add a new and more difficult class of errors: those where one uses the same identifier (possibly written with different case ...) with two different meanings. For example, one uses a class 'Error' from library a, and the function 'error' from library b, case-insensitivity will be a great source of annoayance here. You are trading syntax errors (easy to cope with) for possible semantic errors (extremely difficult to cope with) 4. the point, that bothers me most about case insensitivity, is, that consistency in the spelling of identifiers will be lost. That means, because case doesn't count any more, why should a programmer enforce any kind of rules in the use of type case ? Why should one even consider using the same case for the same identifier in different places ? What would the right typing be anyway, if Python doesn't check it anymore ? I find programs extremely hard to read, when they don't use consistent case for, say, class names, method names & so on. 5. there are quite a lot of cases, where i would have to invent 'unnatural' names for identifiers, just because the word i want to use is already used by a class name, for instance. 6. Any wide-spread computer language in use today uses case-sensitive identifiers. Oth, the only case - insensitive language i know of (pascal) doesn't produce any real-world projects and even has it's case-sensitive followup (Modula-2), by the same author (Niklaus Wirth). Lisp is another case - i didn't use it for some time already, but as i remember, the standard common lisp had case-sensitivity, and the syntax of the language allows for totally different naming schemes (with hyphens, for example). Ok, i hope that's enough to stop you claiming that i don't have or that there arent't arguments against case - insentivity On the other point, that has been discussed in the list, about promoting integer divisions to float or something other: I don't get the point here. I mean, during my college time, we have been bored with stuff about groups and rings, just to see in the later courses, that that kind of stuff can be quite useful. So, why should a division between integers leave the set of integer numbers, but no so a muliplication ? Ok, it's more 'natural' to say 'ok, 1/3 is 1/3, a rational number, that is (note that it's NOT the floating point representation 0.3333..., that's only an approximation). The point is, again, that a programming language is NOT a natural language (COBOL tried this already and failed laughable), but used for programming. And in programming, i will need an integer division all around, it were annoying if i would have to use some other function/operator, whatever. And then, i mean, once told, one shouldn't forget that 1/2 == 0. A person forgetting that all the time should propably learn something else. CP4E, to be honest, i have my vague doubts about that. In some way you are postulating the same level of intellectual potential for everyone, but that's another question you might have investigated for a longer time already. The strong point about C is, that it succeeded with an absolutely minimum set of language features to be capable of everything a programmer needs. The syntax, to a beginner, looks extremely crude. But in all my time at the university and after that, in profession, whenever i've seen a beginner to start programming, it was with C ( not C++, get me right here! ). What i want to say with that, it doesn't matter so much how 'resistant' the language is against first-time-programmer's errors, but 1. how logical the language is. 2. how much it helps the programmer to detect errors. 3. how little the number of syntactic constructs is (for that reason, C++ certainly is NOT a beginner's programming language) Ok, don't take all this personally, i like Python very much - but i hope that will remain so... Thomas
- Previous message (by thread): Case-sensitivity: why -- or why not? (was Re: Damnation!)
- Next message (by thread): Case-sensitivity: why -- or why not? (was Re: Damnation!)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list