> X: Sure does. Geos's API is facinating-- one of the nicest I've worked
> X: with, but SO different from others that it's hard to translate. Helmar
> X: accused its memory management of being archaic-- no, it's much more
> X: advanced than most PC operating systems. What it is is different!
> Java just made away with all this silly (my expression!) pointer stuff, which
> makes an awful lot of sense to me. I didn't say the memory management is
That was a silly and foolish choice, and ruins a large market for them.
They didn't do away with it by replacing it with something better; they
did away with it by removing it completely. Their mistake. Oberon did
MUCH better; they replaced pointers with a safe, easy to use concept
called references.
> archaic -we all know it isn't-; I said the allocation of it via manual C
> coding is. That's the last thing I want to worry about when writing
> applications.
And you should'nt have to. I'd like to help design a language that
helped you to do that-- but I'm not up there yet. Sorry.
However, in all the domains in which I work, pointers and manual
allocation are important and needed. I've never had any trouble with
memory locking in programs I write; it's attempting to translate other
people's programs to Geos that gives me the heebie-jeebies. That last is
why a language which handled memory allocation automatically would be
nice; all the programs written in it would be immediately portable to
Geos.
> On the risk of being simplistic, that's why I always liked silly simple dBASE.
> I could concentrate on the code and didn't have to worry about allocating
> chunks and blocks, locking them, unlocking them, marking them dirty, you name
> it.
And this is how _you_ should code. It lets you get your work done. My
work is different, and is the sort of work that gave you dBase in the
first place.
(By the way, isn't IZL perfect for what you describe?)
> _I_ think we have progressed to a stage where this shouldn't be necessary
> anymore, and the Java guys have proven me right.
How many megabytes per second can an implementation of LZS compression
achieve when written in Java running on a Java-written platform? You
think maybe .0002M/sec (naw, that's more like compiled Java code)?
Really, you DO need the pointers. Compare that figure to the current
LZS-86-ASM benchmarks, and see the difference (Ithink that the '86 clocks
at about 500K/sec, but I'm a little mixed up 'cause I'm helping with the
rewrite to '386-- SPEEDup so nice I can't even say how much).
> Helmar