An Exploration of SBCL Internals (2020) • Hacker News Board

ilrwbwrkhv wrote: post #12

fooker wrote: post #2

It'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?

Well take over is relative. I built my startup using SBCL and it is very profitable. Couldn't have done it without SBCL.

Could you share the name (and what it does)f your startup?

Re: An Exploration of SBCL Internals (2020)

#77

Post by SEXMCNIGGA42427 » Mon, Apr 22, 2024, 8:06 PM UTC

[dead]

Re: An Exploration of SBCL Internals (2020)

#78

Post by anonzzzies » Mon, Apr 22, 2024, 8:07 PM UTC

nurettin wrote: post #64

ilrwbwrkhv wrote: post #39

Earlier quoted context omitted.

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…

So a jupyter notebook is just a bad lisp repl

In my opinion it’s indeed like Greenspun’s 10th rule; it’s a vague imitation. If people weren’t so squeamish about parans the world would be a nicer place. The tech is there for a long time already.

Re: An Exploration of SBCL Internals (2020)

#79

Post by p_l » Mon, Apr 22, 2024, 8:12 PM UTC

pfdietz wrote: post #32

fooker wrote: post #28

Earlier quoted context omitted.

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…

There's arguably also the part where it was, AFAIK, mainly driven by needs of Maxima and it's declaration (or so I recall) of focusing on CLtL first didn't help things either.

In comparison, ECL which forked from the same family seems to work out much better over time.

Re: An Exploration of SBCL Internals (2020)

#80

Post by lispm » Mon, Apr 22, 2024, 8:28 PM UTC

pfdietz wrote: post #44

dasyatidprime wrote: post #41

Earlier quoted context omitted.

Do you not count LispWorks in this? I haven't had a chance to play with the commercial Lisps myself, but anecdotally it seems to still have some currency.

I didn't, but perhaps I should have. There's a question of whether it's live enough to count, or if it's just in maintenance mode. The last release was in 2021, but there have been gaps that long before that.

compare the last release dates

    2012 Allegro CL  9.0
    2015 Allegro CL 10.0
    2017 Allegro CL 10.1
    2024 Allegro CL 11.0

    2012  LispWorks 6.1
     2012  LispWorks 6.1.1
    2015  LispWorks 7.0
    2017  LispWorks 7.1
     2018  LispWorks 7.1.1
     2019  LispWorks 7.1.2
    2021  Lispworks 8.0
     2022  LispWorks 8.0.1

Looks similar to me. LispWorks also had patch releases in between. Both are on the market for more than 35 years. Both are mostly written with CLOS and thus are especially to update with patches, additionally to the usual ways to update code (-> late binding). One just loads patches (which are mostly compiled Lisp code) into a running Lisp and that's it. Alternatively one can save a new image with patches loaded.

When one needs a patch or a feature, one would typically contact them directly. Both provide patches to the users.

Franz has made that simple for the user, they have a relatively continuously stream of patches, one can call an update function and it gets the necessary patches and installs them.

SBCL has monthly (!) releases, where the user (that's what I do) would typically compile it from scratch using the supplied sources. Updating is quick, around a minute for a recompile.