🚀 go-pugleaf

In article <445369$o2n@orion.cybercom.net> jerry@cybercom.net (Jerry Shekhel) writes:
>Kazimir Kylheku (c2a192@ugrad.cs.ubc.ca) wrote:
>:
>: That's just the static code size. What about the total count of
>: executed instructions? I bet that goes up quite a bit more. Each
>: time you have to dereference a handle, you have to execute twice
>: as many instructions. Chasing dynamic links becomes slower.
>:

>Nope.  Your "twice as many instructions" comment is BS.  You lock,
>access as many times as you need, then unlock.  You don't have to lock
>or dereference twice for each access.

Well, reality is much more complex. If you do encapsulated routines
for access to data structures, like linked lists, etc, you have to do
lock/unlock in each routine. If you port code from system with linear
memory, often it is very hard to find block boundaries properly.
These are examples that spring to mind first.

>: >
>: >That says more about your skill as a programmer than it does about the
>: >Mac's memory scheme.
>:
>: Not every programmer wants to go through blockhead exercises that have
>: nothing to do with the computing task.
>:

>But they all have to.  It's called programming.  

It is called brainf*cking. On VM systems I do not have to go through
all that crap, my code is both smaller and faster and memory 
requirements are comparable or less than Mac or Win3.x.

>It's the "blockhead
>exercise" that programmers have to do so that others can perform their
>computing tasks.  LISP bigots will tell you that malloc() itself is a
>"blockhead exercise".  Compared to all the crap you have to learn to write a
>modern application, handles get lost in the noise.

It depends on your definition of modern application :).

>:
>: I wouldn't say that I am closed-minded person. Hell, I implemented the
>: crap myself, foolishly thinking that heap compaction would be neat!
>: After all, memory is a precious resource with which one must be
>: very frugal. Once you use it up, ain't none left!
>:
>: After I saw what my favourite list, B+tree and hash-table module turned
>: into when converted to use double indirection, I erased the project at
>: once!  I went to the library and pulled out Knuth, which at once set me
>: straight.
>:

>Perhaps you should have read the Knuth books *before* you wrote your
>heap compaction algorithm.  There is no need to do double indirection
>on every access.

Actually, there are situation when there _is_ need to do indirection per
each access. And when you try to block your accesses, you might create ugly
bugs that are very hard to find. On other hand, in VM systems MMU hardware 
does indirection for you automagicaly.

Cheers,
	Fat Brother.

Fatal Error: Couldn't enter Windows, use Doors.