Live data from Hacker News

Steel Bank Common Lisp version 2.6.7

sbcl.org

61–70 of 172 posts

Re: Steel Bank Common Lisp version 2.6.7

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

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-expression reader you'd have to build a json like subset from first principles. even things like colons in symbol name package:symbol will trip you up. it's been understood since long time ago, that common internet standards, like RFCs, are the preferred method. in which case the fact that it's an s-expression versus a json is pretty much irrelevant. it's a kind of reader/writer anyway.

Re: Steel Bank Common Lisp version 2.6.7

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

Not In production yes?

Also not sure what is SDE.

Re: Steel Bank Common Lisp version 2.6.7

#63
post #39

Earlier quoted context omitted.

> The very power of Lisp, macros, dynamic programming, reflection lead to a mess of an ecosystem where every single developer reinvents the wheel and nobody can understand yet another DSL invented by the next developer next to them. Have you like looked at anything in the Clojure ecosystem because this description makes no sense of any kind. Clojure has macros but less powerful than common lisp and Clojure code in th…

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.

Re: Steel Bank Common Lisp version 2.6.7

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

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.

Re: Steel Bank Common Lisp version 2.6.7

#65

Earlier quoted context omitted.

> The very power of Lisp, macros, dynamic programming, reflection lead to a mess of an ecosystem where every single developer reinvents the wheel and nobody can understand yet another DSL invented by the next developer next to them. Have you like looked at anything in the Clojure ecosystem because this description makes no sense of any kind. Clojure has macros but less powerful than common lisp and Clojure code in th…

Further confirming my point on why it is the only lisp with some genuine traction out there.

I think you have very little insight to what you're talking about. The modern Lisp landscape is nothing like what it was in the 90s or even 2000s. The amount of practical shit Lispers been quietly building these days is genuinely impressive.

Have you ever seen GitHub language stats? Elisp there in the list a few points behind Lua, Elixir, OCaml and Haskell. The amount of Emacs Lisp on GitHub alone should be at least surprising. There's so much Elisp in the wild - the amount of it probably exceeds Clojure, CL and Racket combined. And let me remind you that it isn't a "general-purpose PL" - it's meant for one and only purpose.

Look at the number of package for AI-coding in Emacs¹ - 35 and counting. Mind that emacs has no central curated marketplace with the same discoverability as VSCode's. Packages live across MELPA, GNU/NonGNU ELPA, and countless personal repos, so a hand-counted 35 from a Reddit roundup is almost certainly an undercount of what exists in the wild.

And that's just one of the observable axes of Lisp. Anyone can join Clojurians Slack and scroll through #news-and-articles, just out of curiosity. It is hard to find a problem space today or a runtime where Lisp has not proliferated. Why? Because Lisp is enormously practical. Just because you convinced yourself it isn't, doesn't change a thing about reality.

---

¹ https://www.reddit.com/r/emacs/comments/1uwm3c0/the_state_of...

Re: Steel Bank Common Lisp version 2.6.7

#66

Earlier quoted context omitted.

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

Not In production yes? Also not sure what is SDE.

No, of course not in prod. SDE stands for "Software Developer Environment" - ephemeral VMs we spin up for testing before stuff hits staging/prod clusters.

Re: Steel Bank Common Lisp version 2.6.7

#67
post #29

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…

You probably want Clog: https://github.com/rabbibotton/clog

Clog is very cool. As an alternative, I have recently been building Common Lisp UIs with webview (I have two example webview apps as recent additions to my Common Lisp book).

re: heap based delivery: not a good idea. But, I sometimes do heap based development when I have a ton of data I want loaded every dev session, then I save a SBCL image, and restart my Lisp environment using my custom image.

Re: Steel Bank Common Lisp version 2.6.7

#68
post #16

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 isn't functional in that sense.

When I learned (Common) Lisp at Georgia Tech in the summer of 1995, we were encouraged to make as many functions as possible purely functional, and if mutation was needed, to try to hide it within the bounds of a function.

So while Lisp may not be purely functional, the culture hewed that way.

Re: Steel Bank Common Lisp version 2.6.7

#69

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.

I used to do this to build command line utilities in SBCL, with millisecond initialization times. Good technique, and compress the image so executables are fairly small.

Re: Steel Bank Common Lisp version 2.6.7

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

Lisp's been around for 70 years at this point and hordes of developers tried it and said: lovely, but I ain't using it at work. I'm strongly convinced, having used Scheme, CL, Racket, Clojure that Lisp is doomed to be (mostly) a hobby language. The very power of Lisp, macros, dynamic programming, reflection lead to a mess of an ecosystem where every single developer reinvents the wheel and nobody can understand yet a…

+1 upvote

I don’t agree with you but your comment is very well thought out and doesn’t deserve downvotes.

Post reply on HN