What is debugging like?

[jedwards1211]

@nelsonic I know you said there are really good stack traces, but I'm also curious: how are the source maps? Is it easy to put a breakpoint in the Elm code and step through it in Chrome dev tools? I guess this would be my main concern with a non-JS based language. I've found it easy enough to read and set breakpoints in Babel-transpiled ES6 at least (since using full sourcemaps for production-scale apps is really slow on each recompile).

[nelsonic]

@jedwards1211 really good question! (thank you for asking it!) I think debugging is where elm-lang truly shines...! see: http://debug.elm-lang.org/

In fact if the elm debugger was available for JS/IE (let's face it Internet Explorer is still where most of our time consuming bugs are...!) it would make my life (debugging other people's code) so much better! But, the only way we can show the power of the elm debugging experience is with a video ...

For a micro-intro to "Elm Reactor" see: elm-reactor: a Time Travelling Debugger https://youtu.be/vS3yzUo7l8Y

If you want to have your mind blown watch "Code is the Easy Part" by @evancz where he demos the next iteration of the Elm debugger: https://youtu.be/DSjbTC-hvqQ?t=27m17s

[jedwards1211]

@nelsonic yeah if I remember correctly that was the inspiration for the redux dev tools, which do essentially the same thing, though in my experience with a complex app with a high volume of events, it was quite slow :(

And the time traveling debugger is great but it's only half of the battle; what's missing from that demo is putting breakpoints in the code and stepping through to see what went wrong when some action was mishandled.

[jedwards1211]

@nelsonic surprisingly Evan Czaplicki claims that few companies in production have much of a need for source maps so they aren't a priority right now. I don't yet understand what about Elm enables them to avoid using any source maps. I asked him about it in that thread.

[jedwards1211]

Googling for "elm breakpoints", I didn't find much. But I found a few posts on the google groups for Elm. One user summarizes my biggest reservation about using Elm in production-scale web apps:

Elm, as great as it is, doesn't save you from debugging every once in a while. The one option we have now, is logging. Logging is great, but it can quickly become painful in loops. Since Elm compiles to a single JS file with long mangled names, setting a breakpoint from the code would sometimes be the simplest way to properly debug your code. The generated JS isn't that hard to understand either, it's a series of vars and function calls for the most part.

[nelsonic]

@jedwards1211 thank you so much for digging into the debugging "story"... ❤️ ✅

[SimonLab]

It seems that more debugging tools will be available also on the next version of elm (0.18): https://youtu.be/DSjbTC-hvqQ?list=PLglJM3BYAMPH2zuz1nbKHQyeawE4SN0Cd&t=1633

[nelsonic]

@SimonLab yeah, v0.18 looks very promising from a Debugging (& "QA") perspective. 😉 I think @jedwards1211 was more focussed on the ability to use "break points" in the code and step through it: https://developers.google.com/web/tools/chrome-devtools/javascript/add-breakpoints But in my (probably naive) view writing smaller ("pure") functions and having a (really) smart compiler that looks for typos and type errors will go a long way toward improving the debugging story ... while this does not directly answer the question @jedwards1211 originally asked - and I think we should continue to ask it - I'm still optimistic ... 🌈

[nelsonic]

@jedwards1211 this might interest you: http://elm-lang.org/blog/the-perfect-bug-report 🤔

[jedwards1211]

Yes, importing/exporting history is very helpful and fortunately possible with Redux as well.

[nelsonic]

@jedwards1211, indeed, Dan Abramov did a great job of "porting" the elm debugger to Redux. 😉