Evaluating opinions (was Re: "compile" vs. "tokenize" (was Re:Password Problem))

[Jay R. Ashworth]

On Thu, Jun 03, 2004 at 02:58:19AM -0400, John Esak wrote:
> > > not that way. He would rather be silent if he does not know a topic then
> > > contribute something that might be in error.
> >
> > Yes, he often leaves my questions unanswered.  *This* one isn't hard to
> > prove, at all.
> 
> I'm sorry Jay, but many (in fact, sadly most) of your questions) do not
> merit any response from anyone... Why, because you place them in this
> caustic, sarcastic, mostly disrespectful and quite "worng" tone...

If you have spent little enough time on the internet to miss the point
of the irony in the mispeling of 'workng', John, I can't help you.

> --excerpt from the very last message you just left on the list-----
> 
>   > *** A filePro Error Has Occurred ***
>   >
>   > Array Index Out of Range: dim prffac(7) -- Index: -35
>   >
>   > Output Processing
>   > Line Number: 22
>   >
>   > ai=prffac[np]*lia(11)
>   > ^
>   > Process contains a syntax error at position indicated.
>   > -----------------------------------------------
> 
>   Clearly, the syntax error is at '[np]', not at the beginning of the line.
> 
>   Could I take a moment to explain the concept of "worse than useless" in
>   the context of error messages that give too much detail, and it's worng?
> 
> --end-of-excerpt------------
> 
> I use this example because it is so sarcastic and so "over the top" and so
> completely "worng". Though it is a splendid example of 90% of your
> contributions here.

To each their own opinion, I guess.

> Just because you *say*  "Clearly" the syntax error isn't precisely at the
> carat pointer..." and you feel it should point directly at the array,
> doesn't make it so. I, in fact, totally disagree. The ^ is pointing to the
> beginning of the segment of code that contains an error... anyone can pass
> there eye along the segment to find the error... ESPECIALLY because it is so
> exactly described directly above as an array error. There is NO need to
> point directly at the array itself...

If the pointer doesn't in fact actually *point* at the error spot in
the line, then it is worse than useless.  We *know* the line is the
problem line; it's displayed.

Yes, John, it is "just because I say it".  But I'm sure I'm not the
only one who'd say it.  Bill?  Bill?  Bob?  Brian?  Mark?  If the
programming environment is going to point out an error to you,
shouldn't it either point in the right place of shut up?

*Should you* have to exercise judgement about whether to *ignore* that
pointer or not?  :-)

>                                        Maybe that would be nice if someone
> had trouble in telling where the array was in the segment... but it's
> obvious, no?

No, John, it is *not* obvious.  dclerk calls this a *syntax* error.

By definition, syntax errors are things which can be discerned by
looking at the non-running code on paper.  They are things which your
'compiler' (sorry, Mark :-) can complain about at compile time.

Remember, John, that you were once a novice filePro programmer as wll;
get back to that Zen empty mind state, and think about what this error
mesage would cause you to do then, if you took it at face value.

We experience filePro hands know which parts of the error message to
*ignore*... but we shouldn't have to.

>                Now, even if you had let it go at your pontificating "Clearly
> it should be THIS way and no other..." states... EVEN that would, I suppose
> be okay... but you further go on to say the totally nasty and completely
> unnecessary next line... about it being "worse than useless".

Worse than useless is a phrase which, while a touch incendiary,
admittedly, has few parallels; it's a real condition: when a program
goes out of it's way to tell you the wrong thing, and (assuming you
aren't smart enough to know what to ignore) wastes your time.
filePro's job is to make your programming life *easier*.  Job 1.
That's how they sell it.  Any part of it that makes said job *harder*
really is worse than useless, no matter how much that phrasing
personally ticks you off, John.

>                                                               Jay, a post
> like this (as most of yours regarding filePro are) is what I consider "worse
> than useless"... it is more than that, though, it is offensive as well.  And
> you expect to get "answers" to posts like these from Ken or anyone else?

Nope.  Didn't expect an answer to that one.

> Don't hold your breath. Better yet, use your breath to shout at compiler
> designers who right that the error is on or near line 276. It would be just
> as meaningless there though. The syntax checker is meant to provide good
> indications of what might be wrong...

Then it should do so, and not lie about extra degrees of precision that
it does not posess.

>                                     not waste time trying to cross-connect
> myriads of combinations of possible positions at which to place the pointer
> for you. A good description of the problem and pointing to the precise line
> where the problem is... well that's pretty good enough I think. Yes, there
> are times I've seen the carat at the wrong place, but it is almost never on
> the wrong line... and that's more than I can say for my Borland 5.0.

