Re: If you were developing a database in Forth...

On Jun 4, 2:51 am, Jonah Thomas <jethom...@xxxxxxxxx> wrote:
No, you again utterly and completely missed the point. You're getting
extremely tiresome.

I got your point. I found your point superficial. I'm sorry if you
thought it was a good point. It wasn't. Move on.

You took one throwaway line from Brian Fox. You did not ask him what he
thought was "yet to be duplicated" but instead you assumed a specific
answer, explained why it was wrong, and claimed he was wrong. Was this
perhaps a continuation of some previous discussion from a long time ago?
I have no idea how you got all this from one short phrase otherwise.

Yes, I assumed what was "yet to be duplicated" because I remember the
original story and I remember what distinguished the approach the
Forth programmers took from the approach taken by the programmers
using a "conventional database package." What Elizabeth Rather
described in the story was a binary indexing scheme which allowed for
more efficient access to entries in the database-- something that some
modern database engines *do* provide (and that others can have grafted
on through third-party extensions). And so the "yet to be duplicated"
claim is false.

Again, nobody is going to hold your hand and type a query into Google
for you to find the context of past conversations. If it's too much
of a bother for you to do basic research on the topic (the story, what
a binary index is, what database engines support such a feature), then
maybe there are other conversations you would be happier in
participating in. Maybe you should just stick to conversations that
have no history behind them-- another week has gone by, so maybe
someone is trying to optimize a divide routine again. Have fun with
that.

Yep, which is why I asked that people not make assumptions and just
read what I literally write instead of taking past statements and
trying to weave it all into some kind of larger narrative.

If you aren't weaving this particular example into some larger narrative
then what the hell are you doing?

This is pretty funny. I write that my interest is in learning from
project successes and failures, and to do that requires asking
questions and applying some basic critical thinking skills. You for
some reason find it difficult to accept that at face value. Gosh, I'm
sorry if the process of diving in to the legends and lore of Forth
occasionally results in conclusions that run counter to the fan-boy
nature of this newsgroup. That's reality for you.

A few years ago, I tried a change in my writing style as an
experiment. I observed that no matter how many messages I wrote that
were in support of Forth, that a single message where I was critical
of some aspect of it caused me being labeled as somehow being anti-
Forth. So the change was to start putting a preface in my messages
where I would issue some praise of Forth to keep the fan-boys happy
before I wrote something critical. I expected that those people who
(like you) apparently have no memory of past conversation in
comp.lang.forth would see balance-- both praise and criticism. It is
after all how I approach Forth (and most programming languages) as a
mix of strengths and weaknesses.

The experiment failed. I found the exact same response. The act of
writing anything critical about Forth caused some people (like you) to
focus on the criticism and ignore what else I wrote-- even when it was
part of the same message! That's either a lack of basic reading
comprehension skills or some mighty powerful selective perception.

I've met people who want to correct all the errors on the Internet. They
tend to be very unhappy; somehow errors propagate faster than they can
correct them. You at least have restricted your scope to one perceived
error on one newsgroup. I'm sure you must be much happier that your
scope is limited to an achievable goal. All you have to do is object
every time you perceive somebody might be making this error, and soon
nobody will give the appearance of making it any more and you can rest.

Bizarre, and yet more evidence that you're not taking my words at face
value, but injecting a larger agenda in them. Sorry, but I have no
interest in playing your game.

Dennis Ruffer provided source code and documentation. Why haven't you
dived beneath the surface and critiqued the actual techniques? Instead
you have only made a completely unsupported claim about what you claim
is the only innovation involved.

Dennis Ruffer's provided source code and documentation for *a*
database package. That database package does not have the code that
implemented the indexing scheme described in Elizabeth's story, which
makes sense as that scheme was application-specific and the database
package is intended as a generic set of routines that can be adapted
to an application. Thus, I'm not sure why I should have issued a
critique of the techniques used in Ruffer's database package when it
has nothing to do with the claims.

Again, if you're going to play along, find the story, understand it,
and then maybe you'll look less foolish.

Have you had that diagnosed? OCD? Asperger's? A proper, accepted, normal
format for a war story involves somebody else who didn't get results so
the project was behind schedule. Then the heroes come in and save the
day by making special innovations that work. That's just the format of
the story. Then you complain that they're glorifying the language, and
you argue that they should explain at length how the language was not
important. [...]

False. There are stories when the language *is* important. An
example would be a story about how dynamically-compiled code is
intrinsic to the success of a project. Another example would be a
story where the interactive nature of Forth was critical to the
success of a project. Another example would be a story where the
small runtime and compact representation of code make a project
successful over a language that had a less efficient representation of
code. You're starting with a false premise. Stop it.

Explain why the first guy failed -- explain it was nothing to
do with what language he was using, it was some other specific flaw.
Explain why the heroes succeeded -- nothing to do with the language, it
was their own individual superiority. Make sure that everybody
understands it didn't matter what language they used, in case somebody
is so naive they think it was all because of the language.

Wow, when you have a wrong idea in your head, you really go with it,
don't you? Damn, don't let facts and details get in the way!

