Five Things that Mildly Annoy Me in Clojure | Hacker News Reader

Five Things that Mildly Annoy Me in Clojure

briancarper.net

62 pointsbgray10 comments

I think providing useful stack traces is one of the most important features of a language - since it makes debugging so much easier. Those languages that have great stack traces are Java, Python, Ruby etc. Some languages that have pretty cryptic stack traces are for example ML and Haskell (and C++ if one uses lots of templates). Lacking useful stack traces is a big problem for Clojure, at least if one is new to the language.

"As soon as we started programming, we found out to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs." - Maurice Wilkes

Clojure's stack trace _is_ Java's strack trace.

Because of this it's not as big of a problem as one would think. For real debugging you would attach a debugger, jdb to Emacs, jSwat to any REPL, or the one built into Netbeans (if you're using the Enclojure plugin). These already work well, will only continue to improve, and others will emerge.

That fact, however, doesn't mean there isn't room for future improvement in exception reporting at the REPL. Once the REPL catches an exception, it can do pretty much anything with it, since java.lang.Throwable objects provide convenient methods for a program to examine the stack trace. It's just a matter of someone writing a function that scratches whatever their itch is.

I found that after a while I just got used to reading them, but I'm certain the initially ugly exceptions do turn off some people who don't start out with a strong enough desire to use Clojure.

It's Java's stack trace alright, but the stack traces are not that useful since they mostly relate to tons of internal Clojure related stuff - - than the written code.

Like the blog author notes: "Stack traces in Clojure will often tell you little to nothing about what is causing the error, or more importantly, where it's coming from in your code." - - The most important property of a stack trace is to tell you where the bug is coming from in your own code - - and this is a non trivial task if you compile down to a low-level language.

One of my top complaints is the lack of method combination. You can do something like it by locally binding a function name... sometimes, but CL does it right.

I've been using Clojure for about a week and out of the issues mentioned in the article, I find the stack trace and import issues the most annoying. Also, since it's built on the Java ecosystem, clojure seems to have inherited all the config bullshit which is a big reason I left that world years ago. I guess I thought those issues would have improved over the past 7 years, but it appears not.

import thing is something you have to learn. It's well thought out and fine grained.

the config bullshit - yes. There are various community efforts in progress to help on this front.

that said, once you've built your first web app in Clojure (and Compojure) and debugged/updated it via a remote REPL à la Paul Graham, the pain points become less ... painful.

What's the typical workflow for this look like? That is, if you're making changes to the code live, and you're trying this and that in the REPL to fix things; once you get it working, how do you then get those changes out and then into your source code repository?

Nice to see something that doesn't complain about the usual "it has too many parentheses"; it shows people are actually taking the time to learn the language.

Brian is a pretty regular Clojure blogger; I'd be shocked if he mentioned anything about parentheses. AFAIK, his blog runs on software he wrote in Clojure.

Reply on news.ycombinator.com