Live data from Hacker News

Steel Bank Common Lisp version 2.6.7

sbcl.org

81–90 of 172 posts

Re: Steel Bank Common Lisp version 2.6.7

#81

Earlier quoted context omitted.

The problem is that the type of developer you're talking about is the kind who invents a thousand excuses about anything. It doesn't begin and end with different languages. Using a different subset of their favorite language? A different toolchain? A radically different build process? You'll hear plenty of whining about it. Even just moving them to a different codebase will make them miserable. You put a Lisp or a Pr…

Yes, that kind of developer exists everywhere, but is still limited by the tools you reign in him. > I think most people who have led teams will know exactly what I'm talking about. I've had those as leads themselves, with great benefit and pain. They further convinced me about the beauty of ugly and boring.

You clearly and obviously have little or none of practical, genuine experience working with experienced Lispers, and driving your opinions from a book-read definitions rather from actual, battle-tested work.

Your line up of Lisp and Haskell next to one another is already telling - the two cultures can't be more different. Haskell culture historically have selected for people who enjoy theory for its own sake. Lisp culture genuinely prizes getting-shit-done attitude.

> What scales and works is simple and boring.

Java was exotic in 1996 and boring by 2006. If "boring" just means "widely adopted and familiar", then your notion just collapses to "what's popular is popular". True and absolutely pointless and empty.

I reckon, you're piggybacking on Dan McKinley's "Choose Boring Technology", but his point was that the innovation tokens are scarce. That is a good and true argument. But it's about organizational risk budgets, not language virtue. It says nothing about Haskell or Lisp being bad or impractical - it says being different is expensive, and you'd better be buying something with that expense. I personally disagree with that argument (in this case), because I have effectively proven that Lisp's bus factor is much smaller than even of Python or JS/TS, because modern Lisp dialects are far simpler and less convoluted and easier to train into. The experience difference and angle of opinions of two Python/JS experts can be dramatic. Having two Lispers talking "the same" language is far more plausible in practice. Not to mention that ROI from hiring a practicing Lisper (regardless of the business stack) more likely to exceed of a programmer without such knowledge.

Let me remind you that Python was considered a niche scripting toy at some point when it was the same age of [niche] Clojure today. It got boring by riding two waves that had nothing to do with the language design: web (Django/Flask) and then, decisively, being in the right place and time when scientific computing and ML needed a glue language.

Boring things survive by mass, inertia, and being unremarkable - COBOL endures because ripping it out of banks is too expensive, not because anyone loves it. Lisp survives by being remarkable - by smaller population who see the thing the majority can't, regenerating the flame across dialects out of conviction, not inertia.

What scales and works is boring, that is true. Lisp is not that, never will be, and doesn't care. What has enduring value survives regardless of adoption - that is Unix, SQL, lambda calculus itself. I'm sure you won't be arguing that any of these are impractical. Anyone can wholeheartedly accept every new rising and falling, boring COBOL and chase every new hype cycle, or just quietly keep feeding on truly everlasting ideas. Or, like in my case, nothing stands in your way of combining both - I use plenty of boring languages at work, and efficiently utilize Lisp for my personal computing. Because the darn thing just fucking works!

Re: Steel Bank Common Lisp version 2.6.7

#82

Earlier quoted context omitted.

I've often thought that s-expression diff-viewers would be very nice tooling. I've also often wondered how easy it would be to just sling s-expressions across the wire to execute in another environment. What would modern infrastructure look like if you could just have lambdas running lambdas?

in at least Common Lisp world slinging s-expressions is considered to be a hack, at best something you do in a development environment, like swank/slime wire protocol. one of the reasons is that a readtable is both powerful, user extendable, and has all kinds of default ways in which a malicious input would be detrimental. you can remove all kinds of reader macros like #.(xyzzy), but to make a truly bulletproof s-exp…

You can configure (read) to be safe for this purpose.

It’s not a hack.

Re: Steel Bank Common Lisp version 2.6.7

#84

Earlier quoted context omitted.

I've often thought that s-expression diff-viewers would be very nice tooling. I've also often wondered how easy it would be to just sling s-expressions across the wire to execute in another environment. What would modern infrastructure look like if you could just have lambdas running lambdas?

