Hacker News new | ask | show | jobs
by icarus127 4773 days ago
I haven't written any Elm but having written some Haskell I can say it's surprising how often you _don't_ need a debugger in a functional language. I doubt Elm not having a debugger is as difficult as, for instance, Javascript or Coffeescript not having a debugger would be.
2 comments

> it's surprising how often you _don't_ need a debugger in a _functional language_

I disagree. That may be true in Haskell because it's static and the compiler finds a lot of problems.

This isn't true for all functional languages though. I REALLY want a debugger in Clojure code and it's pretty functional*.

Clojure is a great language, but there really is a difference between functional and "pretty" functional; e.g. as in, I know 100% sure that this function has no side-effects.

Static typing can do a lot of good, but the stricter semantics of Haskell also goes a long way into writing code with fewer bugs.

Nobody can agree on the definition of a functional language. AFAIK, so-called "functional" languages like F# or O-Camel allow arbitrary side effects, unlike Haskell.
That's why you'd call Haskell a 'purely functional' language.
Any function changes the state of your machine, and you have to pretend your computer doesn't have memory or registers in order for this pure function side effect free stuff to make sense. When you said "know 100%" my ability to accept abstractions like that turned off.
IMO, that has nothing to do with it. Especially because you often do know 100% that this function has no side-effects.

It's because with Haskell you find a ton of errors at compile time and Clojure finds most issues at runtime.

bah side effects what useful thing can you do without side effects? The only way to have no side effects is to frame the problem in a certain way.
Haskell has support for side-effects. It's just able to state the property that something is a 100% pure function, and also makes it very easy to write such code a lot of the time.
Unfortunately, I don't have the opportunity to be paid to write Haskell. Which means I haven't had the opportunity to use it for anything else than side projects.

However, there is one thing you want a debugger for in Haskell: checking when thunks have been forced.

Also, the type system can catch much more issues than "normal" compiled languages, not to mention the safety of immutable values. But there still numerous classes of issues which will not be caught by the type system. And of course, you have exceptions. Even if your code catches them, figuring out what triggered the exception can be tricky.