4 ms·

This would be a great demo to see running in a responsive programming environment, ala Bret Victor's amazing Inventing on Principle talk (http://vimeo.com/36579

This would be a great demo to see running in a responsive programming environment, ala Bret Victor's amazing Inventing on Principle talk (http://vimeo.com/36579366 http://vimeo.com/36579366). I want to be able to click on hex values and get a color picker that updates the demo in realtime, and be able to click on various magic numbers and drag a slider to change them. Incidentally, Bret Victor's talk was the starting point for Khan Academy's CS curriculum that John Resign led (http://ejohn.org/blog/introducing-khan-cs/ http://ejohn.org/blog/introducing-khan-cs/). Edit: I managed to get this running in livecoding.io, which does some of what Bret Victor was talking about (basic sliders and color pickers): http://livecoding.io/4191583 http://livecoding.io/4191583. Not sure why it's running so much slower though...

undergroundhero 14y ago
Thanks for the livecoding link. I assume there's some overhead in constantly checking for and applying code changes - that's probably the reason for the lower frame rate.
- scottyallen 14y ago
  Good point, I hadn't thought about the fact they might be polling for changes. Might be better if livecoding used an event based model to check for updates...
  - akx 14y ago
    Or if it works at all like Scrubby (http://nornagon.github.com/scrubby/ http://nornagon.github.com/scrubby/) which was on HN a couple days ago, it might rewrite all constants into global lookup table indexes, which surely wreaks havoc on performance.
  - dxq 14y ago
    How do you suppose event-based models are notified of changes? Ultimately you are still polling, you're just abstracting it out of your higher-level design.
- enjalot 14y ago
  it's not polling, its reevaluating code when codemirror triggers an event for text changing (which uses the dom underneath). the problem is from calling setInterval every time the code is evaluated, leading to way too many function calls/second
dsl 14y ago
This "responsive programming environment" you speak of has been around for a really long time. Don't expect sliders and colorpickers to do cool stuff, but this should be a good jumping off point for you to start learning from: http://stackoverflow.com/questions/3305164/how-to-modify-memory-contents-using-gdb http://stackoverflow.com/questions/3305164/how-to-modify-mem...
- scottyallen 14y ago
  Thanks, I'm plenty aware of gdb and debuggers:) (ex-google software engineer, etc etc) Go watch the video. Bret presents a very cogent vision for a dramatic improvement on most of today's standard engineering/design tools.
  - deangiberson 14y ago
    And here I'm going to point to Bret's later writing, http://worrydream.com/#!/LearnableProgramming http://worrydream.com/#!/LearnableProgramming. It's not about the sliders it's about the understanding. A good example is the first large loop setting up the texture. for ( var i = 1; i < 16; i++) { var br = 255 - ((Math.random() * 96) | 0); for ( var y = 0; y < 16 * 3; y++) { for ( var x = 0; x < 16; x++) { ... } } } If this was a first introduction to programming it would scare off many people. My interpretation of Bret's idea is that it would be better to have the ability to highlight the section of the texture being written by each section of the loop. It's not the sliders & live editing that are most important it's about linking abstract control into meaning within the learner.
    - chii 14y ago
      yes - that is also my interpretation - you mouse over the canvas, and the block of code that "lead" to the bit that you "highlight" in the canvas lights up so can directly navigate from the final output back to the source code (and vice versa).
enjalot 14y ago
Here is a version adapted for Tributary: http://tributary.io/inlet/4199801/ http://tributary.io/inlet/4199801/ Press play in the bottom left to have it go, and scrub numbers/colors to your hearts content! Part of the reason it slows down in livecoding is because of the way the original code uses setInterval, and every change reevaluates the code which polutes the scope and starts way too many threads going. I've added optional functionality to Tributary which gives you a run loop (using requestAnimationFrame) that doesn't polute anything. Hope this helps!
- scottyallen 14y ago
  Very awesome:) It's _almost_ fast enough to feel like you're modifying it in realtime on my macbook air. This is a great demo of what might be possible with this responsive programming approach.

undergroundhero 14y ago

Thanks for the livecoding link. I assume there's some overhead in constantly checking for and applying code changes - that's probably the reason for the lower frame rate.

scottyallen 14y ago
Good point, I hadn't thought about the fact they might be polling for changes. Might be better if livecoding used an event based model to check for updates...
- akx 14y ago
  Or if it works at all like Scrubby (http://nornagon.github.com/scrubby/ http://nornagon.github.com/scrubby/) which was on HN a couple days ago, it might rewrite all constants into global lookup table indexes, which surely wreaks havoc on performance.
- dxq 14y ago
  How do you suppose event-based models are notified of changes? Ultimately you are still polling, you're just abstracting it out of your higher-level design.
enjalot 14y ago
it's not polling, its reevaluating code when codemirror triggers an event for text changing (which uses the dom underneath). the problem is from calling setInterval every time the code is evaluated, leading to way too many function calls/second

dsl 14y ago

This "responsive programming environment" you speak of has been around for a really long time. Don't expect sliders and colorpickers to do cool stuff, but this should be a good jumping off point for you to start learning from: http://stackoverflow.com/questions/3305164/how-to-modify-memory-contents-using-gdb http://stackoverflow.com/questions/3305164/how-to-modify-mem...

scottyallen 14y ago
Thanks, I'm plenty aware of gdb and debuggers:) (ex-google software engineer, etc etc) Go watch the video. Bret presents a very cogent vision for a dramatic improvement on most of today's standard engineering/design tools.
- deangiberson 14y ago
  And here I'm going to point to Bret's later writing, http://worrydream.com/#!/LearnableProgramming http://worrydream.com/#!/LearnableProgramming. It's not about the sliders it's about the understanding. A good example is the first large loop setting up the texture. for ( var i = 1; i < 16; i++) { var br = 255 - ((Math.random() * 96) | 0); for ( var y = 0; y < 16 * 3; y++) { for ( var x = 0; x < 16; x++) { ... } } } If this was a first introduction to programming it would scare off many people. My interpretation of Bret's idea is that it would be better to have the ability to highlight the section of the texture being written by each section of the loop. It's not the sliders & live editing that are most important it's about linking abstract control into meaning within the learner.
  - chii 14y ago
    yes - that is also my interpretation - you mouse over the canvas, and the block of code that "lead" to the bit that you "highlight" in the canvas lights up so can directly navigate from the final output back to the source code (and vice versa).

enjalot 14y ago

Here is a version adapted for Tributary: http://tributary.io/inlet/4199801/ http://tributary.io/inlet/4199801/ Press play in the bottom left to have it go, and scrub numbers/colors to your hearts content! Part of the reason it slows down in livecoding is because of the way the original code uses setInterval, and every change reevaluates the code which polutes the scope and starts way too many threads going. I've added optional functionality to Tributary which gives you a run loop (using requestAnimationFrame) that doesn't polute anything. Hope this helps!

scottyallen 14y ago
Very awesome:) It's _almost_ fast enough to feel like you're modifying it in realtime on my macbook air. This is a great demo of what might be possible with this responsive programming approach.