Re: cache and d3-style case-insensitivity

Ed Clark wrote:
I will pass your comments on to the project manager.
Case insensitivity is quite a religious issue. D3-centric programmers
are all for it, and programmers from other mv platforms look at D3 and
say "huh?".

My friend, I agree that this can get religious but we're also talking
about basic inability for potential clients to migrate (quickly or
cost-effectively), and ongoing frustration of people who try to get
beyond this basic issue. That's just bad business. I don't like the
way flavors/emulations are handled in many MV environments but I think
it's important that all environments support such things.

People who use a case insensitive environment feel liberated from
endless errors with verbs or files not being found, or with programs
not compiling or running incorrectly. People who have never used a
case-insensitive environment seem to be the only ones complaining
about the feature - and that's only because the other MV DBMS vendors
don't support it so these people have never tried it. This seems
awfully chicken and egg to me.

Outside of migrations, when has case-insensitivity been bad? I've
never accidentally found data that I didn't want to find because it
was in the wrong case but the right letters. I don't know a single
developer who seriously codes Response and RESPONSE to be different
variables. If someone uses Response here and RESPONSE there, we know
they mean the same thing, let them have it. The only time I can see
that "yes" and "YES" can be a problem is if the data gets transferred
to a strongly typed and case-sensitive environment like Java or .NET,
and there developers expect such things. The fact that case
insensitive data is a problem when migrating from D3 to other MV
environments seems to be a self-fulfulling prophecy for which people
then blame Pick Systems.

It's ironic that Pick Systems did something useful and people go
"huh?", but when some other DBMS vendor does something it's lauded as
creative and a sign of progress. At least PS had the foresight to
ensure this feature is optional and can be selectively invoked in
various ways. Other DBMS vendors categorically criticize the feature
and refuse to even provide an option for those who want it. That's
downright authoritarian, and not surprisingly the position is usually
supported by engineers who have been raised in the old church, err...
school.

Why do MV DBMS providers make TCL a little more case-insensitive?
Because it helps users, especially new ones, right? If we're already
agreed that far, then why is increasing the scope of this good feature
considered to be bad?

In a world where MV developers revolt against the rigid and sometimes
ambiguous complexities of object-oriented programming and
RDBMS-enforced referential integrity, how can they as strongly defend
in favor of case sensitivity? A case sensitive environment tends to
be more user-hostile and requires special coding, How many times have
we seen "Yes", "YES", "yes", and "y" rejected because the expected
response is "Y"? In this case the developer is expected to check for
Response[1,1]. Do we really need to force developers to UCASE or
LCASE everything too?

A case-sensitive coding environment to me has the same feeling of
rudeness as someone who posts to forums in all upper case. THIS IS
INTERPRETED AS YELLING - and when I read code I don't want it yelling
at me all the time. This is another area where Caché engineers saw
the value of adding an OPTIONS flag. If we have the option here
because it's a good thing, and code statements themselves are Always
case insensitive (in Caché), it's starting to get really hard to
defend the mandatory case sensitivity elsewhere.

Thanks for your time.
T
.

Relevant Pages

  • Re: VS2005 and VS 6.0
    ... environment by stupid errors. ... Mitchell, who essentially signed the check that made Java possible, was one of these ... I'm not sure why you think targeting managed code with a GUI designer is any different ... There were always more VB programmers than VC++ programmers, ...
    (microsoft.public.vc.mfc)
  • Re: Case sensitivity in programming languages.
    ... Obviously thisThing can't play first and second ... Case Sensitivity is a Good Thing ha! ... When your consider how slow the processors were all that long ago, the compiler developers chose to implement case insensitivity with its slight overhead instead saving a few cpu ycles by intoducing case insensitivty. ... Given the choice most programmers would chosse software which creates fewer problems for them, wich means choosing case insensitive software. ...
    (comp.lang.php)
  • Re: VB .net - A question for Microsoft Moderators...
    ... >> that not all VB6/VBA programmers have the luxury of Visual studio proper. ... This is obviously why Microsoft ... In thes environment VB, more and more, has become a utility ...
    (microsoft.public.office.developer.vba)
  • Re: Son of Snarky Tirade: a response to Seebachs new CTCN: part 1
    ... Seebs is seriously confused about "standard". ... This produces a warning in my environment because the use of main ... Reason" as one of obsessive programmers, who, assigned simple tasks ... "really" writing The Great American Compiler. ...
    (comp.lang.c)
  • Re: Requirement ordering (was Agile developement ... more than just extreme programming ???)
    ... All I have to say on this is that it's wrong to judge other developers ... Contrast working in a MIS ... in the systems environment, ... The programmers are likely to be familiar with the domain. ...
    (comp.object)