index.html

<!DOCTYPE html>
<html>
  <head>
    <!-- Global site tag (gtag.js) - Google Analytics -->
    <script async src="https://www.googletagmanager.com/gtag/js?id=G-6KQYQGCXMQ"></script>
    <script>
      window.dataLayer = window.dataLayer || [];
      function gtag(){dataLayer.push(arguments);}
      gtag('js', new Date());

      gtag('config', 'G-6KQYQGCXMQ');
    </script>

    <title>Elm Reader</title>
    <meta charset="UTF-8" />

    <link href="style.css" rel="stylesheet" />
  </head>
  <body>
    <!--
      <a href="https://github.com/elm-reader" id="fork-me"><img loading="lazy" width="149" height="149" src="https://github.blog/wp-content/uploads/2008/12/forkme_right_darkblue_121621.png?resize=149%2C149" class="attachment-full size-full" alt="Fork me on GitHub" data-recalc-dims="1"></a>
    -->
    <div class="heading">
      <header>The Elm Reader</header>
      <div class="topright">
        <!-- <a href="https://github.com/elm-reader" target="_blank"><img title="Elm Reader on GitHub" alt="Elm Reader on GitHub" height="60px" width="60px" src="https://avatars0.githubusercontent.com/u/39574638" /></a> -->
        <a href="https://github.com/elm-reader" target="_blank" title="Click me for the source code!">
          <!-- SVG from https://github.com -->
          <svg class="octicon octicon-mark-github v-align-middle" height="60px" viewBox="0 0 16 16" version="1.1" width="60px" aria-hidden="true"><path fill-rule="evenodd" d="M8 0C3.58 0 0 3.58 0 8c0 3.54 2.29 6.53 5.47 7.59.4.07.55-.17.55-.38 0-.19-.01-.82-.01-1.49-2.01.37-2.53-.49-2.69-.94-.09-.23-.48-.94-.82-1.13-.28-.15-.68-.52-.01-.53.63-.01 1.08.58 1.23.82.72 1.21 1.87.87 2.33.66.07-.52.28-.87.51-1.07-1.78-.2-3.64-.89-3.64-3.95 0-.87.31-1.59.82-2.15-.08-.2-.36-1.02.08-2.12 0 0 .67-.21 2.2.82.64-.18 1.32-.27 2-.27.68 0 1.36.09 2 .27 1.53-1.04 2.2-.82 2.2-.82.44 1.1.16 1.92.08 2.12.51.56.82 1.27.82 2.15 0 3.07-1.87 3.75-3.65 3.95.29.25.54.73.54 1.48 0 1.07-.01 1.93-.01 2.2 0 .21.15.46.55.38A8.013 8.013 0 0016 8c0-4.42-3.58-8-8-8z"></path></svg>
        </a>

      </div>
      <div class="subtitle">An exceptionally powerful debugging environment and learning tool</div>
    </div>

    <main>
      <p>
        The Elm Reader is an extension to the debugger of the <a href="https://elm-lang.org" target="_blank">Elm</a>
        programming language, built by
        <a href="https://github.com/WilsonBerkow" target="_blank">Wilson Berkow</a> and <a href="https://github.com/exists-forall" target="_blank">William Brandon</a>.
      </p>
      <p>
        Leveraging Elm's pure functional design, the Elm Reader
        allows <b>fine-grained time-traveling debugging:</b> exploration of every stack frame in the trace of a program,
        navigated as a lazily-evaluated tree. This means <b>stepping backward is as easy as stepping forward.</b>
      </p>

      <div class="paragraph video">
        <video id="dbg-video" src="assets/video.mp4" controls autoplay muted loop></video>
      </div>

      <h2>Try it</h2>

      <div class="paragraph">
        <ol>
          <li>
            Press <b>"Start"</b> in Conway's Game of Life to run the simulation (or edit the mosaic first).
          </li>
          <li>
            <b>In the gray sidebar,</b>
            see the messages (events) sent to the program by user interactions.
          </li>
          <li>
            <b>Click a message</b> in the gray sidebar to <b>pause</b> the program and <b>rewind</b> to when it was produced.
          </li>
          <li>
            <b>Navigate</b> through the code on the right to see how the next state of Conway's Game of Life was generated as a result of that message. <b>Click</b> on function calls to descend the stack, <b>hover</b> over expressions to see their values, and <b>double-click</b> expressions to pin them.
          </li>
          <li>
            Hit <b>"Resume"</b> to interact more with Conway's Game of Life
          </li>
        </ol>
      </div>
      <div id="try-it">
        <div id="elm-container">
          <center>Conway's Game of Life</center>
          <div id="elm"></div>
        </div>
        <div id="debugger-container">
          <center>Debug</center>
          <iframe id="debugger-window"></iframe>
        </div>
      </div>

      <h2>Context</h2>
      <p>
        Elm, a functional programming language for front-end software, ships with
        a debugging tool which allows the programmer to <b>view</b> the model (the state of the program)
        at any previous point in the execution of an Elm program. This is fantastic
        for finding <b>when</b> the model became bad or corrupted, but doesn't really help to
        identify <b>why</b> the model became corrupted, i.e. to see how the code
        generated a bad model. The Elm Reader fills this gap, and in doing so experiments with
        a whole new kind of debugger.
      </p>

      <p>
        In the demo and video above, everything in the debugging window with a <b>white
        background</b> is the Elm Reader. When rewinding the program to an event from the past, the Elm Reader not only
        shows
        the contents of the model when that event occured, but also allows the user to arbitrarily navigate
        the call to <code>update</code> which generated the next value of the model in response to the event. Opening
        a function call does not preclude you from going "back in time" to open a prior call from earlier in
        the program execution.
      </p>

      <p>
        The Elm Reader is <a href="https://github.com/elm-reader">open-source</a>,
        and we will open a PR to merge upstream later this year!
      </p>

      <h2>The Future</h2>
      <div class="paragraph">
        Fine-grained time-traveling debugging opens up design opportunities for all kinds of developer tooling.
        There is much more to be done!
        <ul>
          <li>
            <b>"Bookmarks" not "breakpoints" &mdash;</b>
            When using traditional debuggers, we often have to stop and think
            to decide whether to Continue to the next breakpoint. If
            we go too far, we'll miss the anomaly and have to start over.
            Time-traveling debugging radically changes this,
            allowing the developer to freely navigate
            between and around every "breakpoint" or "bookmark" in an execution, without loss of
            analytical power or performance.
          </li>
          <li>
            <b>Examples in documentation &mdash;</b>
            Examples in documentation can turbocharge onboarding. But they generally don't help
            you understand what's happening beneath the exact API used in the example.
            The Elm Reader is a way to improve the teaching potential of
            code examples by allowing dynamic exploration of how any invoked function works.
            Ultimately we learn by poking and experimenting, and time-traveling debugging makes
            it easy to explore a program execution with flexibility.
          </li>
          <li>
            <b>"Where did that state go wrong?" &mdash;</b> Often when debugging, one knows some
            state to be incorrect and the whole problem is to identify when and where that state
            was created. In the Elm Reader, we will experiment with adding a "find origin"
            tool to record a runtime ID for a value in a stack frame, re-run the
            tick in the program, and rewind to the stack frame which created that value.
          </li>
          <li>
            <b>Prefetching information &mdash;</b> The reader already "prefetches" the values of
            each expression in a stack frame for immediate inspection; it can do this because Elm is pure,
            so executing each of those expressions does not clobber state. A trivial extension of this idea would be to
            record the execution time of each invoked function, or collect other useful metrics,
            <b>while imposing trivial runtime cost</b> due to the lazy computation of trace information at runtime.
            The ability to <b>prefetch</b> information by executing code that the user has not yet reached
            opens up a wealth of design opportunities.
          </li>
        </ul>
      </div>

      <div style="height: 50px"></div>
    </main>

    <script src="assets/life.js"></script>
    <script type="text/javascript">
      Elm.Main.init({ node: document.getElementById("elm") });
      document.getElementById("debugger-corner").firstChild.click();
      setTimeout(function () { document.getElementById("debugger-corner").remove(); }, 300);
    </script>
  </body>
</html>