John Passaniti <nntp@[EMAIL PROTECTED]
> wrote:
> Andreas Klimas wrote:
> > sooner or later you will see memory usage growing
> > because of caching objects which in turn will keep the whole
> > object database in memory. so you introduce weak references
> > here and here. but there might still hidden cached objects
> > which are very hard to find.
> > conclusion: you have to think anyway, why not avoiding GC in
> > first place ?
>
> Because if you know the strengths and limitations of the tool, you can
>
> effectively work with it. People who run into the problems of hidden
> caches are people who aren't using the tool properly. Doctor, it
> hurts when I do this. As always, the problem isn't with the tool,
> it's with the use (or misuse) of the tool.
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.
> >> Complexity is one of those terms tossed around in comp.lang.forth
> >that > often has very little if any meaning. Complex relative to
> >what? > Complex relative to who? It's a lot like the word
> >"efficient" that is > equally abused here.
> >
> > it's not my Job to unswer such esotherik questions. if you
> > don't see 'complexity' or 'inefficient' I can't help you.
>
> It isn't an esoteric question: Words like "complexity" and
> "efficiency" only have meaning in a context. Saying (for example)
> that garbage collection is complex may be true in some contexts, but
> false in others.
> And if you can't see that, then you either don't have as much
> experience as you claim, or the scope of your experience is pretty
> limited.
In the Anthony Villiers stories by Alexei Panshin, there was a large
organization called the Big Beavers. They were a lot like the Boy
Scouts, they went camping and studied ecology and such. Their announced
goal was to be able to start out naked in some particular ecology and
build civilization there from scratch, and some people would make a
start at that for multiple biomes. It looked like a pleasant pastime --
hike into a place and dig your latrine and your firepit and such, go on
nature walks etc. I didn't notice that any of them were reaching the
point of escavating iron ore and building smelters.
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.)
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.
> I believe there is in some sense a "conservation of complexity." That
>
> is, for non-trivial problems, there is a set amount of complexity in
> the system that you can't remove. It's in the nature of the problem
> being solved.
>
> What you can do is push that complexity around. So a programmer might
>
> write simple "Do What I Mean" code expressed in some high level
> language that handles all the underlying low-level details. There,
> the complexity has been pushed to the language. Or, for the same
> problem, a programmer might choose a simple low-level language (like
> Forth), but now have to tediously specify each and every step. There,
> the complexity has been pushed to the programmer.
If you have to do it all, then you might push the complexity into code
that you can write once and use many times -- some sort of library. Or
you can move the compexity from runtime to compile-time or from
compile-time to edit-time. But it's still your complexity and you have
to deal with it.
> The mental trap here is assuming that one approach is always right.
> And I think part of that mental trap comes from programmers who work
> with blinders on, focusing entirely on narrow aspects of a system and
> never stepping backward and looking at the system as a whole. We see
> this in comp.lang.forth all the time-- programmers wringing their
> hands over how complex a particular solution is, seeking something
> simpler. But that is usually meaningless. I can't count the number
> of times I've had a programmer proudly hand me an exquisitely crafted
> set of routines that presented some utterly simple and consistent view
> of problem being solved. And then, when I have to actually use that
> in a system, I find it's too simple-- that it doesn't do what I want
> or need. The result? You either end up rewriting the "simple"
> routines or you write some abstraction around it to make it work like
> you want.
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.
> I'll toss out a simple example. A while back in comp.lang.forth,
> there was a discussion about graphics and how to deal with some of the
>
> complexity of some basic routines. Say you wanted to draw a box. In
> the usual approach most people would take, you would need at least
> four arguments on the stack-- the X/Y location of a corner and either
> the X/Y location of the opposite corner, or a length/width pair.
>
> Someone came up with an object-oriented approach of using turtle
> graphics. Have an object (the turtle) that maintains state about
> where it is on the screen, and give it commands to move relative to
> where it is. So drawing a rectangle breaks down into four "move a
> distance and turn 90 degrees." Simple and elegant.
>
> So someone takes the simplicity and elegance of this design, and now
> they want to draw a line graph with quantities expressed in X,Y pairs.
>
> And suddenly what would have been a simple line drawing routine now
> becomes a problem where you have to calculate the rotation angle and
> distance to move the turtle. Not difficult, but additional complexity
>
> driven by having something underlying that is too simple (or at least,
>
> not matched well to the problem being solved).
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.
> 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.
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. 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.
|
