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

Steel Bank Common Lisp version 2.6.7

sbcl.org

Post reply on HN
Print view View original

151–160 of 172 posts

Re: Steel Bank Common Lisp version 2.6.7

#151

Post by Jach »

wduquette wrote: post #142
klibertp wrote: post #58

Earlier quoted context omitted.

On the contrary, CLI, TUI, and desktop GUI apps are basically the only kinds of apps that benefit from CL and can live with its shortcomings. The startup time of a tool written in CL is short: you just need to load the image into RAM, run some hooks (if configured), and you're good to go. If you don't include loads of dependencies, the dumped image is also not too big, so loading it from an SSD is almost instantaneou…

What GUI would one use with SBCL? Is it cross-platform, Linux/Mac/Windows?

You can use most of the popular GUI libs, there's a couple Lisp-specific ones but they're not nearly as featureful. https://lispcookbook.github.io/cl-cookbook/gui.html collects most of them; though for gtk4 I'd recommend https://github.com/crategus/cl-cffi-gtk4/ But no matter what you use I think the experience is going to be a bit rough. CLOG is probably the most interesting non-traditional framework but you do have to accept some web idioms.

I'm confused by the GP's assertion that backends aren't a good fit because of the threading model, to me they're one of the best fits. The 10k problem isn't a concern for most software, and in any case there are ways around it. (I don't know what Google Flights does but even at their scale they haven't moved off SBCL. And Hacker News itself runs fine on SBCL, though there probably aren't 10k concurrent connections.) In the ecosystem, there's the https://github.com/fukamachi/woo webserver which binds to libev to handle similar scale as Go was advertising about 10 years ago. And besides some work going on recently on the SBCL dev mailing list to add native fibers/green-threads, there's been non-native versions of them before, and basically any concurrency model you can think of has been built on top of SBCL by someone. (STM, actors, async (one even built on libuv), channels, promises/futures...)

Re: Steel Bank Common Lisp version 2.6.7

#152

Post by iLemming »

anthk wrote: post #149
iLemming wrote: post #148

Earlier quoted context omitted.

Are you using a 42 year old book to find flaws in my argumentation? Let's talk real, contemporary numbers. NuBank: from ~12M customers in 2019, grown to 25M in a year, then to 48M at IPO a year later, then to 114M in 2024, to 131M in 2025 - 991.67% growth within 6 years and still going. Not in theory, not conceptually, not because "SICP has told them". They did get-the-shit-done. Not acknowledging that Datomic and Cl…

I mean, both Scheme and CL have good libraries and a set of standards.

Okay, but what that has to do with preferring strong CS theoretical grounds vs. cutting corners to get-the-shit-done?

My initial point was about cultures - Haskelites are typically very smart, extremely mathy, and they'd often choose certain ways even if it takes them forever and requires reading and analyzing dozens of academic papers, just because "Galois was a genius and we can make this theory fit here, because then we can center infinite divs on infinitely large DOM entities...", then publishes a paper "Coequalizers for Vertical Alignment: A Comonadic Approach"

A Lisper would be like: "Ahem... I wrapped the whole thing in a macro. Yes, it evals a string. Yes, the string is generated by another macro. No, I will not be explaining it. It shipped Tuesday, it prints money, it works. Gotta go, kids need dinner.."

Re: Steel Bank Common Lisp version 2.6.7

#153

Post by pfdietz »

groundzeros2015 wrote: post #138
pfdietz wrote: post #121

Earlier quoted context omitted.

Yes, there's a specific standard special variable controlling it, *read-eval*.

You can also configure a read table to disable any other data structure features you want. inb4 DoS attack. That is a universal parsing problem and should be solved by configuring OS limits for your process.

I'm of two minds about read tables.

Yes, it's nice we have control over it. This is a lisp thing, where features that are used to implement standard things (like the standard reader) are exposed so the user can play with them also.

But code written with custom read tables has some problems. Different code with different read tables may not be composable. If I have two packages that use incompatible read tables I can't import them into a third package and expect to be able to use their readtables there.

Also, it makes treating code as an object to be inspected, modified, and written out again difficult. This is similar to the problem of code rewriting systems on preprocessed languages like C or C++.

A different branch of Lisp put everything into S expressions. Interlisp, for example, had comments in the code as forms, so the code could be editted as S-expressions. But that was dropped from Common Lisp, which took the surface syntax more from Maclisp.

Re: Steel Bank Common Lisp version 2.6.7

#154

Post by ivxvm »

klibertp wrote: post #58
ivxvm wrote: post #23

Earlier quoted context omitted.

Anywhere is where exactly? I've been thinking of where I could use it for like 10 minutes, and I couldn't come up with anything. Maybe a game engine or web services. It wouldn't make much sense for any kind of desktop software or command line utilities that are supposed to start really fast and have minimal runtime.

On the contrary, CLI, TUI, and desktop GUI apps are basically the only kinds of apps that benefit from CL and can live with its shortcomings. The startup time of a tool written in CL is short: you just need to load the image into RAM, run some hooks (if configured), and you're good to go. If you don't include loads of dependencies, the dumped image is also not too big, so loading it from an SSD is almost instantaneou…

> you just need to load the image into RAM

> The startup is of course nowhere near that of a small C or Zig binary, but for larger tools it will be tolerable.

