

Usable Live Programming - ryanbrush
http://research.microsoft.com/en-us/people/smcdirm/liveprogramming.aspx?2

======
danabramov
Shameless plug: though unrelated to the article, for the past few days I've
been working on live reload for React components.

As you edit JSX files, after a small delay, components re-render in browser,
using React's diff algorithm to reconcile DOM. This means their state is not
destroyed. For example, you can live-edit a modal window without having to
refresh and open it again. You can change event handlers and debug a complex
component on the fly.

There are no browser plugins involved, it's all just JS. This is implemented
on top of Webpack, if you want to give it a try, check it out! (I assume
familiarity with Webpack, but I plan to write an explanatory blogpost later.)

I'm very excited about this because I think it's the future of front-end
development. It is possible thanks to React's separation of side-effects and
Webpack's powerful plugin system (loaders are essentially macros).

Project on Github: [https://github.com/gaearon/react-hot-
loader](https://github.com/gaearon/react-hot-loader) (contains an example you
can run)

Demo video: [http://vimeo.com/m/100010922](http://vimeo.com/m/100010922)

~~~
skrebbel
Thanks for this shameless plug! Webpack happens to be next on my list of
frontend builders to try (hoping that it's less bug-ridden than Browserify and
less hassle than Grunt or Gulp). If it works like it says on the tin, I'll
probably be an early adopter of your hot loader.

~~~
danabramov
Webpack is totally awesome. It's not as documented as I wish it was but @sokra
(Tobias) is an insanely clever person. A few months ago I dismissed it in
favor of Browserify, but after really getting to know Webpack, Browserify is
nowhere close.

~~~
skrebbel
Interesting. Why did you move over from Browserify? From a first glance, the
featureset seems comparable, and Browserify sure has more hype behind it.

~~~
danabramov
A lot of reasons actually.

* Webpack isn't religious and plays well with CommonJS, AMD, whatever. We almost didn't have to change the code when ported from RequireJS.

* Browserify's "all in one bundle" approach is precisely what we wanted to get away from, because our codebase grew like crazy. Webpack supports [code splitting][1] which allowed us to cut initial JS by half.

* As Pete Hunt said on some thread I can't find now, Browserify doesn't bring anything really new to the table. Webpack, on the other hand, brings "loaders" (first-class support for applying cacheable transformations as a build step for module). While they are not documented very well[2], they allow insane extensibility. They can be used for anything, from declarative code splitting with require() returning a promise[3], to compiling LESS[4], to bundling CSS as a JS dependency[5], to running JSHint[6].

* Hot Module Replacement gives each module an API to declare how it reacts to its dependencies being updated[7]. Loaders can use this API too, e.g. `style-loader` uses HMR to replace stylesheet without reloading the page[8], so you don't need to write extra code.

The biggest downside right now is the documentation being too technical. In
the long run though, I believe Webpack will get more popular once its docs are
improved, because it's just crazy powerful and extensible.

[1]: [https://github.com/webpack/docs/wiki/code-
splitting](https://github.com/webpack/docs/wiki/code-splitting)

[2]:
[https://github.com/webpack/webpack/issues/360](https://github.com/webpack/webpack/issues/360)

[3]: [https://github.com/gaearon/promise-
loader](https://github.com/gaearon/promise-loader)

[4]: [https://github.com/webpack/less-loader](https://github.com/webpack/less-
loader)

[5]: [https://www.npmjs.org/package/style-
loader](https://www.npmjs.org/package/style-loader)

[6]: [https://github.com/webpack/jshint-
loader](https://github.com/webpack/jshint-loader)

[7]: [http://webpack.github.io/docs/hot-module-replacement-with-
we...](http://webpack.github.io/docs/hot-module-replacement-with-webpack.html)

[8]: [https://github.com/webpack/docs/wiki/hot-module-
replacement](https://github.com/webpack/docs/wiki/hot-module-replacement)

~~~
skrebbel
Great, thanks for the braindump!

~~~
danabramov
Update: if you're interested, I blogged about how this works and how to
integrate live reload in your project: [http://gaearon.github.io/react-hot-
loader/](http://gaearon.github.io/react-hot-loader/)

------
asgard1024
I am not a big fan of "immediate feedback" in coding (such as instant
compilation). I find it distracting.

What I think I would appreciate more than "live" values of variables etc.
would be integration of some statistics into IDE. For example, how often was
this function called? What is the usual value of this parameter? What is the
mean/modus value? What are the outliers? How often was this condition true?
And so on.

~~~
seanmcdirmid
The immediate feedback is useless by itself (according to the essay); what is
useful is the ability to debug in real time.

What you want is some more advanced logging facility, which is completely
possible (e.g. Graphs over time in playground); I don't think logging should
be limited to just lines of text (an intern is working on log-driven relation
graphs).

~~~
asgard1024
I am not sure how is that going to scale for bigger programs. In simple cases,
I can model behavior of the program in my head, in more complicated cases,
without aggregation, there will be too much data to make sense of it anyway. I
think the aggregation of the statistical data is the crucial thing here.

Anyway, good that someone is playing with this.

~~~
seanmcdirmid
The point of the abstractions presented in the essay is that they are under
the programmer's control (write code to debug code isn't that new), so they
only see as much as they want to. This is in contrast to automatic methods
that show everything and are too noisy.

Scaling will perhaps come with time, by which I mean managed time. It is a
nice goal for next gen languages.

~~~
sitkack
What do you think of the work that Philip Guo [0] is doing? Specifically the
youtube video.

[0]
[https://news.ycombinator.com/item?id=8002839](https://news.ycombinator.com/item?id=8002839)

~~~
seanmcdirmid
Philip has more of an educational focus, so more is shown to help then
understand what is going on (also, see Bret Victor's Learnable Programming
Essay). The work presented in this essay deals with enhancing the debugging
experience for programmers who are already trained up.

------
mike_hearn
The Glitch paper was discussed previously on HN and is very interesting:

[http://research.microsoft.com/pubs/211297/managedtime.pdf](http://research.microsoft.com/pubs/211297/managedtime.pdf)

It's great research. Near term applicability would be more useful to me as an
IDE plugin that works with existing reactive frameworks. For instance, it
turns out that the latest Java UI framework (JavaFX) has a reactive/lazy
functional bindings framework in it. Every property of every UI widget can be
connected to other properties or derived expressions of those properties. Of
course Java itself has no support for this so it's all framework level stuff.
An IDE plugin / embeddable DSL that understood these constructs and allowed
for real-time debugging like in the videos would be useful indeed: whilst I
love binding UI widgets to the backend data model with that framework,
debugging it can be a total timesink.

~~~
seanmcdirmid
It is not easy, or,perhaps even possible, to take reactive programming model A
and combine it with reactive programming model B. E.g., the editor in this
demo is written in C#/WPF via Glitch, WPF supports data binding to recompile
expressions, but since this is what glitch is doing also (at a much more
general level), we can't use it with data binding.

You could have glitch for an existing language, but it would look more like
ReactJS for JavaScript.

------
sitkack
I love this stuff. I'd love a heat map superimposed over the code that
represents the range of the values and the likelihood or risks of sub
expressions overflowing or underflowing.

I'd like to capture the execution flow of a method, visualize it and then
watch those visualizations diverge from the old code to the new code.

The runtime could collect a minimal representative set of function invocations
and then use that in a visualization during the edit,debug cycle one could see
exactly how the new code diverges (kinda like having a column of inputs in a
spreadsheet).

------
kilon
Live coding is not a "new thing", both Smalltalk and Lisp , two of the oldest
programming languages are live coding languages. I am using a modern Smalltalk
implementation called Pharo.

[http://pharo.org/](http://pharo.org/)

When it comes to live coding, Pharo is "hardcore" , everything is live, direct
, accessible and easily modifiable. Pharo is based on Squeak , which is based
on Smalltalk-80 which is based on Smalltalk that means 45 years of live coding
experience condensed in beatiful language, IDE and evironment. Pharo can
already do all the things that the linked article tries to accomplish.

The end goal is provide a unified direct experience to the user, no delays, no
complexities just what you want to do with your code.

So to anyone whos really interested to live coding, try Pharo or some modern
implementation of Lisp. Even if you create your own live coding implementation
it will give you a good idea how great live coding can be.

~~~
sebastianconcpt
Self has also live coding features.

This is new for computer science in the same way the refrigerator is new for
storing food

~~~
seanmcdirmid
Neither Self nor Pharo have live programming features. The IDEs are live, the
code is dead. You can manipulate objects directly at run-time, but none of
that goes back into code.

It is time to move beyond Smalltalk and Self-style reduced liveness.

------
thikonom
reminds me of [http://vimeo.com/36579366](http://vimeo.com/36579366)

------
erokar
Looks a lot like Apple's Playgroud for Swift.

~~~
seanmcdirmid
Playground wasn't that big in 2013.

