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

91–100 of 172 posts

Re: Steel Bank Common Lisp version 2.6.7

#91

Post by nesarkvechnep »

GeorgeTirebiter wrote: post #89
NeutralForest wrote: post #5

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…

But then again, why would I use CL for this when I can use Elixir? I’m not the original commenter but I too can’t find a use case for CL.

Re: Steel Bank Common Lisp version 2.6.7

#92

Post by galaxyLogic »

baq wrote: 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.

That would be a bad idea. In Smalltalk the "image" was the main thing and I think that was one thing that led to the commercail demise of Smalltalk. You can not combine two (or more) images. You can not build new things by using "images" as components. Instead as we know source-code modules with well-defined interfaces between them is what keeps productivity hhigh. At least before AI.

Re: Steel Bank Common Lisp version 2.6.7

#94

Post by goatlover »

galaxyLogic wrote: post #92
baq wrote: 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.

That would be a bad idea. In Smalltalk the "image" was the main thing and I think that was one thing that led to the commercail demise of Smalltalk. You can not combine two (or more) images. You can not build new things by using "images" as components. Instead as we know source-code modules with well-defined interfaces between them is what keeps productivity hhigh. At least before AI.

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.

Re: Steel Bank Common Lisp version 2.6.7

#96

Post by BoingBoomTschak »

whyenot wrote: post #86
baq wrote: 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.

The worst and best thing.

Re: Steel Bank Common Lisp version 2.6.7

#97

Post by Scarblac »

pfdietz wrote: post #31
dismalaf wrote: post #19

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.

Image saving isn't something that's done very often, in practice.

What is done in practice, for daily development use? Building the image in memory from source files at startup?

Re: Steel Bank Common Lisp version 2.6.7

#98

Post by guenthert »

p_l wrote: post #52
taolson wrote: post #49

Fun fact I learned from a Func Prog podcast: the name Steel Bank is a play on it's origin as Carnegie-Mellon Common Lisp (Carnegie made his fortune in Steel, while Mellon did so with Banks): https://www.sbcl.org/history.html

There's another wordplay in the name. Namely, that "SB" stands for "Sanely Bootstrappable" - something that the CMU Common Lisp was unable to do

It is my understanding that easing bootstrap was the original motivation of the fork of CMU CL. I'm a bit confused about that, since CMU CL supports compilation to byte-code (which should make a port to a new architecture comparatively easy), a feature which was dropped in SBCL.

Re: Steel Bank Common Lisp version 2.6.7

#99

Post by guenthert »

whyenot wrote: post #86
baq wrote: 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.

Nobody stopped anyone to come up with variants, just from calling those ANSI Common Lisp compliant. There are after all many, most of which are long dead already.

Re: Steel Bank Common Lisp version 2.6.7

#100

Post by lenkite »

iLemming wrote: post #47
baq wrote: 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.

> How would a kubernetes We have a few services built in Clojure and we expose nrepl port on our pods in our SDEs, it's enormously helpful to test and debug things on the fly, without having to redeploy or restart anything. Without having to deal with state, caching, etc.

For non-LISP languages on k8s, you have Tilt (https://tilt.dev/) or Skaffold (https://skaffold.dev/) nowadays to support continuous development.
Post reply on HN