browse keys (@bk)

[Brian K. White]

Jay R. Ashworth wrote:
> On Tue, Jul 20, 2004 at 09:08:12PM -0400, John Esak wrote:
>>> On Tue, Jul 20, 2004 at 08:45:13PM -0400, John Esak wrote:
>>>> want case insensitivity to be the default and not otherwise. The
>>>> _vast_ majority of people out there type in "smi" at an index key
>>> prompt in IUA and
>>>> they would be _very_ upset if they weren't brought to the first
>>>> "SMITH" record should one exist.
>>>
>>> If you can build an index on a '*' column populated by all upper
>>> case data, type 'smi' into it, and get anywhere, you let me know,
>>> John.
>>
>> Excuse me?  Ummm, I can do that any day of the week and twice on
>> Sunday...
>
> I'm pretty sure you're wrong, here.
>
>> also, I was referring to the index-key question in the index dialog
>> box in IUA. Are you asking about data entry into the field itself?
>> In which case, what you are suggesting isn't possible, IS most
>> certainly possible ALSO. Your comment here is completely
>> non-understandable to me... what exactly do you think would NOT work
>> if one typed "smi" into just about anyplace in filePro related to an
>> index built on an * data type... (filled with all UPPER CASE data)
>> or not?  Maybe you should try some of this stuff out before you post
>> these messages, Jay. Either that or be more clear about what it is
>> you want me to let you know about... because, uh, in this case, at
>> least, you seem pretty confused.
>
> [ runs test ]
>
> Ok, *now* I'm just disgusted.
>
> WARNING, to anyone remaining who might expect sane behavior: indexes
> on * format fields are case insensitive, too.
>
> What John says above is in fact accurate.
>
>>> What you *actually* mean here is building an index on a column that
>>> the programmer *consciously* forced to uppercase, which, as Mark
>>> correctly noted, is a completely different thing.
>>
>> heesh, the worst thing you could do is try and say what *I* actually
>> mean, when you are so unclear about what you yourself are saying. I
>> was not referring to anything Mark said, nor does it apply to any of
>> this... nor does it apply at all to your comment above about not
>> being able to use "smi" to find something in an index with ALLUP
>> data... Try stating all this again in some way that makes sense and
>> I'll test it out and try and understand what you mean... but with
>> the stuff you've just put here, it all is pretty inscrutable.
>
> No.  The problem is that I continue to expect sane behavior out of
> filePro despite all the continuing evidence to the contrary.
>
> You asserted that "smi" would locate a record with a '*' field
> containing 'SMITH'.  It turns out you're right, which is *completely*
> unconscionable.
>
> You may not *like* or *agree* with my appraisals of and opinions about
> filePro's implementation design decisions, John, but I've been
> programming professionally in 4 or 5 languages for 20 years: I am
> entitled to hold those opinions.
>
> I'm giving up now. I really don't feel the need to be involved with
> a package that's designed so differently from every other procedural
> programming on the planet that it allows me to look foolish once a
> week, saying "oh, they couldn't possibly be so dumb as to have made
> it work like *that*; that's crazy stuff.

What's so evil about being different from other languages if most of the
differences are what make this language _better_ than others? As I often
point out in situations like this: Lot's of people eat mcdonalds and run
windows. I'm supremely happy to do neither and defy convention like a
bastard.

As Johns incredibly simple example showed, that behaviour is part of what
makes filePro a great way to get things done and keep users happy. It works
the way real people expect instead of trying to make real people act like
computers. That example is one of the core features of fp. Make that work
less user friendly and what do you have? Yet another language where it's
harder than necessary to give users what they want like all the others.

I bet the default of case-sensativity in most languages is exactly the
reason some old programs require you to have your caps-lock key on. So the
programmers didn't have to write twice as many tests as the real world
wanted. That was fine when the program was running on a dedicated dumb
terminal, but run that same program in a telnet window on a screen shared
with other normal programs and and you realize how stupid an limiting it is.
If the programmer had had a more real-world conscious development
environment he wouldn't have had to write such a klunky user interface.

Marks point that C started out case-sensative and later case insensativity
was added even supports the idea that it is an enhancement and an advance.
One fP started out with instead of needing to discover later on that they
needed it.

I think a lot of programmers and programs forget just what the point of all
this stuff is. The computers work for _us_ and on _our_ terms.

I do agree that for internal programming, you often need to know if
something matches exactly, but so long as there is any way to do it, that is
good enough, it doesn't have to be the default. I used to have a beef with
"=" != "=" also, in my case it was because it would say "smi" = "smith"
which really destroyed some (I thought) clever logic I was working on.
But in the end, that need existed in .5% of my code, and case insensativity
and ignoring trailing spaces and matching the least common denominator are
desired in the other 95.5% So what kind of a retard do you have to be to
want your tools to default in your favor less than 50% of the time and
default against you more than 50% of the time?

I think what's being overlooked here is the target fP is designed for. It's
not designed to be the most strict and precise math engine to control
nuclear reactors. It's designed to help users pack away data into a database
and then get it back out as effortlessly as possible. With that simple yet
crucial design goal in mind, I'd say fP started out from day one doing an
excellent job of  meeting it's goals and has only improved since then. If
you heard the things customers say about what our app does for their
business within one month of going live, the shear boggling numbers, after
switching from all manner of other programs written in all manner of other
languages up to and including the most modern ones that should have by now
aquired many of the traits fP started out with, there would be no way
continue to say some of these core design decisions were wrong. Not without
throwing basic logic right out the window and treating computer languages
like religeons instead.

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani