Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Exploration of SBCL Internals (2020)

simonsafar.com

Post reply on HN
Print view View original

91–100 of 194 posts

Re: An Exploration of SBCL Internals (2020)

#94

Post by coliveira »

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?

The big problem for Lisp is that it was too slow during the 80s and 90s. At that time, C and C++ took the market share and maintained it since then. New languages had to conform to C, since Lisp has its own independent way of doing things.

Re: An Exploration of SBCL Internals (2020)

#95

Post by coliveira »

linguae wrote: post #20
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?

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…

Java claim to fame was to be close enough to C++ but portable in binary form. This made it possible for millions of people to learn it quickly. Lisp is too distant from C++ to have had any change.

Re: An Exploration of SBCL Internals (2020)

#96

Post by whartung »

FredPret wrote: post #4
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?

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.

I normally dabble with CLISP (notably because of its built in readline), and if I could SOMEHOW get it to build with SSL, I'd play with it more.

This is what I stick at the top of my Lisp files when dabbling.

  (defun l ()
    (load "file.lisp"))

  (defun e ()
    (ext:shell "vi file.lisp"))
And then I just muddle my way through with a (e) and (l) cycle. Since I tend to not work on 10,000 line files -- this works fine (my files are That said, I discovered that for some reason, firing off something as simple as "vi file.lisp" from SBCL is stupifyingly complicated. I made several 10s google searches and 5s GPT attempts to make that work, but gave up.

So, can't say I can recommend that style of development in SBCL unless someone is willing to chime in with the, apparently, paragraph of code necessary to launch vi on a file.

Re: An Exploration of SBCL Internals (2020)

#97

Post by vindarel »

koito17 wrote: post #46

I wish other Common Lisp implementations, particularly Clozure CL, documented their internals as well as SBCL does. Apple Silicon support has been a long-standing feature request, but nobody can really work on it besides rme himeself due to the sheer amount of "institutional knowledge" (and time!) it takes to understand CCL's compiler backend then add support for a brand new architecture. SBCL, on the other hand, was…

Fresh news from 2 weeks ago for CCL:

> I recently decided to leave my current full-time job, and I’ll be working on CCL again. […] I’ll be able to work about half-time on an ARM64 port. Please write me privately if you want to talk about supporting that ARM64 work.

> I've worked on CCL for quite a few years, and I did the 32-bit x86 port, so I have experience in this area. I’m not as good a hacker as Gary Byers, but then again, few people are.

rme

https://lists.clozure.com/pipermail/openmcl-devel/2024-April...

Re: An Exploration of SBCL Internals (2020)

#99

Post by agumonkey »

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

Not sure if I'm up to date, but jupyter (as good as it is) suffered from strange rules of evaluations for cells which makes it difficult to do anything large since side effects will impede thinking quick.
Post reply on HN