Live data from Hacker News

An Exploration of SBCL Internals (2020)

simonsafar.com

191–194 of 194 posts

Re: An Exploration of SBCL Internals (2020)

#191
post #163

Earlier quoted context omitted.

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.

> 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. IDLE is a underrated feature of Python. The default install includes a barebones IDE together with the REPL, making setup for beginners nearly zero effort. On the other hand, in lisp land, step 0 to learn most lisps is to learn emacs beforehand.

[deleted]

Re: An Exploration of SBCL Internals (2020)

#192
post #175

Earlier quoted context omitted.

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.

Which is funny because it was marketed as close, while in reality being quite different from C++: all methods virtual, interfaces, type erasure, no method overloading, no operator overloading, no templates, to name just first things coming to mind. We've been fooled in 90s so easily!

For entry-level programmers making the transition to Java, those deep semantics like "all methods virtual" didn't matter, nor did the lack of features like operator and method overloading or templates. They didn't really need those to build stuff.

The killer "like C++" feature that made adoption easy was the "C/C++ like syntax, with braces and everything".

Re: An Exploration of SBCL Internals (2020)

#193
post #5

Earlier quoted context omitted.

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). i think scalability problem is a bit overstated. the biggest issue with lisp becoming popular is that it doesn't have a large user base and is not a new language like rust. however despite being old, common lisp /sti…

The big team thing matters for two reasons:

First, it implies lots of people are paid to learn it. Second, it implies companies will have to invest in adding/fixing support libraries.

Re: An Exploration of SBCL Internals (2020)

#194
post #185

Earlier quoted context omitted.

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…

It's not that bad: (require 'uiop) (defun c () (uiop:run-program '("emacs" "-nw" "file.lisp") :output :interactive :input :interactive)) EDIT: note that SBCL comes with UIOP included by default, but if you want to use SBCL's implementation-specific facility, it's only slightly different: (defun c () (sb-ext:run-program "/usr/bin/emacs" '("-nw" "file.lisp") :input t :output t))

If you don't want a full emacs, jmacs from 'joe' an do the trick.
Post reply on HN