4 ms·

> Getting Lisp to run as fast as C takes major effort when at all possible. The Computer Language Benchmarks Game shows Lisp Code as generally being between 2x

> Getting Lisp to run as fast as C takes major effort when at all possible. The Computer Language Benchmarks Game shows Lisp Code as generally being between 2x and 10x slower than C++[1]. As fast as C? No. Way faster than Python, and more than fast enough to be used in almost every single application, modulo hard-real-time systems and AAA video games? Yes. > Lisp needs a lot of space to do it's thing; and while it's certainly possible to downsize it, you're left with something that's not really Lisp anymore. Again, while a 13MB SBCL image might be significantly larger than a 100KB C program, given that that's the entire compiler and runtime bundled in, and the size of additional code scales also like C/C++, that still makes it viable for almost every kind of program (and still an order of magnitude smaller than Electron). Same deal with memory usage. > Finding solid libraries is tricky since it's not very popular professionally. This one is so true it's not even funny. (although there are C, C++, and Python FFI's that cover most of the stuff that you want, although that's kind of cheating) > Unleashing the full power of Lisp in a diverse team is a recipe for an adventure, if not disaster. The list of companies using Clojure[2], in addition to the commonly-cited Viaweb/Orbitz/Grammarly, beg to differ. Anecdotally, most Lisps have less footguns than C++ - if people can figure out how to use Stroustrup's monster in massive video games, Lisp is easy. [1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/sbcl-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... [2] https://clojure.org/community/companies https://clojure.org/community/companies

mbil 5y ago
> Finding solid libraries is tricky since it's not very popular professionally. If we're considering Clojure, then I would argue this point isn't true. Java interoperability in Clojure is really well supported and easy to accomplish, so leaning on the massive Java library ecosystem is possible. Also, anecdotally, a lot of Clojure libraries appear to be defunct, but just actually haven't been updated in so long because of the strong backward compatibility across Clojure versions.
- codr7 5y ago
  Well, if we're going to venture that far into excuse land Common Lisp has access to every C library in the world through CFFI. Look, I love Lisp, but reality isn't going anywhere.
  - mbil 5y ago
    I haven't used CL so I can't comment on the differences between CL's C interop and Clojure's Java interop. But when I worked at a Clojure shop, "finding solid libraries" was never an issue, because we used Java libraries directly. And we usually preferred to use a Java library even when third-party Clojure wrapper libraries existed. Using Java from Clojure is natural and idiomatic.
  - spicybright 5y ago
    What's the excuse GP is making exactly?
  - throw10920 5y ago
    This is a variant of the "Turing tarpit" fallacy - that is, saying that all things that are technically possible are equivalent. Calling Java code in Clojure is completely seamless[1] - there's a world of difference from the CL FFI (which isn't that bad to use), which is turn easier to use than the CPython FFI. You might as well say that C is just as powerful as Common Lisp, because you can implement Common Lisp in it. Ergonomics matter. The point of a library is that you're supposed to be able to use its interface without worrying about the code underneath - so, Clojure does have access to the entire Java ecosystem. My comment about lack of libraries was mostly referring to non-Clojures - CL in particular, but my argument also applies to Scheme and Racket and others. [1] http://xahlee.info/clojure/clojure_calling_java.html http://xahlee.info/clojure/clojure_calling_java.html
    - codr7 5y ago
      I certainly don't recall it as being seamless; Clojure is a very different language from Java, and the interop code I've seen doesn't look like the kind of Clojure anyone would write otherwise, hence the comparison to CFFI which has the same impedance issues. But it's all JVM bytecode, so ofcourse it's going to be somewhat smoother.
Zababa 5y ago
I don't think you should use "Lisp" as Common Lisp in one reply, and then "Lisp" as Clojure in the other. They are two very different languages. Though with the Armed Bear Common Lisp backend, you have access to the Java libraries.
dang 5y ago
>> Finding solid libraries is tricky since it's not very popular professionally. > This one is so true it's not even funny I'd say that's a bit out of date as Quicklisp has made a huge difference for CL. Obviously it's still not the most library-rich ecosystem but it's come a very long way.
- spicybright 5y ago
  Do you mind elaborating a bit on this? I've actually never heard of Quicklisp.
  - Jtsummers 5y ago
    https://www.quicklisp.org/ https://www.quicklisp.org/ It's a package manager for Common Lisp. It's supported in pretty much every implementation (probably every, but I won't say that with certainty).
    - spicybright 5y ago
      Ohhh, duh. I've even used that before a few times but forgot lmao
