Posted Sep 6, 2007 15:42 UTC (Thu) by foom
In reply to: Taste
Parent article: LinuxConf.eu: Documentation and user-space API design
> ITA goes to great lengths never to trigger a GC cycle, because the first one would
> take longer than restarting the program.
Not true. CMUCL/SBCL's garbage collector isn't the most advanced in the world, but it's most
certainly not *that* bad.
> Therefore, they call out to a huge C++ library to do floating-point calculations,
> XML parsing, database lookups
> or anything that needs dynamic memory allocation.
> They use explicit integer type declarations throughout, and use peculiar idioms known to
> compile to optimal machine code for inner loops.
It's a nice feature of lisp that you can make it very fast when you need to, without changing
languages. (+ x y) can compile into a single machine ADD instruction, if you tell the compiler
that you expect the arguments and result to fit in a machine word. And if you don't tell it that,
your integers can be as big as you like, not limited by hardware.
> Bugs often arise from integer overflows because they don't have a 64-bit integer type.
The compiler will check that the actual type matches the declared type if you're running in lower
optimization modes (which are still fast enough for development and testing)., so it will notice
that and throw an error. So, you can of course write buggy code, but unlike C, integer overflow is
not completely silent.
PS: yes, I work at ITA on this product. It's possible all of the things you say may have been true
when inferior lisp implementations had been used in the past. Maybe one of those was in use
when you worked there.
to post comments)