It's worse than Java and Python and JavaScript I think? The languages that were always disliked for CLI/TUI/GUI apps because of unnecessary bloat they bring due to their runtimes. It's not impossible to use this ofc, it's just inferior to alternatives with minimal runtime, so such an app might be considered a temporary solution to use before someone rewrites it in Rust or Zig or C and people have no reason to use slower and more resource hoggy version. Many people even choose to avoid Emacs for slow startup times, now imagine if something like grep was starting a virtual Lisp Machine underneath. This is why I think it's more promising to consider it for apps and niches that people never tried to keep minimal, such as games and webservices, even if it doesn't have native coroutines or whatever. Using non-standard solution is almost a non-issue and invisible to end user while startup times and RAM usage are very visible.

Also, ofc there's definitely unique things that become available with something that's just as programmable in runtime as it is in development stage. So some kind of very polymorphic app that benefits from growing more native code in response to user actions, could benefit from it. I don't have many ideas of what app really needs this though.

In the past, like two decades ago, I've seen a person using SBCL with some kind of unofficial continuations or green threads for backend webdev in commercial setting. I also remember someone using it in context of virtualization systems, but don't remember their exact usecase.

Also quick search shows there are some modern takes on coroutines as well: https://atgreen.github.io/repl-yell/posts/sbcl-fibers/

Re: Steel Bank Common Lisp version 2.6.7

#155

Post by galaxyLogic »

igouy wrote: post #134
goatlover wrote: post #94

Earlier quoted context omitted.

Images can be saved out as files, so I don't see why not. Also, I recall it was the expensive commercial licensing along with the rise of cheap PCs as competition to Lisp and ST machines. That and Java being free with a focus on networking and the web was the final nail in squashing Lisp or ST popularity.

March 7, 1988 — "Smalltalk/V 286 is available now and costs $199.95, the company said. Registered users of Digitalk's Smalltalk/V can upgrade for $75 until June 1." https://books.google.com/books?id=CD8EAAAAMBAJ&lpg=PA25&dq=d... September 1991 — "Smalltalk/V code is portable between the Windows and the OS/2 versions. And the resulting application carries no runtime charges. All for just $499.95." (Advert on the last…

Good pointers. But Claude Code is even more expensive.

Re: Steel Bank Common Lisp version 2.6.7

#156

Post by anthk »

iLemming wrote: post #152
anthk wrote: post #149

Earlier quoted context omitted.

I mean, both Scheme and CL have good libraries and a set of standards.

Okay, but what that has to do with preferring strong CS theoretical grounds vs. cutting corners to get-the-shit-done? My initial point was about cultures - Haskelites are typically very smart, extremely mathy, and they'd often choose certain ways even if it takes them forever and requires reading and analyzing dozens of academic papers, just because "Galois was a genius and we can make this theory fit here, because t…

You forgot about HAKMEM under PDP10 assembly/ITS/MacLisp/Macsyma (these three/four ovelapped)

Re: Steel Bank Common Lisp version 2.6.7

#157

Post by dismalaf »

agumonkey wrote: post #143
dismalaf wrote: post #90

Earlier quoted context omitted.

McCarthy's pure Lisp existed only on paper. The first Lisp that ran on a computer had mutable variables, as did Lisp 1.5, Maclisp, etc... Immutability requires lots of copying and early computers didn't have much memory to spare...

fair point but from memory most of early programs in his paper were purely immutable in nature (tree recursion and substition), right ?

Yes but he also wrote this when describing the language:

> In addition to the facilities for describing S-functions, there are facilities for using S-functions in programs written as sequences of statements along the lines of FORTRAN (4) or ALGOL (5). These features will not be described in this article

Re: Steel Bank Common Lisp version 2.6.7

#158

Post by groundzeros2015 »

pfdietz wrote: post #153
groundzeros2015 wrote: post #138

Earlier quoted context omitted.

You can also configure a read table to disable any other data structure features you want. inb4 DoS attack. That is a universal parsing problem and should be solved by configuring OS limits for your process.

I'm of two minds about read tables. Yes, it's nice we have control over it. This is a lisp thing, where features that are used to implement standard things (like the standard reader) are exposed so the user can play with them also. But code written with custom read tables has some problems. Different code with different read tables may not be composable. If I have two packages that use incompatible read tables I can'…

Good points. I sometimes see it as “easy and clean json” rather than code as data.

Re: Steel Bank Common Lisp version 2.6.7

#159

Post by igouy »

galaxyLogic wrote: post #155
igouy wrote: post #134

Earlier quoted context omitted.

March 7, 1988 — "Smalltalk/V 286 is available now and costs $199.95, the company said. Registered users of Digitalk's Smalltalk/V can upgrade for $75 until June 1." https://books.google.com/books?id=CD8EAAAAMBAJ&lpg=PA25&dq=d... September 1991 — "Smalltalk/V code is portable between the Windows and the OS/2 versions. And the resulting application carries no runtime charges. All for just $499.95." (Advert on the last…

Good pointers. But Claude Code is even more expensive.

Back in the day those were not unusual costs for programming tools. (Beer wasn't free.)

Re: Steel Bank Common Lisp version 2.6.7

#160

Post by agumonkey »

dismalaf wrote: post #157
agumonkey wrote: post #143

Earlier quoted context omitted.

fair point but from memory most of early programs in his paper were purely immutable in nature (tree recursion and substition), right ?

Yes but he also wrote this when describing the language: > In addition to the facilities for describing S-functions, there are facilities for using S-functions in programs written as sequences of statements along the lines of FORTRAN (4) or ALGOL (5). These features will not be described in this article

hmm funny i completely missed that, i thought these traits were introduced a bit later
Post reply on HN