And ditch Emacs (unless you are already using it/used to it) and try VSCode + Calva that runs basically out of the box.
Exceptions... yes.... they are clear when you know what they mean, but it takes time, because they are so long.
Startup... you only start a REPL once, so does not really matter (to me at least). For compiled code, you can try GraalVM, that has zero-ish startup time - because all static initialization is resolved at compile-time.
Just my $.02
Edit: Calva also includes a debugger - never used it, but here it is https://calva.io/debugger/
People say this a lot in Clojure, but don't you worry about global vars that no longer point to what you thought they pointed to? For this reason alone, I almost always load a new Python REPL.
I usually restart the REPL only when I add a dependency, so it will be fetched without me caring about it.
And the OC's onboarding experience reminds me of mine. You need some external tutorial / book to get setup.
Also, last time I used calva, the only thing I got was kondo complaining they the default test created in a brand new project were using unknown symbols, or something. So I assumed my setup was wrong, and gave up.
Clojure is "simple made easy _once you've done all the hard part as a bizuthage_"
I hear you about this, but during prototyping one cannot be excessively concerned with did I change the global state enough such that it's better to just start a new REPL (and have to worry about the associated costs)? And if you ask this question a lot, long running REPLs are not a good idea for development.
For validation/testing starting with a clean slate takes away a lot of my worries.
Deps you install Clojure and ... no hints how to get to a running project.
"touch deps.edn"? Still no hints how you get from here to functioning clojure dependencies. It isn't a YAML file. Isn't JSON. No template.
Read the reference page (https://clojure.org/reference/deps_and_cli)? We quickly learn that you can execute a function by invoking "clojure [clj-opt] -X[aliases] [a/fn] [kpath v] kv-map?". Still not much closer to installing a dependency, a lot of people probably give up here.
Oh, there is a guide! Read the guide (https://clojure.org/guides/deps_and_cli). Now we get to our first dependency.
Lets add a 2nd one!
{:deps
{com.github.seancorfield/next.jdbc {:mvn/version "1.3.834"}}
{clojure.java-time/clojure.java-time {:mvn/version "1.1.0"}}}
$ clj
Error building classpath. Error reading edn. Map literal must contain an even number of forms (~/deps.edn)
Maven (like Leiningen) bundles all of that in a single tool, plus adds tons of more options. On top of that, you have a plugin for almost anything.
Or you could read the guide on the website: https://clojure.org/guides/deps_and_cli
There is https://github.com/practicalli/clojure-deps-edn which solves this but it’s not linked to from any official docs which seems a miss to me. As well as the config and full documentation, it also comes with a video walking you through a demo of all the features.
I think their should be a "lein-for-deps-template" that subtly guides people in the right direction by starting the project up with 2+ dependencies. Lein dodges this by using a list-of-list data structure where this mistake is harder to make (copy and pasting stuff in brackets is the right strategy in lein) and there is much more boilerplate in a project.clj to hint what our aspiring Clojure programmer needs to fill in.
My problem here is that the entire way through that story, at no point is there a simple prompt in the official reference documentation telling people what a deps file with multiple dependencies should look like. Even finding the examples of 1 dependency is quite deep in and seems to be an advanced topic (you'll note the sibling comment that considers dependencies an advanced topic for people who already know the language well enough to reflexively get maps right, and it says a lot about the actual complexity of deps that the official guide to installing dependencies thinks 2x dependencies is out of its scope).
There are plenty of reasons to start a new REPL: - adding a library
- changing the project config
- messing up the repl state
- starting with a clean slate
- switching branches
.Net code can be AOT compiled to native code. Doesn't JVM have a similar option?
2. It is. tools.deps
3. It's just one package to install? Why not use intellij or vs code if you want?
4. Yep. This is true.
5. I don't think I've ever thought that. Could you give an example?
6. Cider (emacs) and Calva (vs code) both have this.
7. You can do that just fine, once again tools.deps lets you do this with no hassle.
6. When I last checked emacs-cider only gave a stack trace when exception occurred, not a live repl at that program state. See how emacs responds when there is an exception in elisp, one gets dropped into repl where one can examine, even modify the value of variables at that point of exception, and even try restarting execution from that point.
Much of tutorial and other information seems to use leiningen atleast when I had last seen it. If tools.deps is the canonical way to do it, they why are people refering to lein which is a third party tool.
Using lein, is a batteries-not-included approach, I am not sure why it is seems so popular.
The best part is that you can develop it interactively via the REPL the same way as regular Clojure. You just run bb --nrepl-server and connect an editor to it. Calva with VS Code works great for this incidentally.
1. Improve startup times.
2. Ditch leiningen, its functionality should be included in base clojure.
3. Emacs toolchain for Clojure seems massively complex and have too many parts. Makes it difficult to get it reliably installed/setup.
4. Getting it set up on Windows seems obscure, which shouldn't be. Part of the problem is that lein is not distributed with clojure.
5. Error messages are cryptic.
6. Needs a lisp style debugger. Once an exception occurs we need to get a repl at that point of state.
7. Needs provision include Local jars easily without having to set up a maven repo for the same. This is very important for hobbyist work, and for exploratory programming.