Live data from Hacker News

Steel Bank Common Lisp version 2.6.7

sbcl.org

31–40 of 172 posts

Re: Steel Bank Common Lisp version 2.6.7

#31

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.

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

Re: Steel Bank Common Lisp version 2.6.7

#32

Earlier quoted context omitted.

>> said: lovely, but I ain't using it at work. Says who, you? Wrong. I use Common Lisp at work. edit: and not just use as in a side toy, design and writing software in CL is my primary responsibility. FWIW, at a FAANG!

>FWIW, at a FAANG! Do you work on ITA? Only FAANG I'm aware of using Lisp is Google.

Nope not on ITA. I work at the intersection of HW and SW. Lisp is valued for its strengths and I haven't come across any tool better to explore complex problem space. Of course, the opportunities are fewer, get filled up organically and are better suited for someone with valuable domain knowledge who can translate it into working space for a wider team using Lisp as the tool to write the spec!

Re: Steel Bank Common Lisp version 2.6.7

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

Sure the language might not be immutable but the lisp machine alt universe's "overton window" would I imagine be more functional then today's (JVM? maybe that's the qnalog?) reality.

Re: Steel Bank Common Lisp version 2.6.7

#34

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.

I would presume there was a lot of mixing of imperative/functional in the 80s where this alt universe starts. I think the same type of world in which lisp machines would have become king would also be similar

Re: Steel Bank Common Lisp version 2.6.7

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

It'd look like Graal, which is a real thing you can use today.

Re: Steel Bank Common Lisp version 2.6.7

#36
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…

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 Prolog in front of them, and their attention flows upwards to the most general principles to whine about. The entire thing is that if you stick them into an unfamiliar environment, they will vocalize their discomfort through rationalization. I think most people who have led teams will know exactly what I'm talking about.

Not that these people are necessarily bad at their jobs, but they're definitely a personality type you should learn to identify so you can manage them properly.

Re: Steel Bank Common Lisp version 2.6.7

#37
post #23

Earlier quoted context omitted.

CL can be used pretty much anywhere nowadays, even on the web with ECL wasm compilation.

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.

A binary has a startup time of like 20 milliseconds, the overwhelming majority of that is setting up page tables iirc. While that's a lot for a small cli utility called in a loop, it's really nothing for a desktop application.

I wish more desktop applications could hit even a 100ms startup time. These days it feels like 5 seconds or more is the norm.

Re: Steel Bank Common Lisp version 2.6.7

#38
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 (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…

Docker deploys is a bit like that I think. Overall, I think many languages and programming systems pick up pieces from each other nowadays. PHP almost by accident can be quite stateless. Yet it's looking more like Java. Many things which could be deployed as an executable, are deployed as VM images. I'm sure we can come up with more things...

Re: Steel Bank Common Lisp version 2.6.7

#39

Earlier quoted context omitted.

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…

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

Re: Steel Bank Common Lisp version 2.6.7

#40

Earlier quoted context omitted.

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…

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.

Post reply on HN