8 ms·

This is the document [0] we maintain for new Lisp hackers at Rigetti, where we use Common Lisp to build open source quantum software development tools. Followin

This is the document [0] we maintain for new Lisp hackers at Rigetti, where we use Common Lisp to build open source quantum software development tools. Following that, here’s the rundown of some basic Lisp nomenclature and how to edit in Emacs [1]. The article isn’t bad, but it also doesn’t provide you with a sustainable way to develop Lisp; interactive and incremental development together form a great proportion of value of using the language in the first place. [0] https://github.com/rigetti/qvm/blob/master/doc/lisp-setup.md https://github.com/rigetti/qvm/blob/master/doc/lisp-setup.md [1] https://github.com/rigetti/qvm/blob/master/doc/editing-and-running.md https://github.com/rigetti/qvm/blob/master/doc/editing-and-r... (PRs are welcome!)

adamnemecek 7y ago
What are the advantages of lisp over julia?
- reikonomusha 7y ago
  - Array indices start at 0. :) [Half-joking.] - An excellent debugger and condition system! - Code won’t be broken in 20 years (which I value when developing things like compilers). There’s one standard, and several de facto standard extensions. - Almost 30 years of history, documentation, discussions, etc. Every corner of the language has been discussed to death. - Several stable, mature, and independent choices of open source implementation. - Implementations are written in Lisp all the way down. You can immediately jump to the definition of anything at any depth, and often edit or redefine to taste. (Example, I improved SBCL’s integer square root in my live image, and submitted a patch.) The only off-limits bits are a part of the runtime, like the garbage collector. - Several independent choices of commercial implementation and commercial support. - Generally easy to optimize and micro-optimize code. Easy to edit/disassemble/debug. - Easy to write assembly code with SBCL. - Fast start-up time, easy to compile into native executables. No JIT lags. - Excellent IDE support through Emacs and SLIME. Incremental development is real with Lisp, and absolutely not so with Julia. - Easy to dynamically generate and compile code at runtime. - Excellent metasyntactic programming facilities. (Macros, symbol macros, reader macros, ...) Negatives compared to Julia: - Poor support for numerical libraries and poor support for plotting, much to the chagrin of a scientific programmer like myself. - No hip website or hip foundation backing it. - Quiet community, with very broad interests. Not everybody is rallying around one theme in Lisp. You got database programmers, game programmers, scientific programmers, etc. This could be a positive, if the community were larger.
  - dtornabene 7y ago
    - Implementations are written in Lisp all the way down. You can immediately jump to the definition of anything at any depth, and often edit or redefine to taste. (Example, I improved SBCL’s integer square root in my live image, and submitted a patch.) The only off-limits bits are a part of the runtime, like the garbage collector. I'd add even the GC is accessible if you have the knowledge. Grammarly has a blog post that talks in part about manipulating parts of the GC to achieve higher through put by keeping heap objects (I think!) from reclamation.
    - reikonomusha 7y ago
      Yes, lots of tunable aspects of the GC are available at runtime. You can enable/disable GC, pin memory, control how much of the heap is dedicated to which generations, control GC rate, etc. You just can’t muddle with the actual GC algorithm readily from your image. (Not that you’d ever want to??)
    - snaky 7y ago
      There's talk about using off-the-heap data structures in one of the most successfull software piece written in Lisp, AllegroGraph. "Escape from the Heap: Low-Level Programming in Common Lisp" https://www.youtube.com/watch?v=S7nEZ3TuFpA https://www.youtube.com/watch?v=S7nEZ3TuFpA
      - dtornabene 7y ago
        This is an excellent talk.
  - valarauko 7y ago
    What's a good lisp to get started with? I'm a bioinformatician who's semi-competent with python & R.
    - wglb 7y ago
      I recommend SBCL with emacs. http://www.sbcl.org/platform-table.html http://www.sbcl.org/platform-table.html
- dreamcompiler 7y ago
  One big one is that Lisp is probably much faster. Common Lisp is AOT compiled to the metal so it starts up fast and runs fast. CL is often within a factor of 2 of C speed and dramatically faster than plain Python. I haven't used Julia but recent stories on HN suggest it's no speed demon.
  - ddragon 7y ago
    Julia should be faster than CL for long running numerical computation at least (reaching C/Fortran speed for type-stable code) as it was designed for that purpose (plus the good GPU support and use of libraries like BLAS). But there is no AoT option yet so you'll have to deal with JIT, making it much slower for any shorter running scripts because of all the compilation, which makes CL speed much more consistent across tasks.
    - reikonomusha 7y ago
      “It was designed for that” doesn’t justify a claim. Common Lisp is a general purpose language with excellent support for fast numerical code. In SBCL in particular you can even write assembly if you want to do crazy AVX stuff.
      - dreamcompiler 7y ago
        Likewise in CCL.
      - ddragon 7y ago
        While it doesn't justify by itself, it means that this area will be constantly profiled and optimized tricks will be implemented to handle it better, like auto-simd, using multiple dispatch to detect optimal BLAS method for every matrix operation, implementing broadcast/loop fusion. Even matlab which will poorly handle almost anything is pretty competitive in numerical processing. And saying CL is fast because you can write in assembly is like saying Python is fast because you can write in C. And while you can't write in assembly in Julia, you can go down all the way down to the LLVM (and intercept the compiler right between detecting types and compiling so you can rewrite every intrinsic with your new backend in a more flexible way than multiple dispatch) like they did with XLA.jl for TPUs and CUDANative for GPUs.
