Usable Live Programming | Hacker News Reader

Usable Live Programming

research.microsoft.com

82 pointsryanbrush25 comments

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 (contains an example you can run)

Demo video: http://vimeo.com/m/100010922

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.

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.

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

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

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

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

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

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

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

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

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

Great, thanks for the braindump!

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/

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.

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).

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.

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.

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

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.

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?

Check out Theseus from MIT / Adobe Research: http://blogs.adobe.com/open/behind-the-scenes-with-theseus-a...

Totally agree with you. What I would add to that list: A visualization of the memory space; ie. how often do objects get accessed, how much memory do they each require and how long do they reside in memory on average.

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

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.

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.

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).

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/

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.

Live programming isn't live coding. Live coding is about improvisation and repls. If you want to learn about live coding, see TOPLAP.

I got into a debate with well known Smalltalk guy about this once: my position was that we could achieve complete liveness, where even the past is repaired with respect to code changes, in a way that is responsive. His argument was that this kind of liveness is impossible, and that we should settle for just Smalltalk-style liveness (modify objects directly, fix-and-replace code without "repairing the past").

Self has also live coding features.

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

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.

reminds me of http://vimeo.com/36579366

Looks a lot like Apple's Playgroud for Swift.

Playground wasn't that big in 2013.

Reply on news.ycombinator.com