Arthur wrote:
>>>[ Mark Engelberg ]:
>>>
>>>>2. My teaching experience is limited, but I did teach one programming
>>>>class to a group of middle-schoolers. The most common mistake was, by
>>>>far, simple misspellings of variable names (usually capitalization
>>>>confusion)....
>
> BTW, I can promise you the same Alex Martelli would bring the same level of
> vehemence to an argument *for* case insensitivity that he would bring to an
> argument *against* variable declarations.
>
> I've never actually heard the 2 issues tied together before (doesn't mean it
> hasn't been) - but there maybe a intuitive connection - the forgivingness of
> case-insensitivity offering some practical mitigation of the potential
> issues of a language that disallows variable declaration.
>
> Martelli will be speaking at a NY Linux event next week. If my schedule
> allows I hope to be there, and will perhaps take the opportunity to ask him
> (if he decides we are on speaking terms) if he thinks there is any intuitive
> connection between these vehement positions of his. I think we can agree
> off-hand that there is no strictly logical connection.
Here's a guess:
Both declarations and case-sensitivity are catering to the machine
rather than to the programmer. There have been both case-sensitive
and case-insensitive languages. The advantage of a case-insensitive
language is that when we are taught to read, we are taught that, for
example, "f" and "F" are the same letter. Eventually we learn that.
Then we eventually have to learn that "not really, for programming
you need to be aware of the case."
An argument _for_ case sensitivity involves Python's "practicality."
Many languages _are_ cases sensitive. In particular CPython's C
language, Jython's Java language, and IronPython's C#. In interfacing
to those languages, you'd need to invent some mechanism to get to
interface functions name "abc", "Abc", and "ABC". Much easier to "go
with the flow" on this one to than swim upstream.
A second argument for case sensitivity is related to the invention
(and use) of CamelCaseIdentifiers. "Bight" might be a knot identifier,
but "BigHt" looks like an adjective and a noun. Enough experience shows
it is a bad idea to use two distinct "spellings" of the same identifier
in code -- it at least makes it easier to mis-read code. So, your
style guide reads, "always use the same cases for identifiers". If you
have ever done support over the phone, you will realize that nobody
speaks code in way that you can unambiguously write down the case.
For this single reason, if no other, your style guide should say,
"never name two identifiers so the only distinction is case". Yes,
it is "cute" to be able to have "e" and "E" in physics distinct, but
the problems you run into are much more damaging than than the
advantages gained. I don't need my language to enforce my style guide,
but you'll notice careful use of the guide prohibits your discovering
whether the language has case-insensitive identifiers.
--Scott David Daniels
[EMAIL PROTECTED]
_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