IronBacon 7y ago
I would love to see a section about debugging, something like the series at https://malisper.me/category/debugging-common-lisp/ https://malisper.me/category/debugging-common-lisp/ but I suspect it would be difficult to made it general enough (the guide above targets SBCL, Emacs and Slime)... P.S. I should mention that I live in Emacs, but I know there are people that wouldn't touch it with a ten foot pole

adamnemecek 7y ago

What are the advantages of lisp over julia?

reikonomusha 7y ago
- Array indices start at 0. :) [Half-joking.] - An excellent debugger and condition system! - Code won’t be broken in 20 years (which I value when developing things like compilers). There’s one standard, and several de facto standard extensions. - Almost 30 years of history, documentation, discussions, etc. Every corner of the language has been discussed to death. - Several stable, mature, and independent choices of open source implementation. - Implementations are written in Lisp all the way down. You can immediately jump to the definition of anything at any depth, and often edit or redefine to taste. (Example, I improved SBCL’s integer square root in my live image, and submitted a patch.) The only off-limits bits are a part of the runtime, like the garbage collector. - Several independent choices of commercial implementation and commercial support. - Generally easy to optimize and micro-optimize code. Easy to edit/disassemble/debug. - Easy to write assembly code with SBCL. - Fast start-up time, easy to compile into native executables. No JIT lags. - Excellent IDE support through Emacs and SLIME. Incremental development is real with Lisp, and absolutely not so with Julia. - Easy to dynamically generate and compile code at runtime. - Excellent metasyntactic programming facilities. (Macros, symbol macros, reader macros, ...) Negatives compared to Julia: - Poor support for numerical libraries and poor support for plotting, much to the chagrin of a scientific programmer like myself. - No hip website or hip foundation backing it. - Quiet community, with very broad interests. Not everybody is rallying around one theme in Lisp. You got database programmers, game programmers, scientific programmers, etc. This could be a positive, if the community were larger.
- dtornabene 7y ago
  - Implementations are written in Lisp all the way down. You can immediately jump to the definition of anything at any depth, and often edit or redefine to taste. (Example, I improved SBCL’s integer square root in my live image, and submitted a patch.) The only off-limits bits are a part of the runtime, like the garbage collector. I'd add even the GC is accessible if you have the knowledge. Grammarly has a blog post that talks in part about manipulating parts of the GC to achieve higher through put by keeping heap objects (I think!) from reclamation.
  - reikonomusha 7y ago
    Yes, lots of tunable aspects of the GC are available at runtime. You can enable/disable GC, pin memory, control how much of the heap is dedicated to which generations, control GC rate, etc. You just can’t muddle with the actual GC algorithm readily from your image. (Not that you’d ever want to??)
  - snaky 7y ago
    There's talk about using off-the-heap data structures in one of the most successfull software piece written in Lisp, AllegroGraph. "Escape from the Heap: Low-Level Programming in Common Lisp" https://www.youtube.com/watch?v=S7nEZ3TuFpA https://www.youtube.com/watch?v=S7nEZ3TuFpA
    - dtornabene 7y ago
      This is an excellent talk.
- valarauko 7y ago
  What's a good lisp to get started with? I'm a bioinformatician who's semi-competent with python & R.
  - wglb 7y ago
    I recommend SBCL with emacs. http://www.sbcl.org/platform-table.html http://www.sbcl.org/platform-table.html
dreamcompiler 7y ago
One big one is that Lisp is probably much faster. Common Lisp is AOT compiled to the metal so it starts up fast and runs fast. CL is often within a factor of 2 of C speed and dramatically faster than plain Python. I haven't used Julia but recent stories on HN suggest it's no speed demon.
- ddragon 7y ago
  Julia should be faster than CL for long running numerical computation at least (reaching C/Fortran speed for type-stable code) as it was designed for that purpose (plus the good GPU support and use of libraries like BLAS). But there is no AoT option yet so you'll have to deal with JIT, making it much slower for any shorter running scripts because of all the compilation, which makes CL speed much more consistent across tasks.
  - reikonomusha 7y ago
    “It was designed for that” doesn’t justify a claim. Common Lisp is a general purpose language with excellent support for fast numerical code. In SBCL in particular you can even write assembly if you want to do crazy AVX stuff.
    - dreamcompiler 7y ago
      Likewise in CCL.
    - ddragon 7y ago
      While it doesn't justify by itself, it means that this area will be constantly profiled and optimized tricks will be implemented to handle it better, like auto-simd, using multiple dispatch to detect optimal BLAS method for every matrix operation, implementing broadcast/loop fusion. Even matlab which will poorly handle almost anything is pretty competitive in numerical processing. And saying CL is fast because you can write in assembly is like saying Python is fast because you can write in C. And while you can't write in assembly in Julia, you can go down all the way down to the LLVM (and intercept the compiler right between detecting types and compiling so you can rewrite every intrinsic with your new backend in a more flexible way than multiple dispatch) like they did with XLA.jl for TPUs and CUDANative for GPUs.

IronBacon 7y ago

I would love to see a section about debugging, something like the series at https://malisper.me/category/debugging-common-lisp/ https://malisper.me/category/debugging-common-lisp/ but I suspect it would be difficult to made it general enough (the guide above targets SBCL, Emacs and Slime)... P.S. I should mention that I live in Emacs, but I know there are people that wouldn't touch it with a ten foot pole