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

[Jay R. Ashworth]

I inadvertantly took this off list:

> > On Wed, Jun 02, 2004 at 01:50:10PM -0400, John Esak wrote:
[ I wrote: )
> > > > Offhand, I don't remember; check the archives; they've all been
> > > > on-list.
> > > >
> > > > Many of them are, admittedly, design decisions...
> > >
> > > Ah, okay... those pesky design decisions are what you disagree
> > on ... that's
> > > a little differently colored horse.  Just one more question, still just
> > > curious. What programs have you designed that are on the same level as
> > > filePro as regards to scope, i.e., depth of complexity, user-base,
> > > usability, performance, productivity, commercially distributed,
> > supported,
> > > etc.  Any? I'm now just trying to gauge why your disagreement on "design
> > > decisions" has value. Don't take offense at this, please. Just asking.
(me again:)
> > You may not think it has value to you.
> >
> > I needn't be a toolmaker to be able to judge the value *to me* of a
> > given set of tools, nor to be able to discern and describe where
> > changes and improvements to those tools would make the work I use them
> > to perform easier.
> >
> > Being a toolmaker makes it easier to explain the desired improvements,
> > and to understand better the tradeoffs (or designer brain damage :-) that
> > might have inspired them, but it's optional.
> >
> > But even applications design is useful in honing one's design skills
> > and the ability to appraise those of others; in 15 years I've
> > participated in a ground-up rewrite of Fourgen accounting and created
> > at least half a dozen custom OE front ends to it, including for
> > equipment rental, used musical instrument sales and trade-in tracking,
> > manufacturer's repping, overseas import purchasing, telephone sales and
> > repair tracking and commercial film processing, printing and finishing,
> > all with full system analyses.  Oh yeah, records storage tracking too.
> > :-)
> >
> > But no, not all of them can be characterized as design decisions,
> > either.
> >
> > If you're that curious, I've got every posting to the list since I
> > signed on; I'll go find some.

On Wed, Jun 02, 2004 at 08:48:09PM -0400, John Esak wrote:
> Okay, I appreciate your response. Seems quite reasonable... but why would
> you respond off-list... privately to me... and not even mention that it is
> only a private response?  A little strange... do you not want this answer
> posted??

Cause I'm a slob.  I'll bounce it back to the list.  Thanks.

> I think your response makes complete sense... but on the other hand... just
> because you can drive a car very well, even extremely well does not put you
> in league with car designers who have been designing cars for 25 years...

It does not make me a car *designer*, no.  But it is not necessary to
be a *designer* to evaluate the usefulness of the things people design
for you to use.  I do not need to be Paul Baracq to appreciate why his
1978 design of the BMW 630 series body is still one of the classiest
sports cars on the road today -- though I may not know why I think so,
or what makes it that.

Same for his engineering counterparts.

Though there I'm on somewhat safer ground.

> extremely knowledgeable and capable in many areas... but I see I am right in
> that you have not designed anything close to a "filePro". I, too, have done
> myriads of application builds from ground up, we all have mostly. Hell,
> FourGen, whether you know it or not, was _entirely_ built in filePro
> originally

You bet I know it; I've rewritten most of it.

>            and I _helped_ do a lot of it when they needed help. It doesn't
> make me a programmer on the level of Ken, and never will. So while I can
> make every kind of suggestion and deliberate on every possible ramification
> of this design decision or that... I can't do it from the position of one
> who has already one enormous killer-app under his belt.  (and incidentally
> if you don't consider filePro a killer app... well, you would just be plain
> wrong in that case.)

I don't. 

It's not an app.  Not in its current incarnation, and more
importantly, not in its current *marketing* scheme.  It's a *toolkit*.
And who it's a toolkit *for* is people like me: application designers
and builders.

Would you require that people who write reviews of power tools for
Popular Mechanics be *tool designers*?  No.  You expect them to be
profesional *users* of that tool.

That is precisely the relation I hold to Ken.

