Hi.

> Boy, that's any easy question. ;-)
> Better than any other language I have ever used.
> 
> Smalltalk is the *only* language I've used
> that allows me to spend the *majority* of my
> time solving the problem at hand, rather than
> futzing around with language details.

Ain't the Smalltalk-to-C translator a Very Good Thing? :))))...

> After all, we are getting paid to solve
> the *customer's* problems. So let's do it the
> easy way, shall we?

This is especially true with math. And I've done a lot of math with Pascal and
hand written Assembler... I remember my optimization runs in the night with my
386dx/33. Getting a scanning routine from 18Kb per second to 1.87Mb/second with
a scanning loop of 4 instructions, that when properly programmed for Pentiums
was very very very much faster. I also remember that with Alejandro Weil here we
programmed a prime number finder, first in Pascal and then into assembler. In
the same 386dx/33, it got all primes less than one megabyte (1048576) in less
than a minute using the root algorithm avec intelligence (like, don't test
evens, don't try even divisors, don't try multiples of 3 and so), making use of
all programming tricks we knew, including this little jewel I found while at
this program:

If an Intel processor divides an odd integer by another odd integer, and after
doing this the Z flag is on, then the remainder is zero.

Doesn't apply if the integers are not odd, neither on other chips. I have tested
this on Intel processors starting at the 386 :), 486s also, pentium 133, 166,
200mmx... the attached program runs for hours on intels and just a few fractions
of a second on amd, cyrix and others. This allows me to skip an or instruction,
which saves 2 cycles in a loop. As that loop is the divide then check if
division was exact loop, it's heavily called. It's kinda of natural to set the Z
flag if remainder is zero after integer division, I wonder why don't cpus behave
like that. In any case, here (200mmx), the prime finder finds them all (less
than 1 meg) in less than 5 seconds updating the screen once per system clock
tick, about 18.2 times per second.

In any case, now I compare this to what happens in Squeak: I get extremely happy
if I can beat LZ+Huffman for coding audio with an ADPCM codec (plus interesting
models!) at a miserable 3.7k symbols coded per second. I wouldn't have been able
to devise such models neither the whole thing this easily, and I wouldn't have
been able to even play with it in this way. Not to speak about really using my
time to think about the problem I'm solving instead of solving the problem
twice: once in my head, and then the problem of telling the computer to do
something similar to that... I also like that as humans model things with
language, Smalltalk is actually a natural way of doing things since, modulo it's
on a computer and has no will of its own yet, it's really a model on the human
way of thinking.

So, I get happy when I beat LZ+Huffman at 3.7k symbols per second, and then I
multiply by a conservative factor of 50 to get the "C+Assembler" performance.
That's something like 175k symbols per second, some 10.5m encoded symbols per
minute. This compares to any LZ+Huffman compressor here, and is actually faster
than some of the more powerful ones (like Jar32 that uses LZ+Huffman taking up
to 23.5Mb of ram, with a 16Mb compression memory usage).

I prefer it to be great, slow, and then multiply and compare. I insist that I
wouldn't have been able to do all this without Smalltalk, and if I had done it,
it would have been worse, horribler, and I wouldn't have liked it :). Plus I
would have taken much more time, since with Smalltalk I can think about my
problem almost all the time.

Andres.