[flagged]
An Exploration of SBCL Internals (2020)
61–70 of 194 posts
Re: An Exploration of SBCL Internals (2020)
#62[flagged]
Re: An Exploration of SBCL Internals (2020)
#63Earlier quoted context omitted.
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…
Paul Graham used VI and clisp when he built viaweb.
It's because of his continual praise of lisp that I wanted to check it out.
What I'm complaining about is that it's much harder to "check it out" than it perhaps could be.
At one point many years ago, I wanted to check out this new Python thing. It was so easy, I've been hooked ever since.
Re: An Exploration of SBCL Internals (2020)
#64Earlier quoted context omitted.
>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…
So a jupyter notebook is just a bad lisp repl
Re: An Exploration of SBCL Internals (2020)
#65Earlier quoted context omitted.
I understood it came about due to RMS wanting the source for the printer driver for the Xerox 9700 - nothing to do with Symbolics.
The printer driver situation was RMS’s last straw, but he was already saddened by the demise of the sharing culture of the MIT AI lab once Symbolics and Lisp Machines, Inc. were founded, and he spent a considerable amount of effort reimplementing features from Symbolics: https://www.gnu.org/gnu/rms-lisp.en.html
There's a lot more to the history.
My favourite quote from some other participants was "he didn't see us at lunch not because AI Lab culture died, but because we avoided him"
Re: An Exploration of SBCL Internals (2020)
#66[flagged]
Re: An Exploration of SBCL Internals (2020)
#67[flagged]
Re: An Exploration of SBCL Internals (2020)
#68Earlier quoted context omitted.
>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…
Same here. It is just really annoying to me (ymmv etc etc) to use another env: it just is so much harder to inspect everything, debug easy and still end up with a really fast system because of sbcl.
Re: An Exploration of SBCL Internals (2020)
#69Earlier quoted context omitted.
> is often interpreted Every competitive Common Lisp implementation has compilation. SBCL defaults to not even using an interpreter for eval.
SBCL eval interprets until you hit a lambda form, at which point it will compile (last I checked). But you are much more correct than who you replied to :)
It didn't use to - for various reasons, evaluator inherited from CMU CL had bitrotted at one point, and for many years every form more complex than essentially single function call resulted in compilation.
Few years ago there was work to fix the evaluator and now EVAL has limited evaluation back.
Re: An Exploration of SBCL Internals (2020)
#70[dead]