[..] and every line of JavaScript code costs too much time to maintain.
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.
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.
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*.
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.
It's because with Haskell you find a ton of errors at compile time and Clojure finds most issues at runtime.
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.
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.
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!
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.
Chrome has some sort of support for it too, which Closure can apparently use. (That's Closure the JS library, not Clojure the JVM Lisp.)
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.