Hacker News

Does it scroll? Because I like to scroll around when thinking about my program. I always imagine Lips REPL ppl saying they keep the entire program in their head but that can't be right. That's doing things the hard way.

Can confirm! Once I started doing this (now mainly with iPython interactive in VSCode) my output speed increased dramatically

The main problem that Rust tries to solve, and that functional programming (which Clojure heavily leans into) solves, is avoiding shared mutable state, which leads to data races and (potentially subtly) wrong concurrent programs. Functional programming avoids shared mutable state by avoiding mutable state. Operations are only represented as transformations instead of mutations. Other languages like Erlang / Elixir use message passing techniques like the Actor Model to avoid shared mutability. Instead of avoiding mutability, like in functional programming, in the Actor Model you avoid sharing, by instead sending messages around.

Rust is interesting because it solves the problem of shared mutable state, while allowing sharing, and allowing mutability, just not at the same time. State can be mutated until it is shared. While it is shared, it cannot be mutated. This is the goal of the ownership system in Rust.

One thing that jumped out at me is you don't need Rust's borrow checker to prevent thread race conditions because data in Clojure is immutable. That's a huge simplification over Rust. What I hear mostly about Rust is complaints about the borrow checker. I wrote a simple Rust utility and found it frustrating. But again, don't take my word for it because I don't know either language.

This the “non-low level” code qualification.

I have been enjoying Chez scheme these last few weeks, and having an LLM has helped me when i have missing libraries. The ability to just wrap a C library and statically link everything into a single binary has been really nice too!

Although niche, things are pretty lively in the community. Among other things this year great progress was made on Jank, the native LLVM-based implementation with seamless low-level C++ interop. As part of that work a test suite is being created [0] and now includes runners for all of the major implementations to compare compatibility, next best thing besides a formal specification.

[0] https://github.com/jank-lang/clojure-test-suite

Clojure will be around as long as the jvm. It’s mostly done at the core level, most updates are to leverage new host features nowadays. The rest is happily provided at the library level by the community (which is still very prolific).

And it’s not tied to the jvm per say, look at clojurescript (and derivatives) or the upcoming jank.

It’s far from dead. As much as I like CL, the ecosystem is a bit of a desert compared to the jvm.

But also: https://survey.stackoverflow.co/2024/work#3-salary-and-exper...

JVM is very much not dead even slightly. They just released virtual threads, which are ridiculously awesome. Also it's not tied to a single platform, clojurescript lets you write clojure in browsers and on node.js, and babashka lets you use clojure in a scripting environment via a single executable

I prefer CL, but… clojure at least has some commercial usage and is by far the most successful of current lisps, if we do not count elisp.

Clojure is not going anywhere anytime soon.

It sees plenty use as Clojure/Clojurescript and Babashka. (and other niche variants). Jank is shaping up to be real nice too.

I don't care if it's niche if it solves my problems and gets the job done faster.

The JVM has suffered a fate worse than death: it's become so wildly successful that it's boring. So much enterprise shit runs on Java that it has sort of faded into the background noise of civilization and, like the System/360 (now Z/OS) before it, doesn't grab headlines anymore.

I frankly miss the JVM. I work almost exclusively in Rust these days and haven't worked in Java or Scala since 15 years ago, and I do prefer working closer to the metal.... But... The JVM is an amazing mature runtime with a boatload of tooling. JMX, which has been there since almost the beginning, is the kind of thing missing from almost everything other managed runtime I've worked with.

The amount of R&D that has gone into making it execute with good performance, and its overall stability...

Yeah, it's got the curse of being boring.

I do think it is perhaps unfortunate that Clojure is tied so heavily to the JVM, because I actually don't think it gains much from that ecosystem... but it's a product of the time it was first written.

Actually hell. I'm between jobs, I like Lisp, and I miss the JVM. I've never worked in Clojure, but does anybody want to hire me to work in it? :-)

> the JVM, which looks more dead with every passing year.

Lol, only dying/dead in the febrile imagination of some HN commenters. The JVM has had some of the most explosive feature activity in the last several years. Java had several million greenfield projects in 2024-25 - among the top 6 greenfield programming languages according to the Github Octoverse.

You're saying that Clojure is looking more dead, so you suggest... Common Lisp? That looks considerably more dead than Clojure.

I'm referring to the fundamental idea in AI of knowledge representation. Lisp is ideal for chapters 1 through 4 of AIMA, and TensorFlow has shown that NN can be solved well with a domain specific language which lisp is known to be great for.

In fact, the first edition of AIMA even had a NN and Perceptron implementation in Common Lisp. (https://github.com/aimacode/aima-lisp/blob/master/learning/a...)

Is it the right link? "Lisp" is mentioned once, in a good way. It's an old post too, it mentions Emacs' ilisp mode, which is the now unused ancestor of Slime.

LLMs seem better suited to help with the Tower of Babel we've created for ourselves: aws commands, Terraform modules, Java libraries, Javascript/React, obscure shell commands, etc.

I've been having a great time generating Common Lisp code with LLMs. eg. https://github.com/atgreen/cl-tuition , https://github.com/atgreen/ctfg , etc.

The strength of Lisps is in ability to define DSLs and then concisely express solutions for problems in that domain. Arguably no other programming language was able to exceed or even match that power until now.

The math behind transformers is deterministic, so LLMs could be treated as compilers (putting aside intentionally adding temperature and non-determinism due to current internal GPU scheduling). In the future I imagine we could be able to declare a dependency on a model, hash its weights in a lockfile and the prompt/spec itself will be the code, which corresponds to that insight.

JavaScript has been called "Lisp in C's clothing". JavaScript is not a "pure" functional language but are any of the Lisps either? They might have immutability as the default. But I don't see why an Object-Oriented language could not have immutability as the default as well?

In the 80's Lisp was already over 20 years old.

From what I've understood about Haskell is that it allows you to divide your program into parts which are either pure functional, or mutable. That is great when you read the program, you can know that what you are reading now is immutable, whereas in the some other well designated parts it is mutable.

But with Lisps isn't it the case that statement 1 can be immutable while the next statement 2 is mutable? In other words it mixes mutable and immutable calls into the same program-file without really isolating them from each other in any way. And that means if one part of the program is "impure", so is all of it. You can't isolate those parts except by following a convention, but conventions are not something that it enforces. And you can't know which parts of your program are pure except by reading the code-statements in detail. Am I right?

It supports basically all styles which makes it wonderfully useful in whatever domain you happen to find yourself in.