3 ms·

> Again if we go back to Hancock's thesis, it's all there! Yes, the problem is not with the definition of the term, but with the term "live programming" itself

by jules 14y ago

> Again if we go back to Hancock's thesis, it's all there! Yes, the problem is not with the definition of the term, but with the term "live programming" itself! It is too vague and can apply to too many concepts, and hence we're seeing people use it and interpret it for many different concepts. Nobody will go read a thesis to learn what a term means. But then again "object oriented programming" is vague as well. The notion of "steady frame" does seem oddly domain specific. In the words of that thesis: water hosing your way towards the correct floating point cutoff value or towards the value of a parameter in a formula that produces an aesthetically pleasing result works great, but I'm not convinced that you can "water hose" your way to a correct sorting algorithm for example. Perhaps I have misunderstood what he meant though. > A "best" effort with reset as a back up is more usable. Yeah, I agree. I think the same primitives that can be used for building good explicit state migration tools, like saving the entire state and recording input sequences or recording and replaying higher level internal program events, can also be used for building good custom live programming experiences. So they are not two entirely disjoint problems. > But maybe take a look at our UIST déjà Vu paper [1] That's very interesting and looks like an area where live programming can work particularly well! A meta toolkit for building such domain specific live programming environments may be very useful if live programming is to take off in the mainstream. Of course LightTable is trying to do some of that, but while it started out in a quite exciting way they seem to be going back to being a traditional editor more and more (albeit extensible). > One of the next problems I'm trying to solve is how to memoize between the frames of such programs to make the feedback more lively. Probably you've seen that already, but have you looked at self adjusting computation? http://www.umut-acar.org/self-adjusting-computation http://www.umut-acar.org/self-adjusting-computation

seanmcdirmid 14y ago
> Yes, the problem is not with the definition of the term, but with the term "live programming" itself! True. But I think the word has worked well until recently. > The notion of "steady frame" does seem oddly domain specific. Not really, but please wait for a better explanation until my next paper. One of Bret's examples in his IoP video is a correct sorting algorithm, actually, programmed with live feedback. I also mentioned a return to printf debugging on LtU before, and its basically the direction I'm taking right now (that the UI represented by the steady frame is probably not the GUI that is used be an end user). > Probably you've seen that already, but have you looked at self adjusting computation? http://www.umut-acar.org/self-adjusting-computation http://www.umut-acar.org/self-adjusting-computation Their work doesn't seem to scale yet (all examples seem to be small algorithmic functions) while I'm already writing complete programs, compilers even, with my own methods, which are based more on invalidate/recompute rather than computing exact repair functions. I'll be able to relate to this work better when they start dealing with bigger programs and state.
- jules 14y ago
  > True. But I think the word has worked well until recently. I just saw this: http://www.infoq.com/presentations/Live-Programming http://www.infoq.com/presentations/Live-Programming "Sam Aaron promotes the benefits of Live Programming using interactive editors, REPL sessions, real-time visuals and sound, live documentation and on-the-fly-compilation." :D > One of Bret's examples in his IoP video is a correct sorting algorithm, actually, programmed with live feedback. I also mentioned a return to printf debugging on LtU before, and its basically the direction I'm taking right now Yea, this interpretation of 'steady frame' is fully general I think: the ability to compare feedback of version n with feedback of version n+1 without getting lost. My interpretation was more specific because of the water hose vs bow and arrow analogy: continuously twiddling knobs until you get the result you want vs discrete aim-and-shoot. For example picking the color of a UI widget with a continuous slider vs entering the rgb value and reloading. Since a sorting algorithm is not a continuous quantity, aim-and-shoot is inevitable though you can still make it bit more "continuous" by making the aim-and-shoot cycle more rapid. > which are based more on invalidate/recompute rather than computing exact repair functions You can do this in their framework; you can specify at which granularity you want to have the 'repair functions' and at which granularity you just want to recompute. For example if you have a List<Changeable<T>> then each item in the list can be repaired independently, if you have Changeable<List<T>> the whole list will be recomputed. Although you probably want to automatically find the right granularity rather than force the user to specify it?
  - seanmcdirmid 14y ago
    > I just saw this: http://www.infoq.com/presentations/Live-Programming http://www.infoq.com/presentations/Live-Programming Ya, I saw it to. I didn't see the talk though, but I expect it to be more of the same promotion of live coding as somehow actually being live programming (programming is like playing music! Ya...). > Since a sorting algorithm is not a continuous quantity, aim-and-shoot is inevitable though you can still make it bit more "continuous" by making the aim-and-shoot cycle more rapid. A sorting algorithm can be fudged as a continuous function. But then here continuous means "continuous feedback", not "data with continuous values." The point is not that the code can be manipulated via knob, but that as I edit the code (usually with discrete keystrokes and edits), I can observe the results of those edits continuously. > You can do this in their framework; you can specify at which granularity you want to have the 'repair functions' and at which granularity you just want to recompute. I'll have to look at this work more closely, the fact that we need custom repair functions at all bother me (repair should just be defined simply as undo-replay). The granularity of memoization is an issue that has to be under programmer control, I think.