Not sexps, but better. Quite a while back I have read about a system based on Scheme , called termite (I don't remember which scheme that was) that can actually sling live running code/closures across network and execute them remotely.. Boggles my mind even today.

Erlang also has this capability built in. You can do all kinds of weird stuff with it, it’s great.

Re: Steel Bank Common Lisp version 2.6.7

#85

Earlier quoted context omitted.

sbcl can compile to a single executable (the image is embedded in the binary). From a deployment standpoint, the only real issue is if you depend on a dynamically linked C library like OpenSSL.

random note: it's possible to incorporate C libs at compile time, e.g.: https://github.com/sionescu/sbcl-goodies

Yeah, I’ve done that in a slightly hacky way (manually run the various stages of the sbcl build and statically link c libs before building the actual image).

Re: Steel Bank Common Lisp version 2.6.7

#86
post #12

I wonder sometimes how the world would look like if lisp won and the unit of deployment was a lisp machine image, if that makes sense. How would a kubernetes optimized for lisp look like? How would AWS EC2 look like? etc.

The worst thing that ever happened to Common Lisp was its ANSI standardization, which for many years killed almost all language innovation and improvement.

Re: Steel Bank Common Lisp version 2.6.7

#88

If any SBCL dev is here, please add documentation for how to use the memory arena feature. The only doc is an very old proposal document.

Yeah I'm not sure why it's not in the manual, as it's had arena allocation support since at least 2.4.x, but basically: - use SB-VM:NEW-ARENA to make a new arena - use SB-VM:WITH-ARENA to redirect ordinary allocation into an existing arena like you would use WITH-OPEN-FILE or similar macros The only real doc is this internals note, and it doesn't even cover NEW-ARENA which I guess is left as an exercise to the reader…

Yeah, but I am guessing one needs a bit more info on how this works together with GC. For example, once an arena goes out of scope, what happens to allocations made inside it that have been returned and thus are referred to from outside that scope? Are they copied out or do we have a dangling pointer? Stuff like this needs some decent documentation in order to be able to use a low level feature like this properly.

Re: Steel Bank Common Lisp version 2.6.7

#89

Great to see the project is still going strong, I kinda want to try CL but I always feel like I don't have a great use-case.

I bet you do, or you will. In my case, I had been getting movie recommendations from friends and also randomly. I'd look up the flick on IMDB, metacritic, and rotten tomatoes and I'd guess whether I would like it.

I wanted something more 'algorithmic' - and more accurate.

So me and Claude build an sbcl-based Film Recommendation system. Type in a new film name, it goes to open film database OMDB, grabs the scores, and then, using films I have already rated and with a built-in tiny Neural Net, gives me a personal recommendation. It uses the OMDB data and an algo that weights those with my personal values (in half a dozen areas: overall, acting, cinematography, etc), along with a 'comments' box to note for friends / others.

The code is very well-done CL, heavily commented. The film & ratings database is stored as S-exprs, naturally, all in one file. I don't use a database as I only have a few hundred films, but maybe later I will. And that's the point -- this is a living chunk of code that I from time to time bolt in new features, or try new things (e.g. the UI is localhost:8080)

I fretted about having a 'real' project to really dig into CL for a long time, and finally, found a meaty-enough project that ends up being really useful & quite a learning (continuing learning) experience. I start it up inside emacs/sly like this:

  (ql:quickload '(:hunchentoot :dexador :yason))
  (load "s:/filmrec.lisp")
  (filmrec:start)
I have to set the omdb key:

  (setf filmrec:*omdb-api-key* "fxxxx70")
Then, every so often, I retrain the NN:

  (filmrec:retrain)
Good Luck, you'll find a project. And with an LLM buddy, you'll succeed.

Re: Steel Bank Common Lisp version 2.6.7

#90

Earlier quoted context omitted.

Common Lisp is pretty much the opposite of what people think of as functional nowadays. You're constantly changing the image and everything is mutable.

yeah it's a strange aspect of that lisp era, it was born in mccarthy's recursive functions over recursive lists.. and then interactive development over global state added as a layer. i would argue that lispers use of mutability was much more surgical and principled but maybe i'm biased

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...

Post reply on HN