Live data from Hacker News

Notes on debugging Clojure code

eli.thegreenplace.net

31–40 of 50 posts

Re: Notes on debugging Clojure code

#31
Slight tangent: Am I the only one that's a little bit annoyed that it seems like you need to start using the complex beast that is Emacs to get first class Lisp support? There are one-off apps, but everyone swears by SLIME mode or similar.

Yes, I get it. The editor itself is written in Lisp. It's the most hackable thing out there. Yes, fine. It is a masterpiece of technical achievement. That's all well and good, but...

I just want to learn the language, not the language and an editor that seems entirely alien at the same time. If I had to learn vim as a prerequisite to learning and writing Python (specifically using the debugger and a REPL), I probably would have never learned Python.

Re: Notes on debugging Clojure code

#32
post #17

After being Clojure-only for a long time, I decided to write the front end to my last project in Elm, just to see what the fuzz was about. While I miss code-is-data very much, there is no turning back from the type system and how there are no unpure functions. It is just so mind-blowingly easy to catch almost every bug I would usually write. I'm afraid this is the point where I should try Haskell, and be unsatisfied…

> While I miss code-is-data very much FWIW, Elixir has this (and is possibly the only non-homoiconic language to implement "true" macros) Opt-in typing, though. Regarding Elm, I love that runtime errors are considered compiler bugs.

Nim and Scala are not homoiconic, yet they both have true macros

Re: Notes on debugging Clojure code

#33
post #21

When it comes to debugging, I'm firmly in the printf camp; I rarely prefer debuggers over printf-based debugging I'm struggling to understand this. Why would you ever prefer printf debugging in your local dev environment over using a debugger?

There is rarely a situation where you can't slip a printf or log message into a piece of code and observe how it's working in production. Depending on the complexity of the problem the debugger can also hide a lot of problems- is there a timing issue? is it intermittent? What happened the last 200k times? An interactive debugger technique doesn't help you at all if all you have is a coredump of an issue that happens once a month.

It is definitely a personal preference, but I just find myself in too many situations where the constraints to make a debugger in a dev environment work well end up adding a lot of complexity to the problem space. I know printf/write to a file works every time, everywhere.

Re: Notes on debugging Clojure code

#34

Slight tangent: Am I the only one that's a little bit annoyed that it seems like you need to start using the complex beast that is Emacs to get first class Lisp support? There are one-off apps, but everyone swears by SLIME mode or similar. Yes, I get it. The editor itself is written in Lisp. It's the most hackable thing out there. Yes, fine. It is a masterpiece of technical achievement. That's all well and good, but.…

It makes sense to use Lisp-specific tools with Lisp, otherwise the whole experience is underwhelming. The best Lisp tools are usually written in itself or some variant of it.

On the Mac you can download Clozure Common Lisp from Apple's Macintosh application store:

https://itunes.apple.com/us/app/clozure-cl/id489900618?mt=12

It comes with a small IDE written in itself.

A lot of people who use CL as a serious hobby or for work use one of the commercial development environments: Allegro CL or LispWorks.

There are several other (some are obscure) options, but many use GNU Emacs / Slime or its fork Sly.

Re: Notes on debugging Clojure code

#36

Slight tangent: Am I the only one that's a little bit annoyed that it seems like you need to start using the complex beast that is Emacs to get first class Lisp support? There are one-off apps, but everyone swears by SLIME mode or similar. Yes, I get it. The editor itself is written in Lisp. It's the most hackable thing out there. Yes, fine. It is a masterpiece of technical achievement. That's all well and good, but.…

Try intellij with the cursive plugin for clojure. Tim Baldridge has a video or two on how to set it up.

Re: Notes on debugging Clojure code

#37
I have years working experience with Clojure. The tooling in Clojure is much better than this. If you want a debugger, Cursive has it out of the box, if you are used to Intellij, you can use it right away. If you are an Emacs user, then you know your way around CIDER and its tooling. It's not that I don't agree with the author's post. But I mean for simple functions, good enough tooling and unit tests are your friends.

Re: Notes on debugging Clojure code

#38
post #23
post #17

After being Clojure-only for a long time, I decided to write the front end to my last project in Elm, just to see what the fuzz was about. While I miss code-is-data very much, there is no turning back from the type system and how there are no unpure functions. It is just so mind-blowingly easy to catch almost every bug I would usually write. I'm afraid this is the point where I should try Haskell, and be unsatisfied…

You should definitely try, even if you end up being somewhat unsatisfied every time you have to use something else. When I write code in Haskell, it feels right, just like when I discovered Lisp. Only better. And oh, the purity! Not only in the mathematical sense, even the code is completely deprived of clutter.

But at what cost!? Every time I write Haskell code it reads like a mathematical proof that's beyond my ability to comprehend! Whereas my Ruby, Python, and Clojure programs read like a poem I might have written in third grade.

Re: Notes on debugging Clojure code

#39
post #32

Earlier quoted context omitted.

> While I miss code-is-data very much FWIW, Elixir has this (and is possibly the only non-homoiconic language to implement "true" macros) Opt-in typing, though. Regarding Elm, I love that runtime errors are considered compiler bugs.

Nim and Scala are not homoiconic, yet they both have true macros

Dylan?

Re: Notes on debugging Clojure code

#40
post #23

Earlier quoted context omitted.

You should definitely try, even if you end up being somewhat unsatisfied every time you have to use something else. When I write code in Haskell, it feels right, just like when I discovered Lisp. Only better. And oh, the purity! Not only in the mathematical sense, even the code is completely deprived of clutter.

But at what cost!? Every time I write Haskell code it reads like a mathematical proof that's beyond my ability to comprehend! Whereas my Ruby, Python, and Clojure programs read like a poem I might have written in third grade.

I don't think Haskell code looks like this. You don't have to use all the guru syntactic sugar; the library functions usually have pretty explicit names, and yours should have to.
Post reply on HN