Andreas Klimas <klimas@[EMAIL PROTECTED]
> wrote:
> John Passaniti wrote:
> > Andreas Klimas wrote:
> >> this is the most complex way one could imagine and the source of
> >> the thinking that we need garbage collectors, memory mamangers
> >> and even object orientation.
> >
> > Complexity is not an absolute. It's a matter of perspective and
> > context. From the perspective of a programmer familiar with the
> > bare metal under a system, things like garbage collection, memory
> > management, and object orientation represent (potentially)
> > complicated protocols, complicated hardware, with more memory,
> > processor cycles, and watts used.
>
> sure I'm missing the correct wording. probably "whole
> systemcomplexity". where remote maintenance, packaging and
> distribution are also issues, as performance and tool availability.
Sure. But a lot of people get to treat most of those as "somebody else's
problem".
> > Ask these kids if they found garbage collection complicated. The
> > answer? No. They weren't even aware of it was going on. Ask these
> >
> > kids if they found object orientation difficult to grasp? The
> > answer? No. They found these were very natural abstractions and
> > metaphors that mapped nicely into their real-world experience.
>
> you are joking, don't you ?
> advantage of GC: you can switch off your brain in first place.
You can think about the parts of the problem you care about.
Abstraction is a powerful tool. You can think in terms of a virtual
system that's simpler than reality, where the things you aren't
interested in can be ignored. If the real system emulates the virtual
one adequately then you win -- you don't have to think about the ugly
details you aren't interested in. You can just get your work done. Very
nice when it works. Forth uses a virtual machine that's similar enough
to a simplified real processor that various people have built real
processors along those lines.
Lisp uses an even simpler abstraction -- everything is a list except for
a few atoms. You don't have to think about how to implement everything
as a list, that's somebody else's problem. You can do your own work and
assume that the lists work and that they have unlimited length, and most
of the time it will just work.
TCL has a different abstraction -- everything is a string. It turns out
to be inefficient to actually implement it that way, but that's somebody
else's problem. You can treat everything as a string and everything will
pretend to be strings for you.
I don't want to always think about registers. Forth doesn't make me
think about which registers everything is in, it lets me think about the
data stack instead. I like that.
> drawback: 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 ?
Lots of people find they get their results before memory use gets too
big. They can take their results and shut down the session and all the
memory leaks and fragmented heaps and so on all disappear. A day where
you solve your problems and you don't have to think about memory
management is a good day. Maybe memory management slows you down by
thirty seconds. You can afford thirty seconds when it keeps you from
having to think about memory at all. If memory management means the
whole system is running at 20% efficiency -- that's somebody else's
problem.
> > 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.
If somebody else has designed a complex system that works in a way that
*looks* simple, and it lets you get your results easily, that's fine. If
you want to do something that doesn't quite fit the way the system
designers intended you to behave, and it's hard to tickle it so it will
do what you want, that isn't so fine. Better to start with something
simpler that lets you build what you want.
Sometimes apparent simplicity is good enough. If you're ready to trust
that the complicated hidden stuff really does work just like it appears
to, then you can use the simple user interface to do the sort of thing
they expected you'd want, and it's easier and simpler for you. That's
good.
If that isn't good enough then you want to design your own stuff very
simply and clearly and carefully, because you're the one who's making it
work right. It isn't Somebody Else's Problem. Make a hidden mistake and
it's your work that will have wrong results. There might not be anybody
else testing it for you, reporting the errors.
|
