Hacker News Reader

Comment by billfruit | Hacker News Reader

From my brief time trying it out about 3-4 years ago, the major things that needs improvement include:

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.

View on HN

Modern Clojure includes that - it's deps.edn (though I'm good with Leiningen).

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/

> you only start a REPL once, so does not really matter

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.

Not sure what you mean here, but... no. You can rebind, of course, but I never found myself in a situation where the REPL was too bad to be used.

I usually restart the REPL only when I add a dependency, so it will be fetched without me caring about it.

I kept getting in this exact situation when defining tests and wanting to _forget_ a test.

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_"

Why do you need to "forget" ? I either change a test, or - wordst case - redefine it as being empty.

Usually something as trivial as renaming the test function.

Yes that's a pain

FP languages are quite immune to that. Sure, you can probably do some stupid thing, but that likely never happens. At least that’s my experience with Clojure REPLs and Haskell’s GHCI.

Exactly. It ties to the excessive startup overhead. If you rename things and change stuff you must run the tests in a fresh JVM to ensure that everything has been evaluated in a consistent state rather ad hoc evaluation in the REPL. This means running from the command line in addition to your REPL or restarting the REPL regularly.

I don't know - the kind of programmer who's always worried about every what-if probably shouldn't choose any dynamic interactive language in the first place. There are plenty of language permutations out there for all sensibilities.

But programmers should be worried about every what-if scenario, regardless of language.

> worried about every what-if

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 prototyping a long running repl is fine.

For validation/testing starting with a clean slate takes away a lot of my worries.

There’s a tool called Clerk which among other things resolves this concern about out of sync definitions https://github.com/nextjournal/clerk

deps.edn isn't solving the same problem as lein. Lein you install it, run "lein" and it starts telling you what to do to get a running Clojure project.

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)

This is a pretty plausible on-boarding with deps. Beginners should be using lein, it is a lot more forgiving and doesn't leave people staring at an error message feeling stupid after 10 minutes being confused about what the docs are trying to prepare them for. It'd be good to include something like that in the default distribution so they don't have to figure that fact out by failing a bit with deps.

This! Leiningen is Maven for Clojure and tools.deps is Ant, for those who used them in Java-land. tools.deps can't build your project without a separate library called tools.build, just like Ant can't pull down dependencies without Ivy.

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.

Trouble is it requires a separate JVM instance to run.

No, it doesn't, if you run it with "trampoline" option. You can also have a cached trampolines for even faster startup. Check the docs ;)

There's no need for a "project" to learn clojure. By time you get to the point of wanting one, you should probably know what a map looks like. You inserted extra {} in your example, a similar mistake would also break a JSON file.

Or you could read the guide on the website: https://clojure.org/guides/deps_and_cli

Yeah this is grim.

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 roughly agree with you but in your deps.edn example, how would you like the tool to respond? Your map/dictionary/object has an uneven number of forms, so what else would you like it to say?

The mistake the programmer has made is copy-pasting a line that wasn't meant to be copy-pasted. The error is gobbledegook about implementation details of the deps file, saying a map is malformed in a file that has 5x maps and not much more to bring in 2 dependencies. The error message itself isn't the problem as much as the spartan design of the deps file that leads rookies into screwing up in a way that isn't obvious what went wrong. There are a lot of easy syntax errors here that give no useful error message explaining what went wrong. There isn't even a hint how many maps are needed to bring in those 2 dependencies (turns out, 4). It'll bleed newbies if they try to figure out this file.

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

deps.edn is a building block not a finished build tool. You need to import libraries for common tasks like building an uberjar.

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

I find that Babashka has completely solved the problem for cases where I need fast startup with Clojure. I've been using it for all my scripting, and it works fantastic.

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. To what?

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.

3. It is Cider + nrepl + some other utilities these seem to depend on.

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.

If lein is so essential, then why not bundle it into the clojure base jar itself.

It must have been eight or nine years since you last checked.

>1. Improve startup times.

.Net code can be AOT compiled to native code. Doesn't JVM have a similar option?

It has through GraalVM. (Just a “fun fact”, there used to be gcj as well 20 years ago that could also produce native executables)

Reply on news.ycombinator.com