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

71–80 of 172 posts

Re: Steel Bank Common Lisp version 2.6.7

#71

Post by muvlon »

dismalaf wrote: post #19
tyromaniac wrote: post #13

Earlier quoted context omitted.

We wouldn't have need such barbaric things in a lisp world. :p Personally I think/hope they would have earlier discoveries / more broad usage of the deterministic systems like nix etc, which are built upon functional principles of immutability etc. Maybe the world would be guix/Hurd!

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, all the common lispers I know are all about interacting with "live" programs as opposed to "dead", compiled ones. Nix takes the last live, mutable, reflectable part of the world of programmers today, the OS itself, and turns it into a dead program as well. So common lispers tend to hate Nix with a passion (as do Smalltalk users).

Re: Steel Bank Common Lisp version 2.6.7

#72

Post by attila-lendvai »

muvlon wrote: post #71
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.

Yeah, all the common lispers I know are all about interacting with "live" programs as opposed to "dead", compiled ones. Nix takes the last live, mutable, reflectable part of the world of programmers today, the OS itself, and turns it into a dead program as well. So common lispers tend to hate Nix with a passion (as do Smalltalk users).

i'm a lisper, and i don't hate nix. i prefer guix, for sure, but i don't see this hatered you're talking about among other lispers either.

Re: Steel Bank Common Lisp version 2.6.7

#73

Post by attila-lendvai »

fiddlerwoaroof wrote: post #55
WillAdams wrote: post #24

Earlier quoted context omitted.

That (deployment is via a customized image) is the thing I find most awkward. Somewhere, I have a copy of a commercial LISP for Windows which would compile to an executable --- apparently this sort of thing is still possible, but it's not widely known/used, and sadly Jean-Marie Hullot's "SOS Interface" for the Mac was co-opted to NeXTstep: https://denninginstitute.com/itcore/userinterface/GUIHistory... I'd dearly lov…

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

Re: Steel Bank Common Lisp version 2.6.7

#74

Post by Zak »

kscarlet wrote: post #63
Zak wrote: post #39

Earlier quoted context omitted.

It seems to me the Clojure community internalized the lesson of not writing macros unless it's really necessary more than other Lisps did.

So does the community of every other dialect (Common Lisp, at least). Write a function if you don't have to write a macro, and maybe declaim the function to be inlined. The "Lisp Curse" is a ridiculous and tired myth that can only be invented by people who have looked at the language for 5 seconds and went straight to finding an excuse to not learn it.

Is it? I saw macros and went mad with power. I wrote a macro that could have been a function today.

But seriously, I think Clojure has a particularly strong tradition of writing clean, readable code.

Re: Steel Bank Common Lisp version 2.6.7

#75

Post by WalterGR »

DonHopkins wrote: post #45
sroerick wrote: post #8

I'm going pretty deep on Lisp on accident - can anybody give me more context on this?

(((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((

That’s Scheme, not Common Lisp.

I’d recommend using close parens for your code sample. Those are portable between the two.

Re: Steel Bank Common Lisp version 2.6.7

#76

Post by srparish »

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.

An extensible LLM agent (such as https://pi.dev/ or maybe hermes) written in common lisp could be interesting. Conditions and restarts and general debugging and repair of the live system, fast startup, native execution speeds, ability to add or replace or modify core functionality on the fly, solid multi-threading support, dynamic introspection including documentation, CLOS and multiple dispatch, saved images.

Re: Steel Bank Common Lisp version 2.6.7

#77

Post by attila-lendvai »

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.

if you are pondering about that, then i think you'll like this:

https://ngnghm.github.io/

Re: Steel Bank Common Lisp version 2.6.7

#78

Post by jojohohanon »

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

In my first job, grumpy Martin had as one of his many indispensable tasks, to build cmucl. (Itasoftware, one of the main lisp shops of the age)

Re: Steel Bank Common Lisp version 2.6.7

#79

Post by mechanicum »

reddit_clone wrote: post #64
joshmarlow wrote: post #42

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.

Probably this?

“Concurrency Oriented Programming in Termite Scheme”: http://scheme2006.cs.uchicago.edu/09-germain.pdf

Implemented in Gambit Scheme: https://github.com/FredericHamel/termite-scheme

Re: Steel Bank Common Lisp version 2.6.7

#80

Post by groundzeros2015 »

Shorel wrote: post #28
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.

Not that different. AWS already has lots of AMI and docker are essentially image based. We would version whole images in something like git, and that's all.

Uhm. I can think of more differences
Post reply on HN