Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Usable Live Programming

research.microsoft.com

Post reply on HN
Print view View original

11–20 of 27 posts

Re: Usable Live Programming

#11

Post by mike_hearn »

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.

Re: Usable Live Programming

#12

Post by seanmcdirmid »

mike_hearn wrote: post #11

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…

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.

Re: Usable Live Programming

#13

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

Re: Usable Live Programming

#14

Post by sitkack »

seanmcdirmid wrote: post #8
asgard1024 wrote: post #5

Earlier quoted context omitted.

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

Re: Usable Live Programming

#15

Post by pgbovine »

asgard1024 wrote: post #2

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…

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

Re: Usable Live Programming

#17

Post by skrebbel »

danabramov wrote: post #7

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 debu…

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.

Re: Usable Live Programming

#18

Post by seanmcdirmid »

sitkack wrote: post #14
seanmcdirmid wrote: post #8

Earlier quoted context omitted.

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.

Re: Usable Live Programming

#19

Post by danabramov »

skrebbel wrote: post #17
danabramov wrote: post #7

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 debu…

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.

Re: Usable Live Programming

#20

Post by 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/

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.

Post reply on HN