John Passaniti <nntp@[EMAIL PROTECTED]
> wrote:
> Jonah Thomas wrote:
> > If you have to keep the limitations of the tool in mind, then it
> > isn't doing a perfect job of insulating you from the complex
> > details. But still it can be easier to learn enough about it to use
> > it adequately and then use it with its limitations in mind, than to
> > deal directly with all those details.
>
> Who said it was "perfect?" I can't think of *any* tool,
> computer-based or otherwise, that in any sense is ever "perfect."
> Every tool has limitations. Every tool has best and worst practices
> associated with it. Every tool ultimately requires the user to some
> degree understand how to use the tool.
I was agreeing with you. Sure, it isn't perfect, and it can be worth
using anyway.
Sometimes even abstractions that are utterly wrong in a lot of
circumstances can be useful if you know how to stay within the domain
where they're useful.
> > Comp.lang.forth has some different groups who sometimes talk at
> > cross purposes. I'd say that two of them are people who just want to
> > get their work done, and people who're thinking like Big Beavers. If
> > I pretend I have a Forth processor, or if I actually do have a Forth
> > processor with a simple Forth OS, then ALL the complexity is MY
> > complexity and none of it is SEP (Someone Else's Problem). If there
> > is one true measure of complexity that's probably the one to use.
> > (But until I actually do it and measure it, I don't have a true
> > measure.)
>
> I don't find that a useful measure of complexity as it is entirely
> subjective and suffers from observer bias. You can create the most
> byzantine monstrosity ever created, but because you created it and you
>
> understand it, you can claim it isn't complicated.
If it's all yours then you don't have complexity that's hidden because
somebody else handles that part. You might have complexity that's hidden
because you deal with it and forget it's there.
> > It might be good to recognise when someone is in that mode and just
> > accept it. He won't do much harm if you ignore him. Occasionally he
> > might produce something useful. You don't want to depend on
> > immediate results from somebody who wants to recreate everything
> > from scratch. He's likely to be mostly useless. But if you do pay
> > some attention in your spare time he might come up with an
> > interesting or amusing idea.
>
> That is one of the reasons I even bother to read messages in
> comp.lang.forth. Occasionally, someone here comes up with a unique
> idea or a different perspective. That's the kind of thing that I find
> valuable.
People might do more of that if you don't argue with them about their
foibles. The time they spend arguing that they're right and you're wrong
(when they're wrong or it's a subjective thing anyway) is time they
aren't doing anything particularly interesting.
> > Perhaps they should build their routines to solve some particular
> > problem. Then if all goes well they wind up with something simple
> > and consistent that actually fits at least one problem. I think
> > that's better than starting out with a solution you think ought to
> > be useful and then try to find problems it will fit.
>
> That's often how libraries start. You take a application framework
> like Ruby on Rails. The Rails developers didn't sit down one day and
> say, "gosh, I'm going to create this framework from nothing and maybe
> someday people will use it." Rails was a library that came from the
> development of a specific web site. It then grew from that.
That makes sense.
> > Rotation angle and distance? You can't just tell the turtle to move
> > from where it is to some particular spot? That does not sound like a
> > very good turtle to me.
>
> No, you can't just say move to a X/Y point:
>
> http://en.wikipedia.org/wiki/Turtle_graphics
>
> Read the overview and understand what the phrase "turtle graphics"
> means. Turtle graphics is by definition about a system that describes
>
> motion by relative displacements. This is not a term I invented.
> It's existed since the late 60's.
Regardless of the history, you're describing an unneeded limitation that
gets in the way. I doubt the poster who described a turtle graphics
approach to drawing a box would want that limitation. You told us you
don't want it.
> >> This is what drives me nuts about many of the messages in
> >> comp.lang.forth. These discussions of complexity and efficiency
> >are> far more often than not discussed in a vacuum, as if they were
> >> absolutes that don't rely on context. But they of course do.
> >
> > If they don't show context, and they also don't fit the context
> > where the people involved are doing everything, then you might point
> > that out.
>
> Thanks. And I often do.
>
> > There's nothing wrong with discussing where to put the complexity so
> > it will least get in the way. And there's nothing wrong with
> > discussing whether a particular sort of complexity is needed at all
> > for a particular problem.
>
> Nope. But when such discussions exclude the possibility of examining
> ways of reducing complexity that don't match people's assumption (that
>
> by sprinkling magic Forth dust over everything all problems are
> solved), that is where I step in.
Sometimes that can be useful and other times not. When a bunch of
public-school administrators are discussing how to improve the school
system, they won't be interested in suggestions to eliminate the public
school system and replace it with something entirely different. Arguing
that they ought to be interested in that approach will not get them
interested. Sometimes it's better not to distract them.
> > And it isn't terrible if people discuss
> > philosophical problems that have no immediate application, provided
> > you don't get sucked into them and waste your time. But suppose
> > people are discussiong "complexity" and they're thinking about
> > whole-system complexity, and they're doing it wrong. Maybe they're
> > ignoring parts of the system that need attention. You could do them
> > more good by showing where they're wrong in their own context, than
> > by showing that other contexts are often useful.
>
> Ummm, that's the point. If someone is locked into a narrow context
> and can't see the larger perspective, then "showing where they're
> wrong in their own context" can't work. The very limitation imposed
> by their narrow context prevents them from seeing anything else.
It's possible that something good might come out of their limited
viewpoint. Sometimes it's just a waste. I read that there was a
mechanical approach to TV images that involved a spinning disk -- it
successfully produced an image but it wasn't competitive with cathode
ray tubes. I read that it's theoretically possible to create analog
electronic circuits to get roughly the same results as any computer
program, but for most purposes the complexity and the stability issues
aren't worth it. If people get stuck in a limited viewpoint and they
don't want to come out, isn't that their problem? They might possibly
develop something interesting despite themselves. It's kind of you to
offer a hint of a way out, but when they don't want to hear it, why
berate them?
|
