[elm-discuss] Source Maps? /was Elm Dev Tools

[Evan Czaplicki]

Based on Texas' post
<https://groups.google.com/forum/#!topic/elm-discuss/fZRGysggvdU>, I am
really curious to hear folks thoughts on source maps for my personal
planning and prioritization!

Last time source maps came up, I was choosing between "fix the type
checker" and "do source maps". Fixing inference in 0.9 (or whatever) was a
really really big deal and I think it was the right choice, but we never
revisited the source maps. It also does not fit into my workflow (which is
very atypical) so it's not something that I *personally* miss.

So essentially, how would source maps help you?

- Do you have times when you want them?
- Do you think it has a marketing / perception benefit that'd make it
worth it no matter what?

If you aren't a regular poster, I'm extra interested to hear your
perspective! I need to collect data and perspectives on this to prioritize
it.

[Zachary Kessin]

I would imagine that there are people who when looking at Elm would
notice the lack and not use it for that reason. They are quite useful in
some other compile to javascript languages like CoffeeScript or
ClojureScript etc

I have not don enough elm to know if they would be useful in practice

--Zach

Post by Evan Czaplicki
Based on Texas' post
<https://groups.google.com/forum/#%21topic/elm-discuss/fZRGysggvdU>, I
am really curious to hear folks thoughts on source maps for my
personal planning and prioritization!
Last time source maps came up, I was choosing between "fix the type
checker" and "do source maps". Fixing inference in 0.9 (or whatever)
was a really really big deal and I think it was the right choice, but
we never revisited the source maps. It also does not fit into my
workflow (which is very atypical) so it's not something that I
/personally/ miss.
So essentially, how would source maps help you?
* Do you have times when you want them?
* Do you think it has a marketing / perception benefit that'd make
it worth it no matter what?
If you aren't a regular poster, I'm extra interested to hear your
perspective! I need to collect data and perspectives on this to
prioritize it.
--
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
For more options, visit https://groups.google.com/d/optout.

--
Zachary Kessin
Mostly Erlang Podcast <http://mostlyerlang.com>
Skype: zachkessin
Twitter: @zkessin <http://twitter.com/zkessin>

[Hassan Hayat]

Rather than answer how source maps will help me, I prefer stating what I
sometimes need and have to work around, cuz this could be one of these
cases where some of the concerns could be addressed differently.

1) I'd like to insert a breakpoint in the middle of a function/expression.
Sometimes when updating component states I find myself in these nested
scenarios with lots of intermediate steps and functions in the middle and I
just want to know the state of all the variables at that time. While the
time travelling debugger is great, it only works between time frames. As
in, it can only capture time from the perspective of signals. It can't
capture time from the perspective of variables being set and functions
being called (think instruction-level if javascript statements were like
assembly instructions).

2) Sometimes there are runtime crashes even in the core library. These are
rare and are getting rarer by the day, but still, when one happens, I just
have a hard time navigating the code in Javascript. I'd like the ability to
see what line of Elm code crashed with what state (include <native> state)
and see the actual JS code side by side to be like "oh, it somehow remained
a string" or whatever.

2b) This happens especially with native modules. When making a native
module, you may not realize that some weird behavior may occur under weird
circumstances and, again, you'd like the Elm code, the JS code, and the
state side by side.

3) Performance hiccups can occur. Yeah, sure, sometimes the best way to
solve a performance hiccup is by changing algorithms or data structures.
But, other times, you just have a memory leak. And, how can you tell from
Elm code that you have a memory leak? All you get in the dev tools is that
there's some code running, and then GC pause, and then little memory gets
picked up. The other case of course is when you get tons of GC pauses. It's
hard to tell what causes them from Elm code, especially that we just state
data and an update function and make a Signal leap of faith and everything
magically works. It's hard to see from there where all the sawtooth waves
in the memory profiler come from.

