Yet Another Case Question
bokr at oz.net
Mon Feb 24 09:41:53 CET 2003
On 23 Feb 2003 23:39:42 -0800, sjmachin at lexicon.net (John Machin) wrote:
>bokr at oz.net (Bengt Richter) wrote in message news:<b3boet$vt9$0 at 220.127.116.11>...
>> On 23 Feb 2003 15:35:31 -0800, sjmachin at lexicon.net (John Machin) wrote:
>> >The problem is one of where you drive in your peg on the scale between
>> >bit-by-bit exactness and "equivalent for the job in hand". Bitwise
>> >exact is unfortunately all too easy and all too often not a bright
>> >Skip the admittedly sometimes enlightening chats with 7yos. Moving
>> >outside the domain of variable names into the real world, try talking
>> >to the computer system users and customers who are affected by
>> >sillinesses such as:
>> >(1) rejecting customer transactions because "John Citizen" != "JOHN
>> >(2) rejecting customer transactions because "John Arthur" != "John
>> >(3) doubling taxes because "000123456" != "123456"
>> >and ask them what they think of bit-by-bit exactness.
>> Bit-by-bit exactness has nothing to do with those examples.
>> If the cook can't cook, the solution is not oatmeal uber alles.
>> The silliness is in flawed product development, not the language.
>I wouldn't call it "flawed product development"; "flawed" certainly,
>but "product development" tends to indicate that some thought went
>into the process. My contention is that no thought about the
>difference between bitwise equality and semantic equivalence went into
>the "designs" that caused the above examples, and not much thought
That's an implementation detail. IMO the specs for the application
should talk about the syntax of the user input and required output,
and let the next phase be choosing an appropriate language to implement
it with. I certainly wouldn't cross off Python because it is case
sensitive, and some particular app is specified to canonicalize user input
for certain purposes.
>(pax Guido; he wanted to fix it in Python) went into the products
>called "languages" who say that "foo_bar" is not semantically the same
Thank goodness it's settled the way I like it ;-)
More information about the Python-list