spicybright 5y ago
> ... AAA video games? Yes. One of my favorite stories of the ideas of lisp commercially is a dialect that Naughty Dog developed for their game development. It started as being developed for Crash Banicoot on the PS1. Which is really interesting given how limited the system was (1mb to 2mb of ram depending on what you were doing with the system!) They later iterated on it for Jak and Daxter on the PS2. To quote the wikipedia page: > GOAL does not run in an interpreter, but instead is compiled directly into PlayStation 2 machine code to execute. > ... > GOAL has extensive support for inlined assembly language code using a special rlet form,[1] allowing programs to freely mix assembly and higher-level constructs within one function. > ... > It supports a long term compiling listener session which gives the compiler knowledge about the state of the compiled and thus running program, including the symbol table. This, in addition to dynamic linking, allows a function to be edited, recompiled, uploaded, and inserted into a running game without having to restart. [https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp] I almost don't believe it, honestly. In most modern engines I've used we STILL struggle hard for a perfect live-reload system. I've implemented many types of custom interfaces that let you tweak things on the fly in my games, and it's almost criminal how much better/productive it feels vs. the 'tweak, compile, test' loop we're usually stuck with. All that said, I see the same reason of why companies always transition away from lisp all the time: > In all honesty, the biggest reason we're not using GOAL for next-gen development is because we're now part of Sony. I can only imagine Sony's shock when they purchased Naughty Dog a few years back, hoping to be able to leverage some of our technology across other Sony studios, and then realized that there was no way anyone else would be able to use any of our codebase. It really makes me wish some big company would make a python clone in lisp, but put a tiny escape hatch in to fully utilize the lispy parts.
- adgjlsfhk1 5y ago
  that's basically Julia. take lisp, remove the s expressions and add a bunch of really good math libraries and you've just reinvented Julia.
  - medo-bear 5y ago
    there was dylan before julia, so julia might just be reinventing dylan :) but that's not what's interesting the julia project is in fact very interesting to me and has a great team developing its ecosystem and i work with it alongside python for numerical work. however one key drawback (compared to common lisp) for me is that it is not self-compiled. it is hosted on llvm and over 30% of its repository is in another language (mainly C and C++)[0]. but i am saying this only in comparison to common lisp. other languages are not different to this, and are much worse. as far as scientific computing is concerned, i would work with julia over python any day [0] https://github.com/JuliaLang/julia https://github.com/JuliaLang/julia

mbil 5y ago

> Finding solid libraries is tricky since it's not very popular professionally. If we're considering Clojure, then I would argue this point isn't true. Java interoperability in Clojure is really well supported and easy to accomplish, so leaning on the massive Java library ecosystem is possible. Also, anecdotally, a lot of Clojure libraries appear to be defunct, but just actually haven't been updated in so long because of the strong backward compatibility across Clojure versions.

codr7 5y ago
Well, if we're going to venture that far into excuse land Common Lisp has access to every C library in the world through CFFI. Look, I love Lisp, but reality isn't going anywhere.
- mbil 5y ago
  I haven't used CL so I can't comment on the differences between CL's C interop and Clojure's Java interop. But when I worked at a Clojure shop, "finding solid libraries" was never an issue, because we used Java libraries directly. And we usually preferred to use a Java library even when third-party Clojure wrapper libraries existed. Using Java from Clojure is natural and idiomatic.
- spicybright 5y ago
  What's the excuse GP is making exactly?