ibdknox 14y ago
> A meta toolkit for building such domain specific live programming environments may be very useful if live programming is to take off in the mainstream. That's exactly what we're trying to do with LT, see my "The Future is Specific" post [1]. > they seem to be going back to being a traditional editor more and more (albeit extensible) This is a necessary detour as we build a foundation that actually works and allows us to really make the more interesting stuff. If we can't even deal with files, what good are we going to be at dealing with the much more complicated scenario of groups of portions of files? :) [1]: http://www.chris-granger.com/2012/05/21/the-future-is-specific/ http://www.chris-granger.com/2012/05/21/the-future-is-specif...
- jules 14y ago
  That's great to hear! I really hope LightTable works out.

by jules 14y ago

seanmcdirmid 14y ago

> Yes, the problem is not with the definition of the term, but with the term "live programming" itself! True. But I think the word has worked well until recently. > The notion of "steady frame" does seem oddly domain specific. Not really, but please wait for a better explanation until my next paper. One of Bret's examples in his IoP video is a correct sorting algorithm, actually, programmed with live feedback. I also mentioned a return to printf debugging on LtU before, and its basically the direction I'm taking right now (that the UI represented by the steady frame is probably not the GUI that is used be an end user). > Probably you've seen that already, but have you looked at self adjusting computation? http://www.umut-acar.org/self-adjusting-computation http://www.umut-acar.org/self-adjusting-computation Their work doesn't seem to scale yet (all examples seem to be small algorithmic functions) while I'm already writing complete programs, compilers even, with my own methods, which are based more on invalidate/recompute rather than computing exact repair functions. I'll be able to relate to this work better when they start dealing with bigger programs and state.

jules 14y ago
> True. But I think the word has worked well until recently. I just saw this: http://www.infoq.com/presentations/Live-Programming http://www.infoq.com/presentations/Live-Programming "Sam Aaron promotes the benefits of Live Programming using interactive editors, REPL sessions, real-time visuals and sound, live documentation and on-the-fly-compilation." :D > One of Bret's examples in his IoP video is a correct sorting algorithm, actually, programmed with live feedback. I also mentioned a return to printf debugging on LtU before, and its basically the direction I'm taking right now Yea, this interpretation of 'steady frame' is fully general I think: the ability to compare feedback of version n with feedback of version n+1 without getting lost. My interpretation was more specific because of the water hose vs bow and arrow analogy: continuously twiddling knobs until you get the result you want vs discrete aim-and-shoot. For example picking the color of a UI widget with a continuous slider vs entering the rgb value and reloading. Since a sorting algorithm is not a continuous quantity, aim-and-shoot is inevitable though you can still make it bit more "continuous" by making the aim-and-shoot cycle more rapid. > which are based more on invalidate/recompute rather than computing exact repair functions You can do this in their framework; you can specify at which granularity you want to have the 'repair functions' and at which granularity you just want to recompute. For example if you have a List<Changeable<T>> then each item in the list can be repaired independently, if you have Changeable<List<T>> the whole list will be recomputed. Although you probably want to automatically find the right granularity rather than force the user to specify it?
- seanmcdirmid 14y ago
  > I just saw this: http://www.infoq.com/presentations/Live-Programming http://www.infoq.com/presentations/Live-Programming Ya, I saw it to. I didn't see the talk though, but I expect it to be more of the same promotion of live coding as somehow actually being live programming (programming is like playing music! Ya...). > Since a sorting algorithm is not a continuous quantity, aim-and-shoot is inevitable though you can still make it bit more "continuous" by making the aim-and-shoot cycle more rapid. A sorting algorithm can be fudged as a continuous function. But then here continuous means "continuous feedback", not "data with continuous values." The point is not that the code can be manipulated via knob, but that as I edit the code (usually with discrete keystrokes and edits), I can observe the results of those edits continuously. > You can do this in their framework; you can specify at which granularity you want to have the 'repair functions' and at which granularity you just want to recompute. I'll have to look at this work more closely, the fact that we need custom repair functions at all bother me (repair should just be defined simply as undo-replay). The granularity of memoization is an issue that has to be under programmer control, I think.

ibdknox 14y ago

> A meta toolkit for building such domain specific live programming environments may be very useful if live programming is to take off in the mainstream. That's exactly what we're trying to do with LT, see my "The Future is Specific" post [1]. > they seem to be going back to being a traditional editor more and more (albeit extensible) This is a necessary detour as we build a foundation that actually works and allows us to really make the more interesting stuff. If we can't even deal with files, what good are we going to be at dealing with the much more complicated scenario of groups of portions of files? :) [1]: http://www.chris-granger.com/2012/05/21/the-future-is-specific/ http://www.chris-granger.com/2012/05/21/the-future-is-specif...

jules 14y ago
That's great to hear! I really hope LightTable works out.