> > Secondly, in my experience these sorts of bugs are rare. > When working on non-trivial applications I come across these kinds of bugs all of the time. Granted, that anecdote comes from developing AngularJS on a medium sized team.
You're right that the culprit usually is that the code is too complex, but writing complex code is not uncommon in my opinion and I think it'd be incorrect to think that complex code in Elm is impossible or rare. It might be harder to write complex code, but as the Elm community grows I suspect it'll become more common. Why don't we get a hard-to-debug, logically incorrect, compiling piece of > code and see what the best tools would be to address it? > I don't think I'll be able to create a SSCCE <http://sscce.org/>, with emphasis on the "short" part, because as you correctly say this kind of bug occurs in applications that are too complex. But I'll turn the question around. Which debugging tool best helps us understand *why* a particular function is executing with a particular set a values? Some options: - A time travel debugger, but that won't help me if I'm doing too much complex logic for a given Msg - Debugger statements in the compiled code feels workaround-ish but might help if the compiled code is translatable to Elm code in my head - Debug.log statements could help as long as I know ahead of time what to log Of those 3 I think Debug.log gets me the closest to understanding why a function is executing, but IMO it'd be a far better (shorter feedback loop) troubleshooting experience to be able to conditionally breakpoint in a function, inspect the values, and go back up the callstack to inspect other values to help me understand why the code is behaving like it is. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
