3 ms·
> Now, before you go out and write your next project in Lisp, you should keep something in mind. Lisp is not the fastest or smallest language out there, it was
by reikonomusha 4y ago
> Now, before you go out and write your next project in Lisp, you should keep something in mind. Lisp is not the fastest or smallest language out there, it was not designed to be so. There are some pretty good implementations of Lisp out in the wild, but don’t expect them to outperform C, Go, Lua, or even Python most of the time.
SBCL, Chez, and other Lisps produce extremely good native code, competitive with C (sometimes even better due to the ease of run-time compilation) when you're aiming for performance, without sacrificing run-time safety in less critical parts of the code.
Binaries are a couple MB compressed.
> If you’re going to program something in Lisp you should keep these things in mind:
> - How important is execution speed?
> - How important is program/runtime size?
> - How important is portability?
> If you value any three of these too much, then you might not want to write your program in Lisp.
As a standardized language with a plethora of implementations with different pros and cons, Common Lisp is remarkably portable. Decades-old code still compiles on modern platforms and OS's.
- pjmlp 4y agoAnd many "modern" languages are still lacking in tooling versus what Allegro and LispWorks offer.
- paines 4y agoDecade old code might compile but might not run on modern hardware. E.g. I have some code base, s7 scheme + c++, which is 100% posix and it compiles on M1 macs but does not run. And no this is not due to the change from x86 to arm, as the code runs fine on x86 linux as well on e.g. raspberry pi's. macOS seems to prevent drawing outside of the main thread. IIRC this used to work in the past on OSX. I know, you shouldn't do this, but as it works fine on other platforms/systems...
- p_l 4y agomacOS always required drawing to come from thread 1, but it's possible that for some time it would not explode by accident