- throw10920 5y ago
  This is a variant of the "Turing tarpit" fallacy - that is, saying that all things that are technically possible are equivalent. Calling Java code in Clojure is completely seamless[1] - there's a world of difference from the CL FFI (which isn't that bad to use), which is turn easier to use than the CPython FFI. You might as well say that C is just as powerful as Common Lisp, because you can implement Common Lisp in it. Ergonomics matter. The point of a library is that you're supposed to be able to use its interface without worrying about the code underneath - so, Clojure does have access to the entire Java ecosystem. My comment about lack of libraries was mostly referring to non-Clojures - CL in particular, but my argument also applies to Scheme and Racket and others. [1] http://xahlee.info/clojure/clojure_calling_java.html http://xahlee.info/clojure/clojure_calling_java.html
  - codr7 5y ago
    I certainly don't recall it as being seamless; Clojure is a very different language from Java, and the interop code I've seen doesn't look like the kind of Clojure anyone would write otherwise, hence the comparison to CFFI which has the same impedance issues. But it's all JVM bytecode, so ofcourse it's going to be somewhat smoother.

Zababa 5y ago

I don't think you should use "Lisp" as Common Lisp in one reply, and then "Lisp" as Clojure in the other. They are two very different languages. Though with the Armed Bear Common Lisp backend, you have access to the Java libraries.

dang 5y ago

>> Finding solid libraries is tricky since it's not very popular professionally. > This one is so true it's not even funny I'd say that's a bit out of date as Quicklisp has made a huge difference for CL. Obviously it's still not the most library-rich ecosystem but it's come a very long way.

spicybright 5y ago
Do you mind elaborating a bit on this? I've actually never heard of Quicklisp.
- Jtsummers 5y ago
  https://www.quicklisp.org/ https://www.quicklisp.org/ It's a package manager for Common Lisp. It's supported in pretty much every implementation (probably every, but I won't say that with certainty).
  - spicybright 5y ago
    Ohhh, duh. I've even used that before a few times but forgot lmao

spicybright 5y ago

> ... AAA video games? Yes. One of my favorite stories of the ideas of lisp commercially is a dialect that Naughty Dog developed for their game development. It started as being developed for Crash Banicoot on the PS1. Which is really interesting given how limited the system was (1mb to 2mb of ram depending on what you were doing with the system!) They later iterated on it for Jak and Daxter on the PS2. To quote the wikipedia page: > GOAL does not run in an interpreter, but instead is compiled directly into PlayStation 2 machine code to execute. > ... > GOAL has extensive support for inlined assembly language code using a special rlet form,[1] allowing programs to freely mix assembly and higher-level constructs within one function. > ... > It supports a long term compiling listener session which gives the compiler knowledge about the state of the compiled and thus running program, including the symbol table. This, in addition to dynamic linking, allows a function to be edited, recompiled, uploaded, and inserted into a running game without having to restart. [https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp] I almost don't believe it, honestly. In most modern engines I've used we STILL struggle hard for a perfect live-reload system. I've implemented many types of custom interfaces that let you tweak things on the fly in my games, and it's almost criminal how much better/productive it feels vs. the 'tweak, compile, test' loop we're usually stuck with. All that said, I see the same reason of why companies always transition away from lisp all the time: > In all honesty, the biggest reason we're not using GOAL for next-gen development is because we're now part of Sony. I can only imagine Sony's shock when they purchased Naughty Dog a few years back, hoping to be able to leverage some of our technology across other Sony studios, and then realized that there was no way anyone else would be able to use any of our codebase. It really makes me wish some big company would make a python clone in lisp, but put a tiny escape hatch in to fully utilize the lispy parts.

adgjlsfhk1 5y ago
that's basically Julia. take lisp, remove the s expressions and add a bunch of really good math libraries and you've just reinvented Julia.
- medo-bear 5y ago
  there was dylan before julia, so julia might just be reinventing dylan :) but that's not what's interesting the julia project is in fact very interesting to me and has a great team developing its ecosystem and i work with it alongside python for numerical work. however one key drawback (compared to common lisp) for me is that it is not self-compiled. it is hosted on llvm and over 30% of its repository is in another language (mainly C and C++)[0]. but i am saying this only in comparison to common lisp. other languages are not different to this, and are much worse. as far as scientific computing is concerned, i would work with julia over python any day [0] https://github.com/JuliaLang/julia https://github.com/JuliaLang/julia