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.
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.
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.
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.
Paraphrasing a great programmer: "The best debugger is your brain". I have no issue with people using a debugger, but it is not a must in order to debug, imho.
I have found that this advice doesn't work too well when dealing with large, preferably legacy, codebases along with a pile of third-party libraries. Sometimes, the best debugger is a debugger.
A-men. Right now, I'm waist-deep in over 80k lines of JavaScript neither I nor anyone remaining on our team wrote, and just being able to set breakpoints on event listeners in Chrome and step into the functions that are fired probably saved me weeks off a more plodding read-through-the-whole-codebase approach.
I'm not sure how you'd create a language that would solve that problem, though I guess since the bug I was chasing down was a classic state problem, maybe it would have been caught by a compiler in Fay/Haskell.
The bigger problem I encountered trying it out yesterday was that it (at the moment) is fairly happy to generate an empty page and not give any compiler errors.
I assume that will change, but it made it pretty hard for me to get started with the language.
That said, I hope it changes, because Elm looks really neat!
Do source maps also support tracing values in variables, or do they only map line numbers in source to line numbers in output? Because the former (mapping values) is the hard part of implementing a debugger.
That's an interesting question. Debuggers are very different when they target functional languages and the mote you express with fewer lines of code make for somewhat surprising.
OTOH, the way one codes in functional languages is also different. Lack of a debugger may not he a problem as big as it would be with, say, Java.
No, its plain old lazyness. All these "compiled to JS" language makers would rather add more fancy syntactic sugar or extend the standard library than getting their goddamn bases covered.
I have no problem with that, but please don't go on about how you are much more productive in this language than in JS, and how much cheaper the code will be to maintain.
I think it's ridiculous to call people "lazy" who wrote an entirely new language from scratch and released it for free, because it's lacking one feature.
Per my sibling post, I do not believe you are technically correct. Debuggers must support the ability to debug compiled languages before anyone can usefully implement support for debugging. I'm curious what exactly you think the developers of languages that compile to JS are not doing out of "lazyness"?
At this point, go to the next blackboard. Write after me:
You can not debug Elm. There is no debugger. You can not debug Elm. There is no debugger.