9 ms·

> 1) performance costs Keep in mind that a compiler like SBCL will put Lisp performancewise in the range of other statically compiled language/implementations.

• FrozenVoid 9y ago
  >Keep in mind that a compiler like SBCL will put Lisp performancewise in the range Simple short benchmarks don't show a complete picture of the language, since they're easy to optimize >written in Macintosh Common Lisp needed 20 MB RAM At the time when computers had 32/64 MB of RAM. >. You can use many Lisp implementations just like scripting languages. >If a compiler is used (say: SBCL, ECL, LispWorks, GCL, CCL, Allegro CL, mocl, ...) , then Lisp does not require runtime interpretation. >Only if you include an interpreter. So which one is it? >Treeshakers remove unused code and data. Parts of the runtime are still there. Huh, What kind of unused code and data is there in a 25MB hello world? https://web.archive.org/web/20090324024745/http://mbishop.esoteriq.org/hellosize.html https://web.archive.org/web/20090324024745/http://mbishop.es... >If all fails, you can always compile Common Lisp to C code Compiling to C doesn't improve safety of Lisp. As a C programmer, "Compiling to verbose cryptic C" doesn't sell me as a feature, more like a potential security threat.
  • ealhad 9y ago
    > Huh, What kind of unused code and data is there in a 25MB hello world? If you want to produce a standalone Lisp executable, you have to embed the compiler with it, hence the big size. However, if you just run the programs with your own compiler, you only need the actual code — that is a 44 bytes "Hello world!", shebang included. On my machine, the SBCL package is 70 MiB, while for example the Python one is 125 MiB.
    • FrozenVoid 9y ago
      >However, if you just run the programs with your own compiler, By that logic GCC is also an interpreter. https://github.com/abijith-kp/gcc-interpreter https://github.com/abijith-kp/gcc-interpreter
      • ealhad 9y ago
        What do you think of Python, then?
      • armitron 9y ago
• mpweiher 9y ago
  > Keep in mind that a compiler like SBCL will put Lisp performancewise in the range of other statically compiled language/implementations. Hmm...that claim is made a lot, and it works, in theory (see Jitterdämmerung[1]). However practical reports from non-advocates don't seem to bear out those results. For example, Michael Stonebraker says that they started writing Postgres in LISP. Had to revert that decision as everything was an order of magnitude slower[2]. [1] http://blog.metaobject.com/2015/10/jitterdammerung.html http://blog.metaobject.com/2015/10/jitterdammerung.html [2] Michael Stonbraker's Turing Award Lecture: https://youtu.be/sEPTZVGk3WY?t=1791 https://youtu.be/sEPTZVGk3WY?t=1791
  • lispm 9y ago
    > started writing Postgres in LISP. Had to revert that decision as everything was an order of magnitude slower If they have never written a high-performance application in Lisp, they would have needed a bit more work. The Lisp version was written more as an experiment: http://db.cs.berkeley.edu/papers/ERL-M90-34.pdf http://db.cs.berkeley.edu/papers/ERL-M90-34.pdf > Our feeling is that the use of LISP has been a terrible mistake for several reasons. First, current LISP environments are very large. To run a ‘‘nothing’’ program in LISP requires about 3 mbytes of address space. Hence, POSTGRES exceeds 4 mbytes in size, all but 1 mbyte is the LISP compiler, editor and assorted other non required (or even desired) functions. Hence, we suffer from a gigantic footprint. Second, a DBMS never wants to stop when garbage collection happens. Any response time sensitive pro- gram must therefore allocate and deallocate space manually, so that garbage collection never happens dur- ing normal processing. Consequently, we spent extra effort ensuring that LISP garbage collection is not used by POSTGRES. Hence, this aspect of LISP, which improves programmer productivity, was not avail- able to us. Third, LISP execution is slow. As noted in the performance figures in the next section our LISP code is more than twice as slow as the comparable C code. Of course, it is possible that we are not skilled LISP programmers or do not know how to optimize the language; hence our experience should be suitably discounted. They had problems because Lisp alone needed 3 Megabytes of address space (!) to run - a 'gigantic footprint' - , needed to work around the GC and their C version was twice as fast. Their main problem was that they wanted to write it in a mix of C with Lisp and it was hard to debug for them. I'm not surprised that people with no experience writing applications in a mix of C + Lisp failed to write a database engine. I'm pretty sure it is easier to write a database engine in C compared to a mix of C and Lisp, without GC and crossing the boundaries of a managed runtime and plain C data. People did that, but these people had quite a bit more experience writing such applications. You can buy for example AllegroGraph, a graph database in Allegro Common Lisp: https://allegrograph.com https://allegrograph.com You can bet that the NSA/CIA/Homeland Security etc. all have it running with very large datasets about you, me and all the others.