SBCL 25th anniversary workshop is in Vienna thu-fri next week. See you there!
An Exploration of SBCL Internals (2020)
31–40 of 194 posts
Re: An Exploration of SBCL Internals (2020)
#32Earlier quoted context omitted.
Let’s make a trip back to the early and mid 1990s when C++ was a young language and Java was under development (it was released in 1995). At the time the most popular object-oriented language was Smalltalk, Common Lisp was at its peak of commercial popularity (largely in symbolic AI niches), and there were other niche OO languages that were heavily influenced by Smalltalk and Common Lisp (Objective-C in the NeXT worl…
The economics of this is interesting to hear. GNU Common Lisp ( https://www.gnu.org/software/gcl/ ) seems to have existed in various forms from the mid 1980s, but it was probably outclassed by the contemporary big tech companies.
Gnu CL also had problems as a Common Lisp implementation. It works (like ECL, which is related) by compiling to C, which is then compiled with a C compiler and the object code loaded into the image. This approach generates inferior code to that which an implementation like SBCL can achieve.
All the Lisp implementations needed more memory than C programs would, which limited their impact before 32 bit machines became standard. And by that time, C was strongly in place.
Re: An Exploration of SBCL Internals (2020)
#33Earlier quoted context omitted.
Let’s make a trip back to the early and mid 1990s when C++ was a young language and Java was under development (it was released in 1995). At the time the most popular object-oriented language was Smalltalk, Common Lisp was at its peak of commercial popularity (largely in symbolic AI niches), and there were other niche OO languages that were heavily influenced by Smalltalk and Common Lisp (Objective-C in the NeXT worl…
>I think had there been solid cheap or free Smalltalk and Common Lisp implementations around 1992, Java wouldn’t have gained a foothold, though C++ would have still been very appealing to C developers, though perhaps if Objective-C were more broadly available to non-NeXT developers, it would’ve been a formidable competitor to C++ in terms of providing a “C with objects” environment. 100% agree. i think it is also int…
There's basically one commercial Common Lisp left (Allegro from Franz), and they're focusing more on things built on top of the Lisp (like AllegroGraph), not the Lisp itself. So the free CLs have sort of won by default, and perhaps also by sucking the oxygen out of the room for expensive proprietary CLs.
Re: An Exploration of SBCL Internals (2020)
#34Earlier quoted context omitted.
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.
There is Lem too. https://lem-project.github.io/
I really want to like lem, so I followed all the steps at both https://lem-project.github.io/installation/sdl2/macos/ and https://lem-project.github.io/installation/ncurses/macos/.
Neither ends in a working development environment or even text editor.
Compare this to learning Python or Javascript or the C family. VSCode or even just your standard OS text editor is all you need. You can decide to start learning, find a tutorial on Youtube, and execute your hello world in 60-120 seconds.
Re: An Exploration of SBCL Internals (2020)
#35A 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.
This is a bit Haskell oriented, but the "Implementation of Functional Programming Languages" by SPJ is one of my all time favorite books.
https://simon.peytonjones.org/slpj-book-1987/
These compilers were pulling heroic data structure optimization stunts in 1985, that no modern production compiler for major compiled languages can replicate in 2024.
Re: An Exploration of SBCL Internals (2020)
#36A 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.
[deleted]
Re: An Exploration of SBCL Internals (2020)
#37remember that we're on x86 here, which is a big-endian architecture While I wish this were true, x86 is little-endian.
[deleted]
Re: An Exploration of SBCL Internals (2020)
#38It'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?
[deleted]
Re: An Exploration of SBCL Internals (2020)
#39Earlier quoted context omitted.
Well take over is relative. I built my startup using SBCL and it is very profitable. Couldn't have done it without SBCL.
>Couldn't have done it without SBCL Could you elaborate this part?
I still haven't found an environment which lets you build the system as seamlessly as SBCL. The REPL allows you to build the code at runtime and update the system in place. Since I was a solodev, bug fixing and building the thing without going on the wrong path was worth I think months and years of my time.
edit: Once you get the idea of a running Lisp image and you are updating the image it's a game changer. You are not writing a program, then compiling it and then running it anymore (even though those steps happen seamlessly).
Re: An Exploration of SBCL Internals (2020)
#40A 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.
This is a bit Haskell oriented, but the "Implementation of Functional Programming Languages" by SPJ is one of my all time favorite books. https://simon.peytonjones.org/slpj-book-1987/ These compilers were pulling heroic data structure optimization stunts in 1985, that no modern production compiler for major compiled languages can replicate in 2024.
Why? Is it mostly because of Haskell's purity (side-effect-freeness), so optimizations can change expressions more freely and safely?