You have files and editors for your files, eg emacs or vim or vscode.

Your editor is also directly connected to your running application and can compile individual functions or pieces of code to update the application without a full edit/compile/run/test loop. It happens way faster and more interactively while you code. You can directly inspect the running program and its data within that same framework and with the exact same tools and functions you use to code.

To answer another way, you don’t code your application in a REPL, like by line , but with all the tools you’d expect (editor or ide, git, etc) PLUS that live connection to your software.

The nice thing about REPLs is that you can try random snippets code. And as the sibling comments put it, you rarely switch to the prompt interface. Instead you `eval` a bit of code and it got sent to the running state of your program as if you've typed it as the prompt. It's more like brainstorming a program using a mood board.

You kinda have to keep track of the state, but the latter can be easily inspected so there's no need to keep it your head.

You tell your editor to evaluate any arbitrary part of the source file you currently have open, and it does so in the context of your running application without stopping it.

Then you see the result in another pane of your editor.

It's pretty revelatory. You're molding your program while it's running.

> The main problem that Rust tries to solve, and that functional programming (which Clojure heavily leans into) solves, is avoiding shared mutable state

I would argue that avoiding _unrestricted_ shared mutable state is a mean for Rust, not a goal. The main goal would be to provide a way to make safe, fast and non garbage collected programs, which doesn't seem at all what clojure is aiming for.

Well, erlang and elixir operate on almost exclusively immutable data, in addition to message passing between "processes". They are more strict than most other languages in that regard.

As someone who has gone deep into both functional programming (with Elixir, Clojure, and Scala) and also Rust, they solve the same problem in different ways with different tradeoffs.

The problem is that shared mutable state is incredibly hard to get correct, especially when concurrency enters the picture.

Elixir and Clojure sidestep the problem by making copying data so cheap that instead of sharing references to mutable data, you make all data immutable and copy it whenever you want to change it in some way. (Which is a classic technique: don’t like the problem? Solve a different problem that sidesteps the original problem in a creative way)

So you have a lot of functions of roughly the shape `f -> f` (return a new thing) instead of `f -> ()` (mutate a thing in place).

This possible at all by the clever use of some novel data immutable structures like HAMTs that are able to approximate the performance of traditional mutable data structures like hashmaps or arrays while presenting an immutable API.

As it turns out, this is a much easier programming model for most of us to get correct in practice (especially in the presence of concurrency) than sharing mutable state in an imperative programming language like C or Java or Python.

The tradeoff is that the immutable functional data structures actually do have a some performance overhead. In most domains it's not large enough to matter, but in some domains it is, and in those domains you really do need mutable state to eek out that last bit of performance.

Which is where Rust comes in.

In Rust's model, data can either mutable or shared, but not both at the same time. The Rust compiler computes the lifetimes of data throughout your program to ensure that this invariant is upheld, so mutable data is not shared, and shared data is not mutated.

The downside of this is that you have to internalize these rules and program to them. They can be tough to learn and tough to program with even after you have learned them, though it does get much easier with experience, I will say.

The upside of Rust's model is that you can have your cake and eat it too: you can keep the high performance ceiling of a true mutable data model while maintaining memory and resource safety.

In short, you can think of Clojure/Elixir as sidestepping the shared mutability problem at the cost of some runtime performance (though again in practice it is smaller than you would think), and Rust as tackling the shared mutability problem head on by transferring the cost of solving the problem to a more complicated compiler and a harder-to-learn programming model.

These are just my opinions having used both Rust and the immutable data functional programming stuff in anger. I'm not trying to present one as being better than the other, the key point is that they're both better than what came before.

I would argue that F# would be the choice of language in place of Rust if you don't want to deal with Rust's type system. F# is immutable by default with good concurrency and a static type system.

Wow. I clicked on your user name for some reason. You've been here 19 years and only have 34 karma and made only 16 comments!

Anyway, I came here to say Clojure also targets JavaScript and could target more like ClojureCLR https://clojure.org/about/clojureclr

Here, have another karma point!

Which makes Clojure extra tempting because there is a bit of a infectious way to get Clojure i to corporations when you are always just handing the ops guys a "Java" we app bundled as a jar but secretly inside it's all Clojure compiled classfiles that work perfectly run on many JVM-based web servers with no additional effort.

I think Rich even alludes to this fact in one of his talks where it would be disallowed to run Ruby/Python/Rust whatever but it's Java then it's a know entity.

I haven't tried clojurescript but I'm fearful of languages that run on top of other languages or platformks, because of complications that produces for debugging.

How do you debug ClojureScript? Can you modify the source-code while in the debugger? That is a huge time-saver, you debug and see a typo and fix it right away. My preference are influenced by my background in Smalltalk's "live" environemnt: you see the variables, the stack, and can change anything without having to stop the debugging session and then have to go back to the "editor" and then locate the place you (now know) you want to modify, and then start again.

Prolog and Dart programmers earn the least, but Erlang and Clojure programmers earn the most? Something is fishy here...

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

When I was doing more Clojure, I loved that it was on the JVM because it meant I got to use every Java library under the sun. There are tons of battle tested Java libraries that didn't have to be rewritten in Clojure, and getting to use them for approximately zero financial and runtime cost was a HUGE benefit of Clojure compared to other niche FP languages.

Just to counter-balance the inferred conclusion that Common Lisp would not have any commercial usage (sorry, words are important, FUD is too close from hasty wording or hasty conclusions): https://github.com/azzamsa/awesome-lisp-companies/ (example companies using CL today, and yes some pick it for new projects, and yes some hire) (and I don't want to argue if the list is impressive or not: it's some commercial usage :D best,)

I'm not sure that Common Lisp looks less dead, but rather, more eternal.

it’s also Paul Graham’s website…

https://paulgraham.com/bio.html

Pull request incoming to add back your missing README emojis.

> the prompt/spec itself will be the code, which corresponds to that insight.

What I've understood from discussions on HN is that LLMs are non-deterministic. Am I right? So the same prompt when executed again could produce a different answer, a different program every time.

That would mean the prompt is not a great 'highleve lanaguage", it would get compiled into a different Lisp-program depending on the time of the day?

[dead]

> Basically what he said was that lisp ended up not working well for larger software projects with 5 or more people on them

I don’t think "doesn’t work for teams of 5+" is a fair generalization. There are production Clojure and Emacs (Lisp) codebases with far more contributors than that.

Language adoption is driven less by inherent team-size limits and more by social and practical factors. Some students probably don't like Lisp because most people naturally think in imperative/procedural terms. SCIP was doing a great job teaching functional and symbolic approaches, I wish they hadn't shifted their courses to Python, since that increases the gravitational pull toward cognitive standardization.

If you're into Haskell, you may like Coalton. It's an FP language written in CL with seamless interop.

https://github.com/coalton-lang/coalton

Common Lisp is like the vast majority of programming languages, yes.