The story we're discussing was about a database application that was a
success because of an indexing scheme that wasn't available in a
particular database package. In this specific story, there is nothing
about Forth that enabled that success. It was entirely the
cleverness, insight, and skill of the programmers who saw a better way
to approach the problem. The technique could have been implemented in
any language (and probably even the database package itself if those
programmers were clever enough). This is not a blanket statement that
language doesn't matter. It's a statement that language didn't matter
THERE, in that specific story. You're the one blowing up the scope of
my statements. You're the one taking my simple, constrained, and
qualified statements and pretending they mean something more than what
I'm writing. Again, take what I write at face value and you won't
make that mistake.

This is bull***. This is stupid. How about this, why don't you find a
newsgroup where people are telling real war stories. Somebody tells a
story about how their patrol defeated a north vietnamese patrol, or an
iraqi patrol, etc. You tell them to make sure they explain that it was
all in the particular techniques they used and their individual
excellence, and it really didn't make any difference whether it was the
US army doing it instead of the russian army or the chinese army or the
argentine army. Given good equipment and training chinese soldiers are
100% as good as american soldiers and french Marines are 100% as good as
US Marines. Explain to the Marines over and over and over that there's
nothing special about being a Marine except the specific training they
get that any other army could teach. Repeat at every opportunity that
there's nothing special about being a US Marine and it's important that
they realise this because if they have unscientific false beliefs it can
get them killed. Go bother the Marines who want to tell war stories and
leave us alone for awhile.

Wow! That's a dive off the deep end! But I guess it does make sense
in a way-- you've already shown poor skill in constructing analogies
and that context doesn't matter to you. So at least you're being
consistent.

How would that have helped? They were consultants for a team that was in
trouble. The job was to get the team out of trouble. Telling the team
leader that you could do the work yourself far better than his team
could do it, only insults them. Documenting the claim would not help.

Yes, you've established your story and the premise you want others to
conclude from it. Sorry, but my real-world experience tells me
otherwise. My real-world experience has both cases where we found the
complexity of a project to be greater than what the client expected,
and cases where we came in with bids for less than what they
expected. In the cases where we estimated more than they expected,
the act of documenting our estimate showed the client where they
missed details. In the cases where we estimated less than they
expected, the act of documenting showed them our approach and gave
them confidence that we not only knew what we were doing, but had a
plan to get there. And yes, the company is doing very well.

You want your little story to be about rejecting claims because
management was insulted. That's a common theme in comp.lang.forth,
and one of the more cherished rationalizations for why Forth
consultants don't win jobs. If my company was the one bidding on that
project, management might have been just as insulted, but they would
also have in our bid a clear example of how we would meet our claims.
Your story has nothing like this. Your story is about a consultant
pulling a number out of the air without supporting evidence. And
somehow management is supposed to find trust in that?

Let's turn this around with something more practical. You've been
working on your house. Maybe you're adding a deck. Maybe you're
fixing the roof. Maybe you're redoing the kitchen. Whatever it is,
the project isn't going well. It's taking way longer than you've
expected and you've spent way more than you want. You expect at least
another month and $8000. You decide to call a couple professional
construction companies and get some quotes.

A truck pulls up and out pops a guy who looks over your work, writes
some numbers on the back of an envelope, and then turns to you.
"You've done this all wrong, but me and my crew can come in and fix it
in a two weeks for $4000." He hands you a business card and then
drives off.

Shortly afterward, another truck pulls up. Out walks a guy who looks
over your work, takes some notes, snaps some pictures, and then says,
"I'll be back in a day." A day passes, and he comes back. He says
that you've done several things wrong. He starts by describing the
errors not in vague generalities, but in specifics. He points out
where you didn't meet code. He points out areas where the workmanship
was poor. He points out problems you weren't even aware of. And
then, he pulls out some papers. The first is a spread*** that
enumerates the bill of materials and his suppliers. The second is a
Gnatt chart showing the specific tasks with their sequence and
duration. The third is a set of written testimonials from other
customers with contact information. The final totals? He says he can
get it done in three weeks for $5000.

Both contractors shattered your fragile ego and you're insulted. But
there is a difference here. One contractor swooped in, said you did
it wrong, and made a claim that wasn't supported by anything. The
second contractor came in, demonstrated a more thoughtful approach,
said you did it wrong, and made claims he carefully documented.

In your world, you would probably ignore both contractors and continue
on yourself. After all, you were insulted. In the real-world, the
second contractor is more likely to get the job. You were just as
insulted, but there is a world of difference between someone
arrogantly saying, "you did it wrong and we'll fix faster than you
can" and "you did it wrong, here's why, and here's how we're going to
fix it."

Do you very often get accused of being mentally inflexible and
unwilling to see the other guy's point of view?

Actually, no. At work, I am often used as a proxy for coworkers and
clients because I spend a lot of time trying to consider positions
from their viewpoint. And at home, my husband often complains
(typically when discussing politics) that I spend too much time trying
to get in the heads of people I disagree with and see things from
their perspective.

I see your point of view. Honest. I just don't find your views
terribly compelling. You make poor analogies, you make fantastic
assumptions of agenda on my partn, you offer overblown arguments (your
literal "war stories" paragraph above is *priceless*), and you don't
even bother to do basic research into the context of discussions you
engage in. So yeah, I see your point of view. It's not a view I find
much worth in. Sorry.

.

Loading