An Exploration of SBCL Internals (2020)
simonsafar.com
An Exploration of SBCL Internals (2020)
1–10 of 194 posts
Re: An Exploration of SBCL Internals (2020)
#2It's a bit sad that this ecosystem has fallen out of favor for mainstream software development.
One could have designed OOP like frontends to this fairly easily, and I'm sure there are existing ones. How did Java and C++ take over?
Re: An Exploration of SBCL Internals (2020)
#3A lot of people write Lisp interpreters, post it to HN and call it a day, but I think compilation is the far more interesting task for a Lisp implementation.
SBCL is great to poke around in and the decompiler’s great. Also check out ABCL, ECL for what compilation to JVM bytecode and C looks like.
Re: An Exploration of SBCL Internals (2020)
#4It's a bit sad that this ecosystem has fallen out of favor for mainstream software development. One could have designed OOP like frontends to this fairly easily, and I'm sure there are existing ones. How did Java and C++ take over?
I’ve tried multiple times to get into SBCL, but every time I run into the problem that I have to learn Emacs first.
I know there are lots of other ways to work with SBCL, but they are either second-class citizens or paid.
Re: An Exploration of SBCL Internals (2020)
#5It's a bit sad that this ecosystem has fallen out of favor for mainstream software development. One could have designed OOP like frontends to this fairly easily, and I'm sure there are existing ones. How did Java and C++ take over?
Java took over by targeting large teams of inexperienced developers.
C++ took over by adding OO to C with zero cost abstractions, and then evolving into modern C++ (which discourages OO and encourages composition via template instantiation) without leaving programs behind.
Lisp has supported composition forever (it is one of the big advantages of functional programming), and the macro language is similar to templates. I think the big problem is that it is difficult to scale lisp projects with inexperienced developers (loses to java) and is not zero cost (has a GC, is often interpreted; loses to c, c++ and now rust).
Re: An Exploration of SBCL Internals (2020)
#6A lot of people write Lisp interpreters, post it to HN and call it a day, but I think compilation is the far more interesting task for a Lisp implementation. SBCL is great to poke around in and the decompiler’s great. Also check out ABCL, ECL for what compilation to JVM bytecode and C looks like.
The scheme compiler in Paradigms of Artificial Intelligence Programming by Peter Norvig is a great introduction to compiling Lisp. I was particularly impressed by it only taking a change in one line to go from regular recursion to handling tail call optimization.
Re: An Exploration of SBCL Internals (2020)
#7It's a bit sad that this ecosystem has fallen out of favor for mainstream software development. One could have designed OOP like frontends to this fairly easily, and I'm sure there are existing ones. How did Java and C++ take over?
I’ve tried multiple times to get into SBCL, but every time I run into the problem that I have to learn Emacs first. I know there are lots of other ways to work with SBCL, but they are either second-class citizens or paid.
Vim plus sbcl has been ok. Follow this I am happy since
https://susam.net/lisp-in-vim.html
Not 2nd class and I can use it mostly on mac; linux and windows (linux side)are ok. All good.
Re: An Exploration of SBCL Internals (2020)
#8It's a bit sad that this ecosystem has fallen out of favor for mainstream software development. One could have designed OOP like frontends to this fairly easily, and I'm sure there are existing ones. How did Java and C++ take over?
Java took over by targeting large teams of inexperienced developers. C++ took over by adding OO to C with zero cost abstractions, and then evolving into modern C++ (which discourages OO and encourages composition via template instantiation) without leaving programs behind. Lisp has supported composition forever (it is one of the big advantages of functional programming), and the macro language is similar to templates…
> is often interpreted
Every competitive Common Lisp implementation has compilation. SBCL defaults to not even using an interpreter for eval.
Re: An Exploration of SBCL Internals (2020)
#9It's a bit sad that this ecosystem has fallen out of favor for mainstream software development. One could have designed OOP like frontends to this fairly easily, and I'm sure there are existing ones. How did Java and C++ take over?
I’ve tried multiple times to get into SBCL, but every time I run into the problem that I have to learn Emacs first. I know there are lots of other ways to work with SBCL, but they are either second-class citizens or paid.
Why would you have to learn emacs? You can largely batch compile and run lisp code same as any other language, if that is what you want to do. In many ways, the workflow can be very similar to python, if you don't want to get too advanced in the repl. And, to stress, you don't have to get too advanced to get going.
Re: An Exploration of SBCL Internals (2020)
#10 remember that we're on x86 here, which is a big-endian architecture