Don't have an argument there.  But if you can't position the damn thing
accurately, *do not display it*.  Why are you and I arguing about
*this*, my only point?  Do you really disagree with that assertion?

> > Case in point: if you walk an file on an index *in processing* (a loop,
> > say, on a child file), and execute code that a) modifies the key
> > file, and b)
> > uses getnext, that code will fail, because the filepro dclerk routines
> > that handle the lookups do not cache in advance what the next and
> > previous records *ought to be when you get to the current one* (in the
> > remote file).
> >
> > The code will miss child records, because the pointer will jump against
> > the backdrop of the universe of appropriate records in the child file
> > *after you rewrite the key field* -- some records will be visited multiple
> > times; some may be skipped altogether.
> >
> 
> How UTTERLY ridiculous! Almost not worth responding to this... but oh
> well...
> 
> 1) You should not be using getnext if the code is modifying the key...
> sheesh, do something wrong and then complain that it doesn't work write...
> :-)  That's pretty good Jay... but I've seen you do this quite a bit in the
> past also, so my point is made again. The error is on your side.

Does the 5.0 manual warn you about that WRT GETNEXT?

> 2) If a file were to be walked through with getnext (for whatever insane
> reason a good programmer might want to do this... although I can't think of
> any...)

My code created child records with the temporary, negative parent-file
foreign-key related to the terminal id of the user creating the
document, then walked the child file at commit time, replacing them
with the proper job number; I think that was the code; been 10 years.

And, John, isn't 'insane' the sort of invective you're accusing me of?  :-)

>            the description you gave of how it works is EXACTLY how I would
> expect it to work and furthermore would WANT it to work. The getnext process
> should point to where it would naturally point if the key were not being
> modified.

Precisely.  That is not how it *does* work, alas; go reread what I
wrote.  If you're GETNEXTing along records with key fields 1 through
10, and you change 3 to 8, your next record will be 9, then 10, and you
won't ever see records 4 through 7.

>           If the simple procedure of moving out of the getnext loop and
> restarting at the correct point isn't observed, than NO other functionality
> should be expected.  It is flatly obvious to me why this was never fixed
> since you reported it in the great detail you say. It was not and is not
> broken as you say it so (CLEARLY obviously) is. It was you who mentioned
> design decisions... I'm very happy it was designed as it is... it is totally
> predictable, reliable and sorry to say "clearly" working as it should. I'd
> be happy to send up some code that shows how to work with a lookup file
> which is changed during a loop... although it would NOT use the GETNEXT
> construct, which is simply the incorrect tool for the need.

I guess we'l just have to agree to disagree.  If getnext isn't there
for this sort of work, I can't see what it's there for at all.  If it
will break on this sort of modification, fine, *BUT DOCUMENT IT*.

I'll say it again, in large friendly letters.  THIS IS A TOOLKIT.  Its
job is not the end user apps; it's job is to MAKE MY PROGRAMMING
EASIER.  This sort of thing doesn't contribute to that end.

> > The point is that it is not necessary to *be* Ken to evaluate how well
> > Ken's products, and the support systems that surround them, serve their
> > intended target audience: professional applications programmers like me.
> 
> No, of course not, and I did not come even close to saying that...

If you didn't explicitly say that I wasn't entitled to opinions on
Ken's product, you certainly implied it.  And, on a much more basic
level; he's a seller, I'm a buyer.

>                                                                   However,
> one does need to be nice, well mannered and courteous about suggestions,
> which _you_ never are.

Never is a mighty strong word as well, John.  And well mannered is a
value judgement, on which topic it's clear you're much more
conservative.  This is a vendor forum, however unofficial, with a
vendor rep (three, actually), however unofficial -- you have to expect
some heat in here occasionally. 

>                         Try it sometime you might get those answers you say
> people aren't giving you. I'm sorry I questioned you about your background
> and the programs you have written. I can see it has really hit a sore point.

Projection, John.  It's a horrible thing.  I'm not insecure about my
background at all, nor do *I* find it insufficient to justify my having
and expressing the opinions I do, yes, ex cathedra.

> As for your saying you don't think filePro is a killer app... and um, you've
> used it for 15 years... well, um... CLEARLY you wouldn't know a killer app
> if you saw one. :-)

Again you miss my fundamental point there.  No sense repeating it, I
guess.

> I will not be answering any more on this thread you have turned it into some
> kind of a flaming thing... not gonna byte. :-)

Sorry you consider it flaming.  I suggest that you haven't been in the
right places long enough to qualify for your own pair of nomex undies,
if you think *this* is flaming, but so be it.

Have A Nice Day.

Cheers,
-- jr 'we now return you...' a
-- 
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

        "They had engineers in my day, too."  -- Perry Vance Nelson