Post by Evan Czaplicki
Based on Texas' post
<https://groups.google.com/forum/#!topic/elm-discuss/fZRGysggvdU>, I am
really curious to hear folks thoughts on source maps for my personal
planning and prioritization!
Last time source maps came up, I was choosing between "fix the type
checker" and "do source maps". Fixing inference in 0.9 (or whatever) was a
really really big deal and I think it was the right choice, but we never
revisited the source maps. It also does not fit into my workflow (which is
very atypical) so it's not something that I *personally* miss.
So essentially, how would source maps help you?
- Do you have times when you want them?
- Do you think it has a marketing / perception benefit that'd make it
worth it no matter what?
If you aren't a regular poster, I'm extra interested to hear your
perspective! I need to collect data and perspectives on this to prioritize
it.

[Texas Toland]

this could be one of Quoth the iPhone, "Evermore."

Extremely well presented. If Reactor captured state in between lines it could satisfy the first use case. My additional concern is isolating new Elm users from the existing body of de facto tooling used by migrating JS developers that already supports source maps including Chrome DevTools and IDEs like WebStorm. Would it be possible to eventually integrate with IntelliJ's debugging tools without source maps?

[Richard Feldman]

I'll phrase my thoughts as a response to Hassan's, but the tl;dr is that
source maps are a super low priority for me.

I had to literally pause and think about whether - assuming source maps
existed for Elm - I'd even bother spending the several minutes it would
take to enable source map generation in my build chain. My final thought
was "yeah I'd probably get around to it eventually." (And I say that as
someone who has spent hours building bleeding-edge versions of the Elm
compiler from source because he couldn't wait for the latest release to
come out.)

1) I'd like to insert a breakpoint in the middle of a function/expression.

Post by Hassan Hayat
Sometimes when updating component states I find myself in these nested
scenarios with lots of intermediate steps and functions in the middle and I
just want to know the state of all the variables at that time.

Whenever this comes up for me I just start sprinkling calls to Debug.log
around. Would being able to set breakpoints save me time in comparison? No
doubt! But the percentage of my Elm development time that I find myself
spending on this flavor of debugging is very small, so streamlining it
wouldn't move the needle much for me.

Post by Hassan Hayat
2) Sometimes there are runtime crashes even in the core library. These are
rare and are getting rarer by the day, but still, when one happens, I just
have a hard time navigating the code in Javascript. I'd like the ability to
see what line of Elm code crashed with what state (include <native> state)
and see the actual JS code side by side to be like "oh, it somehow remained
a string" or whatever.

Whoa, this has not been my experience at all. I still haven't gotten bitten
even once by this...I'm genuinely curious where this has been coming up!

2b) This happens especially with native modules. When making a native

Post by Hassan Hayat
module, you may not realize that some weird behavior may occur under weird
circumstances and, again, you'd like the Elm code, the JS code, and the
state side by side.

Ah, okay, that totally makes sense. I have not really gotten into Native
module development yet, but I can see how it would come up a lot more there.

Post by Hassan Hayat
3) Performance hiccups can occur. Yeah, sure, sometimes the best way to
solve a performance hiccup is by changing algorithms or data structures.
But, other times, you just have a memory leak. And, how can you tell from
Elm code that you have a memory leak? All you get in the dev tools is that
there's some code running, and then GC pause, and then little memory gets
picked up. The other case of course is when you get tons of GC pauses. It's
hard to tell what causes them from Elm code, especially that we just state
data and an update function and make a Signal leap of faith and everything
magically works. It's hard to see from there where all the sawtooth waves
in the memory profiler come from.

This is also something that hasn't come up for me personally (so far my Elm
perf hotspots have been trivial to identify without going into flame graph
land), but I can see it making my life easier at some point.

Having said that, my perception is that 99% of JS devs have never used
flame graphs to resolve an actual performance problem, so I'd be skeptical
of using that as a justification for prioritization. ;)

[Texas Toland]

Concretely source maps would make my tipping point from using Elm for academic experimentation to "making real stuff."

I want to:
inspect state in the call stack via breakpoints
without recompiling or necessarily refreshing
display Elm source in the browser
without switching contexts

