Usable Live Programming
research.microsoft.com
Usable Live Programming
1–10 of 27 posts
Re: Usable Live Programming
#2I 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.
Re: Usable Live Programming
#3I 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).
Re: Usable Live Programming
#4Looks a lot like Apple's Playgroud for Swift.
Re: Usable Live Programming
#5I 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.
Re: Usable Live Programming
#6Looks a lot like Apple's Playgroud for Swift.
Playground wasn't that big in 2013.
Re: Usable Live Programming
#7Shameless 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
Re: Usable Live Programming
#8Earlier quoted context omitted.
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.
Re: Usable Live Programming
#9I 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…
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.
Re: Usable Live Programming
#10Misleading title.