And it's not uncommmon, frankly, for tool designers who *don't* use the
tools every day for their intended purpose to lose sight of how well
they do that job.

Does Ken work on application level code on a daily basis?

>                       Anyway, I only wanted the clarification that you have
> not really shown Ken to be in error about something "technical".

You haven't received it, yet.  I offered to look.

>                                                                   I've
> written some humongous C apps... I've written some humongous filePro apps...
> I've written code all of my adult life and I still have never once found Ken
> to be outright wrong about anything "technical". I'm not saying he is
> perfect by any means... but he is careful, and does not often throw out
> anything that he can't support. Nor do I think he ever will... he is just
> 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.

> That is all I was on about. Please don't think I don't value what you say,
> but I am sorry to say I value Ken's opinions far more. Comes from 20 years
> of knowing him and his capabilities... using filePro... seeing his source
> code...

There were parts of 4.1 I wan't all that impressed with.

I don't know that I could enumerate for you; the client who was a port
site has decommissioned that 3b2.

>         knowing his nature. Perhaps, if I knew you in those ways, you would
> have that same respect. Until then, I see your contributions as valuable in
> the same way I feel mine are... and wait to see a time when you truly
> disagree with Ken on something and are more "right" than he.  :-)  Hasn't
> happened yet... so if _you_ wanted to pore through those thousands of
> archived messages to show me differently... feel free.  It's not that
> important to me. I just see you placing yourself at Ken's level of technical
> expertise,

Nope.  We swim in different water.  But his output is what I make my
living on, and I feel perfectly free, after 15 years of using both it
and it's competitors, to comment on how well I think it does that job,
and when and why I think it fails, and what I think it *should* be
doing.  And if you look back, I believe you'll see that that's mostly
what I was doing.

>            and I wanted to see why you feel you should be considered so. To
> be honest, I don't think there is much of his code that you could even
> understand.  Maybe I'm wrong... but remember... I've seen his code, and
> haven't seen any of yours. I may be completely wrong on this. That is why I
> asked in the first place. I hope I didn't upset you. I didn't mean to.

I've actually got some of my completely original code laying around; a
records storage tracking system I wrote for a client in 96, from the
ground up.  It reminds me of...

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.

I know this isn't just me; I've seen it bite others in my tenure on the
list.

Now, it's easy to make the assertion that whomever designed and
implemented that routine couldn't have been expected to forsee that
situation, but there are three effective (in my opinion as a
professional user of programming support tools since 1988) counters to
that argument:

1) it works correctly if you do it in a report (modifying the local
primary key, which is the practical analog).  This is, of course, a
side effect of the fact that reports are run by building a temporary
static index on the appropriate fields, and then running the report
against it, but that's not germane.

2) there doesn't appear to be any reasonable a) way or b) reason to
depend on *this* behavior, nor does it seem useful, whereas the
alternative behavior is demonstrably useful  -- and therefore there's
no reason to keep it, and every reason to change it...

but most of all 

3) I reported it (in excruciating detail) in 1995, when it lost me a
couple of days of coding time, and -- TTBOMK -- it's never been
changed.

And that isn't remotely the last or smallest sort of item that not only
never gets fixed, but that no one seems to care about.  The reason
programmers come up with workarounds and give up pounding on the nail
is because all they ever do is get a sore wrist.

But I don't mean to get off on a rant.

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.

It is my opinions on that topic -- many of which, unfortunately, run to
"not well, and here's why, although I don't think anyone's listening"
-- that you're attempting to evaluate here.  And, admittedly, often, I
don't bother to 'show my work', enumerating all the steps behind why I
think the way I do about a particular opinion.  Indeed, often, I formed
the opinion so long ago that I don't have the support to hand anymore,
only the reults.

But that doesn't invalidate the results.

Not in my opinion, and not, AFAICT, in the opinions of many of the
other programmers on this list, whose proficiency I infer from the way
they present their ideas, and from the code of theirs that I see.

And no, it's not just those who agree with me... :-)

Cheers,
-- jra
-- 
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