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.
This is this ridiculous and condescending notion in comp.lang.forth that
the use of libraries and tools that provide some abstraction is "not
thinking" or "locking into someone else's problem" or other nonsense.
If that's true, then it's also true of Forth. When you use Forth, you
are choosing to not think about the many other ways that a problem can
be solved (for example using non-procedural imperative languages). And
when you use Forth, you are locked into a world-view that says your
problem is ultimately to be solved with the key abstractions provided by
Forth-- the dictionary, stacks, and a direct view of the machine.
It's not the only way to consider problems.
> 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.
> 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.
> 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.
Most every successful library that exists was at one time part of an
application that solved a problem. The developers identified that part
of the application could be extracted and reused, and then it began to
have a life of it's own.
> 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.
>> 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.
> 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.
|