Source maps enable:
breakpoints
with inconsistent reliability
without ability to selectively evaluate very dense functional expressions
variables pop-up assuming their names match (Closure optimization breaks it)
Elm source display
DevTools's Timeline hyperlinks to calls in source language
a potential DevTools extension could also link i.e. from a call hierarchy in Reactor
future IDE integration
breakpoints and call stack for free

As a consultant most code I encounter isn't mine, isn't good, and/or isn't remembered. Beyond debugging, these features would facilitate exploration. This discussion arose when I was trying to figure out why Elm docs <http://package.elm-lang.org/packages> wouldn't work in Dash <https://kapeli.com/dash>. Docs in Dash run in WebKit as file local. That sounds like a bad idea™ but Kapeli wasn't interested in implementing a local server. There was no error in the JS console yet there were also no docs and a generic message resulting from a Task <http://package.elm-lang.org/packages/elm-lang/core/2.1.0/Task> recovery callback <https://github.com/elm-lang/package.elm-lang.org/blob/master/frontend/Page/Module.elm#L48>. I even saw the successful JSON request in DevTools! I could Debug.Log but that feels like my old PHP days.

I think we agree source maps are not a question of if but when. Here are other benefits I foresee:
Literally every other compile-to-JS language <https://github.com/ryanseddon/source-map/wiki/Source-maps:-languages,-tools-and-other-info#languages-that-compile-to-javascript-and-support-source-map-generation> I've used (plus a few) supports source maps. Support seems to mark maturity. In fairness I used a few of these before they gained support but their source was very readable.
JavaScript platform developers use JavaScript tools. We can certainly improve upon them but why dictate Elm users not have access.
Our own custom tooling could enhance their usability. I'll have to detail that in my DevTools topic this weekend.

[Richard Feldman]

This is really interesting! Thanks for your perspective on this, Texas;
it's one I definitely haven't encountered until now. I'm curious about this
part:

Concretely source maps would make my tipping point from using Elm for

Post by Texas Toland
academic experimentation to "making real stuff."
1. inspect state in the call stack via breakpoints
- without recompiling or necessarily refreshing
2. display Elm source in the browser
- without switching contexts
You mentioned that you want these things to exist as a prerequisite for

diving in and Making Real Stuff with Elm.

What's interesting to me about this is that, having Made Real Stuff in Elm,
I've found that these things come up so infrequently (especially compared
to JS!) that investing a bunch of time improving them doesn't sound very
appealing.

It's not just the absence runtime exceptions; it's also that Elm's type
system and lack of side effects often make it trivial to narrow down the
set of potential culprits that I don't even need to inspect runtime state
to narrow it down the rest of the way. I'll think "that wasn't what I
expected; who could have possibly affected that value?" and glancing at the
source reveals that there are only a handful of functions that fit the
bill. At that point I think "oh, duh, I bet it was this one," and very
often I just change that function and the problem is fixed. This isn't how
it works out 100% of the time, of course, but it's common enough that in
Elm I rarely find myself inspecting state at runtime - again, especially
compared to JS.

I could be wrong, of course, but I would be surprised if you didn't find
the same thing if you took the plunge and tackled a project using existing
tooling.

Just something to consider. :)

[Texas Toland]

Evan shared your perspective. Pete sees both sides. It sounds like Hassan's experiences mirror mine. I think our debugging workflow is subjective akin to your averseness to IDEs while I don't "make real stuff" without one. (I actually love Scala in IntelliJ but maybe my project was smaller than yours.)

I neglected to mention our discussions around Reactor would fulfill my first use case even better than source maps. (I assume Pete will post in dev as implementation details become concrete.) But this brings me to the reason I'm pushing for source maps.

I love Elm because it's friendly. There's no stigma like Haskell and typeclasses. There's education surrounding programming paradigms that are just as old as the C family. That should be our position surrounding tooling. Not having source maps communicates that workflows universally adopted by "lay" developers are wrong. Instead of presenting an obstacle, why not participate in the wider JS ecosystem; then we can educate about progressive experiences like Reactor.

