What we've learned from a year of live coding(ejfox.github.com)
ejfox.github.com
What we've learned from a year of live coding
http://ejfox.github.com/happybirthdaytributary/
6 comments
That's right, and I hope that's where both Tributary and programming in general are headed. However, saying that they "make the same mistake" seems odd. Progress can happen incrementally, and sometimes you have to see what works and what not. It's almost as if you have to prototype your idea and see real results immediately, very similar to the goals of learnable programming.
You are right of course; the problem is that even though there have been people working on this problem since 2003, no one has communicated very well about the results outside of a few academic circles.
Hancock solves this problem with live text in Flogo II, but all we know about it is from his dissertation (http://llk.media.mit.edu/papers/ch-phd.pdf). I observed the same phenomena when I did my Sueperglue work back in 2007 (http://research.microsoft.com/apps/pubs/default.aspx?id=1793...), but I never really bothered to follow up until now (with inspiration from Bret's work, of course).
Hancock solves this problem with live text in Flogo II, but all we know about it is from his dissertation (http://llk.media.mit.edu/papers/ch-phd.pdf). I observed the same phenomena when I did my Sueperglue work back in 2007 (http://research.microsoft.com/apps/pubs/default.aspx?id=1793...), but I never really bothered to follow up until now (with inspiration from Bret's work, of course).
Seriously, the ability to "step through" a program is HUGELY helpful for learning what programming does. I remember learning the beginnings of programming in Visual Basic for Applications inside Excel 2003. The best feature was the ability to "walk through" the program, with a yellow line highlighting the current code being executed and a window that showed all the variables and their outputs in a highly readable format. Those two things really helped me as a kid learn what programming looked like.
It is both a very nice start, and there is definitely lots of room for improvement.
I'm working in this very area too.
One other thing I can add is that, IMO, it's very valuable to be able to easily execute a subset of the entire program (the tool should do everything it can to make the process easy, you just supply the necessary inputs).
I'm working in this very area too.
One other thing I can add is that, IMO, it's very valuable to be able to easily execute a subset of the entire program (the tool should do everything it can to make the process easy, you just supply the necessary inputs).
> One other thing I can add is that, IMO, it's very valuable to be able to easily execute a subset of the entire program
Sounds sort of like Bracha's stance.
I think we should just focus on making the feedback better over an entire program execution. And we could make defining unit tests easy, which would provide the context needed to test smaller parts of the program.
Sounds sort of like Bracha's stance.
I think we should just focus on making the feedback better over an entire program execution. And we could make defining unit tests easy, which would provide the context needed to test smaller parts of the program.
Could you please link me to what you mean by Bracha's stance?
I think making feedback better over the entire program execution is hard when dealing with immensely large projects. But breaking down those huge projects into smaller pure components with well defined dependencies might stand a better chance. I don't know for sure yet, but I'm gonna try and find out.
I think making feedback better over the entire program execution is hard when dealing with immensely large projects. But breaking down those huge projects into smaller pure components with well defined dependencies might stand a better chance. I don't know for sure yet, but I'm gonna try and find out.
I just saw him speak about it at a meeting we had recently. He also has something about this on his blog (http://gbracha.blogspot.com/2012/11/debug-mode-is-only-mode....), though I don't think he says anything about that there.
I'm trying to write a paper about this right now for Onward, but I think its possible to do large programs with the right amount of incrementalization within. There is definitely a limit though (if the change influences a lot of stuff, there isn't much we can do right?)
I'm trying to write a paper about this right now for Onward, but I think its possible to do large programs with the right amount of incrementalization within. There is definitely a limit though (if the change influences a lot of stuff, there isn't much we can do right?)
Thanks, that was an excellent read.
i'm wondering if we can first explictly state the objective by which this is being judged, mistakes or successes assigned
What is the goal and how effective is the technique in realizing the goal. Bret's work is nice because he so clearly articulates the goal.
as a designer (not a coder as much), tributary helps me realize my concepts quicker by helping with some of the technical stuff like automagically linking csv and json files. my go-to workflow is finding a d3.js example (e.g. from bostock's blocks http://bost.ocks.org/mike/ ) that has some components in common with what i want to accomplish, and then hacking/repurposing it to get what i need. sharing my tributary inlets makes it super easy to get feedback on what im doing wrong, and changing variables with sliders is now difficult to live without.
being able to change the parameters of animations/simulations and see the results in real time is pretty incredible.
being able to change the parameters of animations/simulations and see the results in real time is pretty incredible.
Very cool, reminds me of the interactive widget used in the Khan Academy CS program [1]. I believe John Resig [2] developed it.
[1]: http://khanacademy.org/cs
[2]: https://github.com/Khan/canvas-editor
[1]: http://khanacademy.org/cs
[2]: https://github.com/Khan/canvas-editor
Wow, I just played with the basic example, and being able to "slide" an integer in my code and watch the visualization update in realtime is pretty interesting! Looking forward to playing with this, nice work.
This is pretty amazing.
Granted, I'm friends with the authors (@enjalot, @mrejfox), but Tributary has easily become one of my most used tools on a daily basis.
Definitely cool, but must the page be so ugly?
This is pretty subjective, or?
I personally find it very good. You should learn to give feedback and not complain.
What would you improve? Always looking for useful feedback!
Cheers
Cheers
The embedded font renders very poorly in Windows. The page lags a ton while scrolling. Some of the demos linked freeze my browser for several minutes if I click on them. In Opera none of the examples work (no output at all).
I'm not the op, but I dislike the font and the colorful background (header).
Makes sense to me. Lightened up the background a bit- any better? https://github.com/ejfox/happybirthdaytributary/commit/dc189...
That's better, but I would probably still extend the solid-color background to the top of the page, so the background doesn't clash with the text at all.
I think it looks quite nice. I was looking for more about what you'd actually learned, rather than a list of projects though.
i think some people may not get that the header itself is a tributary math example ... link it up? ;)
theres a difference between creating pixel perfect polished marketing sites and showcasing an evolving prototyping tool
theres a difference between creating pixel perfect polished marketing sites and showcasing an evolving prototyping tool
> The programming environment exhibits the same ruthless abbreviation as this hypothetical cooking show. We see code on the left and a result on the right, but it's the steps in between which matter most. The computer traces a path through the code, looping around loops and calling into functions, updating variables and incrementally building up the output. We see none of this.
I mean, this is a nice start, but we still have lots of work to do before we really understand what we are doing in this area.
[1] http://ejohn.org/blog/introducing-khan-cs/
[2] http://worrydream.com/LearnableProgramming/