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.
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.
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.
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.
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).
It seems they make the same mistake as the Khan Academy computer science editor [1] does. Bret says something about it in his learnable programming [2] post:
> 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.
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).
> 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.
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'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?)
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.
27 comments
[ 2.8 ms ] story [ 69.5 ms ] threadbeing able to change the parameters of animations/simulations and see the results in real time is pretty incredible.
Cheers
theres a difference between creating pixel perfect polished marketing sites and showcasing an evolving prototyping tool
[1]: http://khanacademy.org/cs
[2]: https://github.com/Khan/canvas-editor
> 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/
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).
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.
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'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?)
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).