Looking forward to meeting you Wednesday!

[Richard Feldman]

Post by Texas Toland
I love Elm because it's friendly. There's no stigma like Haskell and
typeclasses. There's education surrounding programming paradigms that are
just as old as the C family. That should be our position surrounding
tooling. Not having source maps communicates that workflows universally
adopted by "lay" developers are wrong. Instead of presenting an obstacle,
why not participate in the wider JS ecosystem; then we can educate about
progressive experiences like Reactor.

Oh, I 100% agree! My concerns are only about prioritization; it's not that
I don't think Elm should have source maps, I just worry it's the wrong
thing to focus on right now. It seems like it would take a major effort but
wouldn't move the needle much on either new user adoption or productivity
for existing users.

To your point about appealing to existing JS developers, I've observed that
relatively cheap-to-implement syntax improvements like string interpolation
<https://github.com/elm-lang/elm-compiler/issues/905> and nicer list/record
syntax <https://github.com/elm-lang/elm-compiler/issues/978> have a strong
record of attracting JS programmers. Consider that CoffeeScript rose to the
11th-most popular language on GitHub just by introducing syntax niceties
(notably these two exact syntax features!) to JavaScript, without any real
semantic improvements whatsoever! This suggests that nicer syntax is valued
by the JS community much more than the Pure FP community, but of course
there's no reason we all couldn't benefit from them.

Looking forward to meeting you Wednesday!


Likewise! :D

If you want to get together sooner than that, hit me up on Twitter...happy
to grab lunch on Sunday or something.

[Igor Tur]

This post might be inappropriate. Click to display it.

[e***@scouten.com]

Waking up an old discussion here ...

I'm new to Elm and considering it for a new project.

I was surprised / disappointed to learn that code coverage is not yet
supported in Elm. Has there been any further consideration of support for
code coverage in Elm? The lack of coverage is not an absolute show-stopper
for me, but my experience with other languages has taught me to be far more
comfortable with data model code that is thoroughly tested.

(Like others in this thread, I am less concerned with unit test coverage
for view code.)

-Eric

Post by Igor Tur
- Source maps are required for Code Coverage (example
https://www.npmjs.com/package/istanbul-coverage-source-map)
- Code Coverage is required for integration into any enterprise
environment (it doesn't really open the door, but absence may close the
door)
Also something like elmLint would be required.
And then integration with SonarCube (or similar) systems - for source code
analysis, complexity and overall control of source code changes.
Thank you,
Igor

Post by Evan Czaplicki
Based on Texas' post
<https://groups.google.com/forum/#!topic/elm-discuss/fZRGysggvdU>, I am
really curious to hear folks thoughts on source maps for my personal
planning and prioritization!
Last time source maps came up, I was choosing between "fix the type
checker" and "do source maps". Fixing inference in 0.9 (or whatever) was a
really really big deal and I think it was the right choice, but we never
revisited the source maps. It also does not fit into my workflow (which is
very atypical) so it's not something that I *personally* miss.
So essentially, how would source maps help you?
- Do you have times when you want them?
- Do you think it has a marketing / perception benefit that'd make it
worth it no matter what?
If you aren't a regular poster, I'm extra interested to hear your
perspective! I need to collect data and perspectives on this to prioritize
it.

[Ethan Martin]

Came here to confirm that test coverage is desirable, and source maps make
that happen, along with other things.

[Martin Janiczek]

I'm working on code coverage tool, although not in the "source maps +
Istanbul" way:
https://groups.google.com/forum/#!topic/elm-dev/1tHjTG1z6EM

It currently lives on Github in Janiczek/elm-compiler
<https://github.com/Janiczek/elm-compiler/projects/1>.

https://github.com/Janiczek/elm-make/commit/1497add08e790bc10e004a7cbefb3f5e02527e92
https://github.com/Janiczek/elm-compiler/commit/303068059656e3e983d5d3f490739e220c2bef9e