9 ms·

Working Toward Bret Victor's “Learnable Programming”

206 points by Permit 11y ago

huuu 11y ago
Currently Alive offers two licenses: Individual and Enterprise. I searched the site but I can't find any information. Does anyone know the difference?
- macmac 11y ago
  I don't see much guidance either. It appears from the brief guidance text ("Purchase a license for yourself" vs "Purchase a license for others." that "Individual" is for personal use, and "Enterprise" for use within a legal entity employing multiple individuals - but I am grasping for straws here.
- Permit 11y ago
  Individual is if you're purchasing for yourself. (You can use it at work if you'd like). Enterprise is if you're purchasing multiple licenses (ie. licenses for employees).
  - dkersten 11y ago
    Going by the wording on a similar licensing structure for another programming tool: Individual allows you to use the tool commercially and you (the individual) owns the license Enterprise allows you to use the tool commercially and your employer (the enterprise) owns the license
hellofunk 11y ago
Article suggests that only Alive and Light Table provide this form of programming interaction. However, many (certainly not all) of the features in this article are a part of the Swift Playgrounds in recent iterations of Xcode, which were probably inspired by this work. Just worth pointing out. Update: I missed the part further down in the article where the Playgrounds were indeed mentioned. Whoops.
- seanmcdirmid 11y ago
  Here is a fascinating thesis written in 2003 on live programming: https://llk.media.mit.edu/papers/ch-phd.pdf https://llk.media.mit.edu/papers/ch-phd.pdf The ideas are quite old, much older than Bret Victor's work.
  - Permit 11y ago
    >The ideas are quite old, much older than Bret Victor's work. Absolutely. Your work in particular predates Bret's and I've enjoyed reading it and hope it catches on and inspires more folks at Microsoft and Microsoft Research! :) I think what makes Bret's work a little different than the linked work is that Bret's work managed to escape academia and appeal to an audience that might not have otherwise been exposed to these ideas in the first place.
    - pjmlp 11y ago
      It is great that Bret's work made the ideas more mainstream, but on my research for Xerox PARC's work I would say the ideas go back at very least to the interactive coding available on Smalltalk, Interlisp-D and Mesa/Cedar. Interactive coding is with us since the early 80's, the ideas just failed to go mainstream.
      - seanmcdirmid 11y ago
        Live programming goes way beyond smalltalk fix and continue, morphic directness, or a LISP REPL. We've caught up to that past, it is now time to go further. And of course, no one is really quite sure what the lisp machines ever did really, it's not like they have a video on YouTube :) It is better to have that argument with Gilad Bracha, I guess.
        pjmlp 11y ago
        Actually there are a few videos. :) But I guess all fail short how they really were. http://www.loper-os.org/?cat=10 http://www.loper-os.org/?cat=10 http://www.loper-os.org/?p=932 http://www.loper-os.org/?p=932 https://www.youtube.com/watch?v=o4-YnLpLgtk https://www.youtube.com/watch?v=o4-YnLpLgtk
jasode 11y ago
I may understate Bret Victor's thesis and may overstate Josh Varty's counterargument but I believe JV's criticisms are not applicable to BV's particular essay. Some key quotes from each for context: >Bret Victor: "How do we get people to understand programming?"[1] >Josh Varty: "Problems getting to Learnable Programming [...] However, we need to stop and think deeply about how this system would handle typical code. How do we generalize this solution such that it helps programmers building compiler platforms like LLVM and Roslyn? How will it help programmers researching neural networks? How will it help programmers writing line of business applications? Databases? Apps? Financial backends? The vast majority of functions in today's codebases do not map nicely to a 2D output." I see BV's essay focused on learning programming for people unfamiliar with programming. For non-programmers, even simple syntax such as "x=0; x=x+1" looks strange and beginners can't hold in their head what it does. So instead trying to teach beginners the LOGO programming language to move turtles around on the screen or BASIC language of "10 PRINT "HELLO" \n 20 GOTO 10", Brett shows a visualization where code syntax update its 2d output in a realtime feedback loop. This can help novices make the leap from abstract syntax in a text editor to the concrete changes in the output. Josh Varty is going beyond the scope of newbies learning programming concepts. He's trying to generalize it to working practitioners who already understand programming and make the "Learnable Programming Model" work for any arbitrary code to any type of visualization (beyond 2D if necessary). The "live coding for everything" is an interesting concept to pursue but I don't believe Brett's essay had this wide of a scope. I don't believe working programmers who have already mastered how "programming syntax maps to changing machine state" needs visualizations for every line of source code. However, JV's generalized scope is applicable for working programmers to verify code for correctness and do sanity checks on what they think the code is doing.[2] However JV's ideas are not necessary for working programmers to understand programming. In one case, JV uses this as example: var result = DoTaxes(person); The professional programmer (not the "learning programmer") doesn't need a clever realtime visualization to "understand" DoTaxes() in the BV sense. The programmer already has some idea that it probably has some code that performs multiplication and addition. Possibly even a lookup table for different countries or taxing authorities. The realtime visualization would help the professional programmer verify what the code actually does. Since realtime isn't available today, programmers get by with watch windows in visual debuggers, or manually insert printf()/console.log() statements. However, the programmer doesn't need BV visualizations to grok the compsci topics of the changing machine state inside DoTaxes(). tldr: BV and JV are tackling 2 different issues. [1]http://worrydream.com/LearnableProgramming/ http://worrydream.com/LearnableProgramming/ [2]See how JV's ALIVE demo visualization serves a different cognitive function from BV's. Those little red annotations are helpful for professional programmers to verify behaviors but not for beginners to grok compsci: https://embed.gyazo.com/4dc7ac656863cbd02a8e213598f85a4f.gif https://embed.gyazo.com/4dc7ac656863cbd02a8e213598f85a4f.gif
Buetol 11y ago
But most things we see are 2D outputs (webpages, world if you close one eye, text console,..). I think the closer we are to the bret Victor's ideal (of seeing what you do directly) is this: https://www.youtube.com/watch?v=xsSnOQynTHs https://www.youtube.com/watch?v=xsSnOQynTHs (react-hot-loader + redux). And this is already practical. Another nice tool who's the near his ideal is the chrome dev console: visual interaction, live edit, start/stop debugging,.. The future is bright.
- orodley 11y ago
  But the amount of code that deals directly with producing such output is usually very low, as a proportion of the total amount of code in the system. Having a pane on the right say '825' next to the 'printf("%d\n", do_the_actual_work(foo, bar));' in my code isn't useful. I already get that from the terminal. The place where the benefit would actually appear is visualizing the parts of the code that are doing the complex and error-prone tasks in the system. If you're a frontend web developer, then sure, it could be useful for you. But with the kind of stuff I do personally, the 2D output demonstrated in the article is irrelevant. Most stuff is much more abstract, and has zero relationship to direct production of visual output. It looks cool and all, but ultimately I feel like it's focusing on the easy problem rather than the important one. There are a few examples in there of visualizing the values in a for loop over time, but again, I feel like this is unrealistic. The proportion of my code that only executes for a fixed number of iterations that is easily determined at compile-time is negligible. As is iteration over a fixed, compile-time set of values. Most code lives inside functions that can be called with different combinations of parameters, interspersed with multiple nested loops and conditionals at different levels in the call stack, etc. Visualizing something like that in a useful way is much more difficult. If they can show an example of that, I'd be very interested. Until then, it seems more like a toy. A very interesting, promising toy, but still a toy. The unit test example gets a bit closer, but it's still just dealing with the output of all the code that actually does the work, not the details of that code itself. A tool like this should be helping you with the hard tasks rather than the easy ones, because the easy ones are already, well, easy. I'm not trying to be hostile, it certainly looks cool, and it looks like it could potentially be very useful in the future. It's just that currently it doesn't look like it would have any practical utility for me.
dkersten 11y ago
How do we generalize this solution such that it helps programmers building compiler platforms like LLVM and Roslyn? How will it help programmers researching neural networks? How will it help programmers writing line of business applications? Databases? Apps? Financial backends? In many (but certainly not all) of these domains, we already visualise (parts of) them in 2D (as charts), so I see no reason why this wouldn't apply here too. In my opinion, its not so important to solve the issue for every problem domain one might program in, but rather to do so for as many as are applicable. Just because a tool doesn't help with X, doesn't mean its a failure if it improves on Y.
krosaen 11y ago
Nice. I think a mention of figwheel / devcards would have been worthwhile: http://rigsomelight.com/2014/06/03/devcards-taking-interactivity-to-the-next-level.html http://rigsomelight.com/2014/06/03/devcards-taking-interacti...
- ch4s3 11y ago
  very cool. I'm constantly jealous of what you folks have in clojure land.
phantarch 11y ago
Personally, I would be wary of any IDE that attempted to interpret what my code is doing for me. Each person probably has a different mental image or interpretation of how their code works, and enforcing a singular interpretation of code via IDE might only enable people to 'learn' how to program within that environment. Teach a man to fish.
- seanmcdirmid 11y ago
  You have a computer right in front of you, why not use it to figure out what your code is doing rather than do the mental gymnastics in your head! This reminds of a story, I think it was dijkstra or maybe Knuth, who was lamenting that their students were being too sloppy because they got to program on interactive terminals and not the punch cards of yesterday. Programming without an IDE is the same...it's using punchcards when something much better is available.
  - brianshaler 11y ago
    The same could be said about other types of abstractions, such as using a compiler versus assembly. In the vast majority of circumstances, developers get far more accomplished using higher level abstractions and frameworks. In very extreme circumstances, portions of an application may need to be rewritten at a lower level for optimizations, but that doesn't negate the value provided by abstractions that allow the developer to be more productive expressing higher level concepts while the computer handles the tedium of how those concepts are translated into machine code.
    - phantarch 11y ago
      I think the difference here is that in the movement towards 'smart' IDE's, they attempt to go beyond the purely semantic meaning of the code and deduce what the interpreted meaning of it is. I'm all for what is in this article as far as it pertains to more interpretations of the semantic meaning.
  - jrbrtsn 11y ago
    Kernel developers don't use and IDE for the Linux kernel, and they are arguably some of the best programmers in the world. Great programmers use vim or emacs, because the imagery in their mind is far more powerful than anything an IDE could display. Besides, any screen real estate used for "interpretive" purposes is just an annoyance.
swah 11y ago
I think many game developers build those tools into their games, like Eskil's Love (https://en.wikipedia.org/wiki/Love_(video_game) https://en.wikipedia.org/wiki/Love_(video_game) tools.
- amadeusw 11y ago
  A few years ago (2012) I was taken aback by the Unreal Engine development process. Their IDE features a running game with all elements being selectable and interactively editable. In one video fragment [1] they hop to Visual Studio where they change gravity. After a few seconds of compilation, the game's code is updated. [1] https://youtu.be/MOvfn1p92_8?t=9m46s https://youtu.be/MOvfn1p92_8?t=9m46s
- corysama 11y ago
  His presi about designing the tools to make an MMO as a solo dev is definitely worth watching. https://vimeo.com/6010060 https://vimeo.com/6010060
  - swah 11y ago
    That's what I'm talking about, great video. I wish Love had gotten more love. (To be honest I didn't enjoy playing it, but I also don't enjoy Minecraft, and this one I love the aesthetics).
stillsut 11y ago
Attempts like these might be barking up the wrong tree. People who are going to be successful in bootstrapping themselves from 0 to dev are going to naturally grasp logic, state, or any other general programming concept. (Not master, but grasp). What people need is a real problem they can solve with programming: automate an office process, build a website, crunch some numbers, etc. And this is usually best done on a stack that has solutions for these problems. That's why "the future" of learning to program looks more like this: http://automatetheboringstuff.com/ http://automatetheboringstuff.com/ than a noob-IDE.
- romaniv 11y ago
  I don't think it's about bootstrapping to dev. I think it's about allowing people to solve certain problems using programming, but in a different way from what we're used to. It's about visualizing explorative programming. That's the way I understand it.
- ThomPete 11y ago
  Thats not the point of what Bret has been trying to advocate IMO. Instead he is trying to establish better frameworks for thinking about programming by providing a better feedback loop.
  - seiji 11y ago
    Smalltalk was the pinnacle of programatic pedagogy. Hypercard was the easiest way for regular humans to use computers for computer-like automations. But, then you run into the "No Real Programmer" problem. The nerds take over, hyper-complicate everything, then we're back to nobody understanding anything. (Also see: "No Real Unix User" when people say "Well, I don't consider OS X users to be unix users.")
    - jowiar 11y ago
      The other major tool I'd put up there with Smalltalk and Hypercard is Excel, at least when it comes to automation of real-world business problems. To an extent, it made a large enough set of problems easy enough to solve that tools have stagnated as a result.
RogerL 11y ago
I urge the people working on this to recognize that we all don't think the same. (I know, you don't claim that we do, but I don't see these counter points expressed often). I can't explain how I think, but it isn't visual, and doesn't seem to involve language much. Probably the closest is to say I think in math and geometry. That doesn't make any descriptive sense, but it is what I experience. I fell deeply in love with math, and then programming. A few words and control structures, and you have Turing completeness! It's as beautiful as language. Minimizing expression is sometimes far more powerful than unconstrained expression. I can hold these structures in my head, and so can most programmers that I know. Pictures are a pale, weak thing in comparison. "The Illustrated Guide to Kant's Critique of Pure Reason" has never been published (SFAIK), and for good reason. The simplest rules of grammar allows us to generate and express extremely complicated and nuanced ideas. Ya, sure, we could make a nice chart of synthetic/analytic and a priori/posterior, and I think Kant did that, but beyond that what do pictures get you? I bet there are visual thinkers reading this that have rebuttals or examples, and that is great. Einstein was a great admirer of Kant, and was a visual thinker, so I imagine him raising objections! But I think in the end the visualizations may have illustrate power, but rarely investigative power. Einstein put the lie to that with his work in Relativity, but he was an extraordinarily unique thinker (he did his work visually, and then struggled to get the math to prove his ideas). Anyway, my somewhat inarticulate argument is that programming languages was the great invention. Anything that is Turing complete lets us express anything computable. I think if you can find ways to complement that it will be a great contribution to knowledge. But I don't think you can replace or improve upon a Turing complete language (unsupported assertion requires citation here!). It would be great to be proven wrong. I use computer languages to do math, computer vision, and AI type stuff. Others uses it for different things. It all works. There is no universal visual paradigm to replace it. Engineering is optimization in multi-dimensions. Visualization limits us to 2 or imperfectly, 3 dimensions. So you can sort of slice out representations of this large, multidimensional space, but you are now working like the blind men on the elephant. You'll never get the complete 'picture'. You are just sort of poking at it with a stick. Whereas with a couple of equations I can describe the entire space AND now have powerful tools to explore that space, describe it, and determine its properties. I think back to one of Bret's videos where he uses a live environment to compute the trajectory for a character in a video game. In math that is known as the 'shooting method'. It kind of works, for some problems. There is also a universe of problems for which it doesn't work. How can you even tell if it works or not visually? The language of math gives us that tool. I love pictures, and produce charts all the time for my math code. But they do not replace the math, they illustrate it. I do my work in math, and in state, and in sw architecture, and sometimes use visual tools to help check the work. There is no language of visualizations, and without one you will either be illustrating the work of math and computer languages (which is not a bad thing, I'll happily use the tools when appropriate) or severely limiting what we can do. I don't work or think in 2D or 3D space and cannot be limited to such a restricted view (pun intended). I work in small spaces usually (R^18 or so) and visualization is a non-starter except as a great way to learn some of the concepts. I know plenty of you work in far larger spaces. tl;dr: the amazing advance was Turing complete languages; visualizations are not Turing complete; languages are powerful, visualizations do not have a language and hence aren't analyzable unless your name is Einstein.
erokar 11y ago
I think Elm makes good strides toward this goal: http://debug.elm-lang.org/ http://debug.elm-lang.org/
- Permit 11y ago
  I regret neglecting to mention Elm in the original article. I've only played around with their tooling, but it looks really awesome. It's probably even more in the spirit of Bret's original article as they've gone beyond designing tooling and also designed their own language.
solomatov 11y ago
It looks impressive, but only in these superficial simple examples. If we have really complex problem, i.e., designing distributed algorithm, we need to create domain specific visualizations and these bells and whistles won't help us.
kevinSuttle 11y ago
Chris Granger just released Eve as well. www.chris-granger.com/2015/08/17/version-0/
seagreen 11y ago
In the second example how does a live programming system synthesize a "Person" object? Most data types should have `example` methods. They're too useful not to have, for documentation generation as well as live programming. `Person` in this case should definitely have one. What if there are multiple constructors? What if it depends on ten other objects when being created? Each of those other objects should also have `example` methods. Person's example method should use those, possibly modifying them after they're called so that they make more sense in the context of a `Person`. What if this object only originates from a database? Should the user constantly create these objects by hand when they want to edit any function in their program? Zomg no. Make `example` methods. The idea of having beginners program without static types and immutability seems misguided to me, because it makes them keep the whole program in their head instead of just the function they're working on. The idea of making them keep the whole program in their head _while also not having an example of what they're operating on_ is just silly. PS As to the "generating unit tests" point, the place to start looking for inspiration is QuickCheck: http://www.stuartgunter.org/intro-to-quickcheck/ http://www.stuartgunter.org/intro-to-quickcheck/ EDIT: PPS: If any lispers are reading this, I'd be curious to hear how you generate example objects at the REPL. Since the lisp community places such a high priority on REPL programming maybe it's already explored this area in depth.
- dkersten 11y ago
  If any lispers are reading this, I'd be curious to hear how you generate example objects at the REPL. Since the lisp community places such a high priority on REPL programming maybe it's already explored this area in depth. Clojure is my language of choice. What I've been doing so far is keep sample data in my unit test files. I then use a mixture of running code direct from my editor [0], importing the sample data from my (non-editor) REPL [1] and actually running the unit tests. Its worth noting that this usually happens in reverse: I construct the data in the REPL while experimenting and then copy it to the unit tests after for reuse. how does a live programming system synthesize a "Person" object? That just got me thinking. In Clojure, we generally use raw data (primitives, maps, lists, sets, vectors) rather than hiding behind objects, so synthesizing them is the same as any other data. Realistically, there would generally be a constructor function, but most functions are deterministic pure functions. I feel like OO languages may be harder to make play nice with live programming because OO hides a lot of stuff and encourages impurity. [0] I can eval the entire file, the form that the cursor is on, or I can eval code I type into a REPL. [1] (require '[my-test-namespace.my-test-file :as alias]) Then access alias/sample-data
arxpoetica 11y ago
Here's my simplistic (but accurate?) summation of Bret Victor's evangelism: make the programming world designer automated/friendly.
nullz 11y ago
here's a JS implementation of Bret Victor's "Learnable Programming" demo http://www.fullstack.io/choc/ http://www.fullstack.io/choc/
bcheung 11y ago
> How do we generalize this solution such that it helps programmers building compiler platforms like LLVM and Roslyn? How will it help programmers researching neural networks? How will it help programmers writing line of business applications? Databases? Apps? Financial backends? I've given this idea quite a bit of thought. I've been wanting to do something in this space but haven't had the time to work on it yet. The idea I have proposed but haven't seen implemented anywhere is to follow what I call the "workbench model". The problem is we are "programming blind". Instead of thinking of programming as a series of abstract steps in a recipe, just start with some sample input and manipulate it towards the output. When you want to do woodworking you use a hammer, saw, sander, etc and manipulate it directly. It's intuitive and you can see what you are doing. The result is immediate. Modern programming is like writing G-code to run though a CNC machine. Instead of defining things in terms of a series of steps and trying to figure out how to visual that, flip it around and do it the other way. Pass in some parameters and let the user manipulate it however they want in real time. Record the steps they used to go from input to output (like a macro). There is your function. This also works quite well, but is not limited to, a postfix environment like Factor (or the HP-48 calculator RPN language if are more familiar with that). Now obviously there are multiple input scenarios that need to be handled uniquely. How do we do that? Simple, run each case separately and use pattern matching to qualify your actions. Ideally, this would be combined with "first-class citizen tests" (another pattern I came up). Basically, when you define a function you give it some sample inputs for the different scenarios and edge cases. You specify the outputs for each corresponding input. When working on the function you choose an input and then work towards the output. When the output is correct it turns green automatically. This happens in real time as you are manipulating the input values. It also tests the other input scenarios as well. If one or more of the other inputs don't match the required output then you add more pattern matching. When all tests are green your function is done.
bcheung 11y ago
> This attitude is a losing one. For all its warts, bumps, pains and bugs, programming today works somewhat decently enough. Sometimes pragmatism is the enemy of progress. As stated earlier in the article, you don't get the combustion engine by thinking how we can make horse drawn carriages faster. Thiel also recommends this approach in Zero to One.
bcheung 11y ago
One of the other problems is that people keep trying to find the one perfect tool or solution that will work for all cases. This is the wrong attitude. When manipulating any kind of object in the real world there are a series of tools. Each has their own feel, way you interact with it, and is used for a specific purpose. A hammer, saw, sander, file, router, nail, all do different things. The interface to them is unique. Programming needs to follow this model. Each scenario is different so they need to be handled separately. Allow for a comprehensive general framework and then people create tools for each scenario. The tools can be general purpose or very specific. Work with the general purpose AST with tons of annotations (comments, 2D coordinates for visual layout tools like NoFlow style, etc). Also, depending on what you are focusing on at the time you may want a different view of the code. Think how architecture is different. Framers have their own annotation. Then there are plumbing and electrical overlays. There are also wireframes and fully rendered views. Top, bottom, orthogonal, perspective, etc. You get the idea. Start with model, view, controller. Each is unique. It can be visualized and written differently. Right now we use the same text based language to describe each and to read each. When you have a general purpose AST then the code can be "read" in different modes (each with their own strengths and weaknesses). Also, sometimes is is easier to write in one form and read in another. For example, writing math using post-fix is really easy but reading it requires too much managing of the stack state in your head (cognitive overload). For reading, mathematical notation would work better.
dang 3y ago
http://web.archive.org/web/20160304045703/http://blog.comealive.io/Working-Toward-Bret-Victors-Learnable-Programming/ http://web.archive.org/web/20160304045703/http://blog.comeal...

206 points by Permit 11y ago

huuu 11y ago

Currently Alive offers two licenses: Individual and Enterprise. I searched the site but I can't find any information. Does anyone know the difference?

macmac 11y ago
I don't see much guidance either. It appears from the brief guidance text ("Purchase a license for yourself" vs "Purchase a license for others." that "Individual" is for personal use, and "Enterprise" for use within a legal entity employing multiple individuals - but I am grasping for straws here.
Permit 11y ago
Individual is if you're purchasing for yourself. (You can use it at work if you'd like). Enterprise is if you're purchasing multiple licenses (ie. licenses for employees).
- dkersten 11y ago
  Going by the wording on a similar licensing structure for another programming tool: Individual allows you to use the tool commercially and you (the individual) owns the license Enterprise allows you to use the tool commercially and your employer (the enterprise) owns the license

hellofunk 11y ago

Article suggests that only Alive and Light Table provide this form of programming interaction. However, many (certainly not all) of the features in this article are a part of the Swift Playgrounds in recent iterations of Xcode, which were probably inspired by this work. Just worth pointing out. Update: I missed the part further down in the article where the Playgrounds were indeed mentioned. Whoops.

seanmcdirmid 11y ago
Here is a fascinating thesis written in 2003 on live programming: https://llk.media.mit.edu/papers/ch-phd.pdf https://llk.media.mit.edu/papers/ch-phd.pdf The ideas are quite old, much older than Bret Victor's work.
- Permit 11y ago
  >The ideas are quite old, much older than Bret Victor's work. Absolutely. Your work in particular predates Bret's and I've enjoyed reading it and hope it catches on and inspires more folks at Microsoft and Microsoft Research! :) I think what makes Bret's work a little different than the linked work is that Bret's work managed to escape academia and appeal to an audience that might not have otherwise been exposed to these ideas in the first place.
  - pjmlp 11y ago
    It is great that Bret's work made the ideas more mainstream, but on my research for Xerox PARC's work I would say the ideas go back at very least to the interactive coding available on Smalltalk, Interlisp-D and Mesa/Cedar. Interactive coding is with us since the early 80's, the ideas just failed to go mainstream.
    - seanmcdirmid 11y ago
      Live programming goes way beyond smalltalk fix and continue, morphic directness, or a LISP REPL. We've caught up to that past, it is now time to go further. And of course, no one is really quite sure what the lisp machines ever did really, it's not like they have a video on YouTube :) It is better to have that argument with Gilad Bracha, I guess.
      - pjmlp 11y ago
        Actually there are a few videos. :) But I guess all fail short how they really were. http://www.loper-os.org/?cat=10 http://www.loper-os.org/?cat=10 http://www.loper-os.org/?p=932 http://www.loper-os.org/?p=932 https://www.youtube.com/watch?v=o4-YnLpLgtk https://www.youtube.com/watch?v=o4-YnLpLgtk

jasode 11y ago

I may understate Bret Victor's thesis and may overstate Josh Varty's counterargument but I believe JV's criticisms are not applicable to BV's particular essay. Some key quotes from each for context: >Bret Victor: "How do we get people to understand programming?"[1] >Josh Varty: "Problems getting to Learnable Programming [...] However, we need to stop and think deeply about how this system would handle typical code. How do we generalize this solution such that it helps programmers building compiler platforms like LLVM and Roslyn? How will it help programmers researching neural networks? How will it help programmers writing line of business applications? Databases? Apps? Financial backends? The vast majority of functions in today's codebases do not map nicely to a 2D output." I see BV's essay focused on learning programming for people unfamiliar with programming. For non-programmers, even simple syntax such as "x=0; x=x+1" looks strange and beginners can't hold in their head what it does. So instead trying to teach beginners the LOGO programming language to move turtles around on the screen or BASIC language of "10 PRINT "HELLO" \n 20 GOTO 10", Brett shows a visualization where code syntax update its 2d output in a realtime feedback loop. This can help novices make the leap from abstract syntax in a text editor to the concrete changes in the output. Josh Varty is going beyond the scope of newbies learning programming concepts. He's trying to generalize it to working practitioners who already understand programming and make the "Learnable Programming Model" work for any arbitrary code to any type of visualization (beyond 2D if necessary). The "live coding for everything" is an interesting concept to pursue but I don't believe Brett's essay had this wide of a scope. I don't believe working programmers who have already mastered how "programming syntax maps to changing machine state" needs visualizations for every line of source code. However, JV's generalized scope is applicable for working programmers to verify code for correctness and do sanity checks on what they think the code is doing.[2] However JV's ideas are not necessary for working programmers to understand programming. In one case, JV uses this as example: var result = DoTaxes(person); The professional programmer (not the "learning programmer") doesn't need a clever realtime visualization to "understand" DoTaxes() in the BV sense. The programmer already has some idea that it probably has some code that performs multiplication and addition. Possibly even a lookup table for different countries or taxing authorities. The realtime visualization would help the professional programmer verify what the code actually does. Since realtime isn't available today, programmers get by with watch windows in visual debuggers, or manually insert printf()/console.log() statements. However, the programmer doesn't need BV visualizations to grok the compsci topics of the changing machine state inside DoTaxes(). tldr: BV and JV are tackling 2 different issues. [1]http://worrydream.com/LearnableProgramming/ http://worrydream.com/LearnableProgramming/ [2]See how JV's ALIVE demo visualization serves a different cognitive function from BV's. Those little red annotations are helpful for professional programmers to verify behaviors but not for beginners to grok compsci: https://embed.gyazo.com/4dc7ac656863cbd02a8e213598f85a4f.gif https://embed.gyazo.com/4dc7ac656863cbd02a8e213598f85a4f.gif

Buetol 11y ago

But most things we see are 2D outputs (webpages, world if you close one eye, text console,..). I think the closer we are to the bret Victor's ideal (of seeing what you do directly) is this: https://www.youtube.com/watch?v=xsSnOQynTHs https://www.youtube.com/watch?v=xsSnOQynTHs (react-hot-loader + redux). And this is already practical. Another nice tool who's the near his ideal is the chrome dev console: visual interaction, live edit, start/stop debugging,.. The future is bright.

orodley 11y ago
But the amount of code that deals directly with producing such output is usually very low, as a proportion of the total amount of code in the system. Having a pane on the right say '825' next to the 'printf("%d\n", do_the_actual_work(foo, bar));' in my code isn't useful. I already get that from the terminal. The place where the benefit would actually appear is visualizing the parts of the code that are doing the complex and error-prone tasks in the system. If you're a frontend web developer, then sure, it could be useful for you. But with the kind of stuff I do personally, the 2D output demonstrated in the article is irrelevant. Most stuff is much more abstract, and has zero relationship to direct production of visual output. It looks cool and all, but ultimately I feel like it's focusing on the easy problem rather than the important one. There are a few examples in there of visualizing the values in a for loop over time, but again, I feel like this is unrealistic. The proportion of my code that only executes for a fixed number of iterations that is easily determined at compile-time is negligible. As is iteration over a fixed, compile-time set of values. Most code lives inside functions that can be called with different combinations of parameters, interspersed with multiple nested loops and conditionals at different levels in the call stack, etc. Visualizing something like that in a useful way is much more difficult. If they can show an example of that, I'd be very interested. Until then, it seems more like a toy. A very interesting, promising toy, but still a toy. The unit test example gets a bit closer, but it's still just dealing with the output of all the code that actually does the work, not the details of that code itself. A tool like this should be helping you with the hard tasks rather than the easy ones, because the easy ones are already, well, easy. I'm not trying to be hostile, it certainly looks cool, and it looks like it could potentially be very useful in the future. It's just that currently it doesn't look like it would have any practical utility for me.

dkersten 11y ago

How do we generalize this solution such that it helps programmers building compiler platforms like LLVM and Roslyn? How will it help programmers researching neural networks? How will it help programmers writing line of business applications? Databases? Apps? Financial backends? In many (but certainly not all) of these domains, we already visualise (parts of) them in 2D (as charts), so I see no reason why this wouldn't apply here too. In my opinion, its not so important to solve the issue for every problem domain one might program in, but rather to do so for as many as are applicable. Just because a tool doesn't help with X, doesn't mean its a failure if it improves on Y.

krosaen 11y ago

Nice. I think a mention of figwheel / devcards would have been worthwhile: http://rigsomelight.com/2014/06/03/devcards-taking-interactivity-to-the-next-level.html http://rigsomelight.com/2014/06/03/devcards-taking-interacti...

ch4s3 11y ago
very cool. I'm constantly jealous of what you folks have in clojure land.

phantarch 11y ago

Personally, I would be wary of any IDE that attempted to interpret what my code is doing for me. Each person probably has a different mental image or interpretation of how their code works, and enforcing a singular interpretation of code via IDE might only enable people to 'learn' how to program within that environment. Teach a man to fish.

seanmcdirmid 11y ago
You have a computer right in front of you, why not use it to figure out what your code is doing rather than do the mental gymnastics in your head! This reminds of a story, I think it was dijkstra or maybe Knuth, who was lamenting that their students were being too sloppy because they got to program on interactive terminals and not the punch cards of yesterday. Programming without an IDE is the same...it's using punchcards when something much better is available.
- brianshaler 11y ago
  The same could be said about other types of abstractions, such as using a compiler versus assembly. In the vast majority of circumstances, developers get far more accomplished using higher level abstractions and frameworks. In very extreme circumstances, portions of an application may need to be rewritten at a lower level for optimizations, but that doesn't negate the value provided by abstractions that allow the developer to be more productive expressing higher level concepts while the computer handles the tedium of how those concepts are translated into machine code.
  - phantarch 11y ago
    I think the difference here is that in the movement towards 'smart' IDE's, they attempt to go beyond the purely semantic meaning of the code and deduce what the interpreted meaning of it is. I'm all for what is in this article as far as it pertains to more interpretations of the semantic meaning.
- jrbrtsn 11y ago
  Kernel developers don't use and IDE for the Linux kernel, and they are arguably some of the best programmers in the world. Great programmers use vim or emacs, because the imagery in their mind is far more powerful than anything an IDE could display. Besides, any screen real estate used for "interpretive" purposes is just an annoyance.

swah 11y ago

I think many game developers build those tools into their games, like Eskil's Love (https://en.wikipedia.org/wiki/Love_(video_game) https://en.wikipedia.org/wiki/Love_(video_game) tools.

amadeusw 11y ago
A few years ago (2012) I was taken aback by the Unreal Engine development process. Their IDE features a running game with all elements being selectable and interactively editable. In one video fragment [1] they hop to Visual Studio where they change gravity. After a few seconds of compilation, the game's code is updated. [1] https://youtu.be/MOvfn1p92_8?t=9m46s https://youtu.be/MOvfn1p92_8?t=9m46s
corysama 11y ago
His presi about designing the tools to make an MMO as a solo dev is definitely worth watching. https://vimeo.com/6010060 https://vimeo.com/6010060
- swah 11y ago
  That's what I'm talking about, great video. I wish Love had gotten more love. (To be honest I didn't enjoy playing it, but I also don't enjoy Minecraft, and this one I love the aesthetics).

stillsut 11y ago

Attempts like these might be barking up the wrong tree. People who are going to be successful in bootstrapping themselves from 0 to dev are going to naturally grasp logic, state, or any other general programming concept. (Not master, but grasp). What people need is a real problem they can solve with programming: automate an office process, build a website, crunch some numbers, etc. And this is usually best done on a stack that has solutions for these problems. That's why "the future" of learning to program looks more like this: http://automatetheboringstuff.com/ http://automatetheboringstuff.com/ than a noob-IDE.

romaniv 11y ago
I don't think it's about bootstrapping to dev. I think it's about allowing people to solve certain problems using programming, but in a different way from what we're used to. It's about visualizing explorative programming. That's the way I understand it.
ThomPete 11y ago
Thats not the point of what Bret has been trying to advocate IMO. Instead he is trying to establish better frameworks for thinking about programming by providing a better feedback loop.
- seiji 11y ago
  Smalltalk was the pinnacle of programatic pedagogy. Hypercard was the easiest way for regular humans to use computers for computer-like automations. But, then you run into the "No Real Programmer" problem. The nerds take over, hyper-complicate everything, then we're back to nobody understanding anything. (Also see: "No Real Unix User" when people say "Well, I don't consider OS X users to be unix users.")
  - jowiar 11y ago
    The other major tool I'd put up there with Smalltalk and Hypercard is Excel, at least when it comes to automation of real-world business problems. To an extent, it made a large enough set of problems easy enough to solve that tools have stagnated as a result.

RogerL 11y ago

I urge the people working on this to recognize that we all don't think the same. (I know, you don't claim that we do, but I don't see these counter points expressed often). I can't explain how I think, but it isn't visual, and doesn't seem to involve language much. Probably the closest is to say I think in math and geometry. That doesn't make any descriptive sense, but it is what I experience. I fell deeply in love with math, and then programming. A few words and control structures, and you have Turing completeness! It's as beautiful as language. Minimizing expression is sometimes far more powerful than unconstrained expression. I can hold these structures in my head, and so can most programmers that I know. Pictures are a pale, weak thing in comparison. "The Illustrated Guide to Kant's Critique of Pure Reason" has never been published (SFAIK), and for good reason. The simplest rules of grammar allows us to generate and express extremely complicated and nuanced ideas. Ya, sure, we could make a nice chart of synthetic/analytic and a priori/posterior, and I think Kant did that, but beyond that what do pictures get you? I bet there are visual thinkers reading this that have rebuttals or examples, and that is great. Einstein was a great admirer of Kant, and was a visual thinker, so I imagine him raising objections! But I think in the end the visualizations may have illustrate power, but rarely investigative power. Einstein put the lie to that with his work in Relativity, but he was an extraordinarily unique thinker (he did his work visually, and then struggled to get the math to prove his ideas). Anyway, my somewhat inarticulate argument is that programming languages was the great invention. Anything that is Turing complete lets us express anything computable. I think if you can find ways to complement that it will be a great contribution to knowledge. But I don't think you can replace or improve upon a Turing complete language (unsupported assertion requires citation here!). It would be great to be proven wrong. I use computer languages to do math, computer vision, and AI type stuff. Others uses it for different things. It all works. There is no universal visual paradigm to replace it. Engineering is optimization in multi-dimensions. Visualization limits us to 2 or imperfectly, 3 dimensions. So you can sort of slice out representations of this large, multidimensional space, but you are now working like the blind men on the elephant. You'll never get the complete 'picture'. You are just sort of poking at it with a stick. Whereas with a couple of equations I can describe the entire space AND now have powerful tools to explore that space, describe it, and determine its properties. I think back to one of Bret's videos where he uses a live environment to compute the trajectory for a character in a video game. In math that is known as the 'shooting method'. It kind of works, for some problems. There is also a universe of problems for which it doesn't work. How can you even tell if it works or not visually? The language of math gives us that tool. I love pictures, and produce charts all the time for my math code. But they do not replace the math, they illustrate it. I do my work in math, and in state, and in sw architecture, and sometimes use visual tools to help check the work. There is no language of visualizations, and without one you will either be illustrating the work of math and computer languages (which is not a bad thing, I'll happily use the tools when appropriate) or severely limiting what we can do. I don't work or think in 2D or 3D space and cannot be limited to such a restricted view (pun intended). I work in small spaces usually (R^18 or so) and visualization is a non-starter except as a great way to learn some of the concepts. I know plenty of you work in far larger spaces. tl;dr: the amazing advance was Turing complete languages; visualizations are not Turing complete; languages are powerful, visualizations do not have a language and hence aren't analyzable unless your name is Einstein.

erokar 11y ago

I think Elm makes good strides toward this goal: http://debug.elm-lang.org/ http://debug.elm-lang.org/

Permit 11y ago
I regret neglecting to mention Elm in the original article. I've only played around with their tooling, but it looks really awesome. It's probably even more in the spirit of Bret's original article as they've gone beyond designing tooling and also designed their own language.

solomatov 11y ago

It looks impressive, but only in these superficial simple examples. If we have really complex problem, i.e., designing distributed algorithm, we need to create domain specific visualizations and these bells and whistles won't help us.

kevinSuttle 11y ago

Chris Granger just released Eve as well. www.chris-granger.com/2015/08/17/version-0/

seagreen 11y ago

In the second example how does a live programming system synthesize a "Person" object? Most data types should have `example` methods. They're too useful not to have, for documentation generation as well as live programming. `Person` in this case should definitely have one. What if there are multiple constructors? What if it depends on ten other objects when being created? Each of those other objects should also have `example` methods. Person's example method should use those, possibly modifying them after they're called so that they make more sense in the context of a `Person`. What if this object only originates from a database? Should the user constantly create these objects by hand when they want to edit any function in their program? Zomg no. Make `example` methods. The idea of having beginners program without static types and immutability seems misguided to me, because it makes them keep the whole program in their head instead of just the function they're working on. The idea of making them keep the whole program in their head _while also not having an example of what they're operating on_ is just silly. PS As to the "generating unit tests" point, the place to start looking for inspiration is QuickCheck: http://www.stuartgunter.org/intro-to-quickcheck/ http://www.stuartgunter.org/intro-to-quickcheck/ EDIT: PPS: If any lispers are reading this, I'd be curious to hear how you generate example objects at the REPL. Since the lisp community places such a high priority on REPL programming maybe it's already explored this area in depth.

dkersten 11y ago
If any lispers are reading this, I'd be curious to hear how you generate example objects at the REPL. Since the lisp community places such a high priority on REPL programming maybe it's already explored this area in depth. Clojure is my language of choice. What I've been doing so far is keep sample data in my unit test files. I then use a mixture of running code direct from my editor [0], importing the sample data from my (non-editor) REPL [1] and actually running the unit tests. Its worth noting that this usually happens in reverse: I construct the data in the REPL while experimenting and then copy it to the unit tests after for reuse. how does a live programming system synthesize a "Person" object? That just got me thinking. In Clojure, we generally use raw data (primitives, maps, lists, sets, vectors) rather than hiding behind objects, so synthesizing them is the same as any other data. Realistically, there would generally be a constructor function, but most functions are deterministic pure functions. I feel like OO languages may be harder to make play nice with live programming because OO hides a lot of stuff and encourages impurity. [0] I can eval the entire file, the form that the cursor is on, or I can eval code I type into a REPL. [1] (require '[my-test-namespace.my-test-file :as alias]) Then access alias/sample-data

arxpoetica 11y ago

Here's my simplistic (but accurate?) summation of Bret Victor's evangelism: make the programming world designer automated/friendly.

nullz 11y ago

here's a JS implementation of Bret Victor's "Learnable Programming" demo http://www.fullstack.io/choc/ http://www.fullstack.io/choc/

bcheung 11y ago

> How do we generalize this solution such that it helps programmers building compiler platforms like LLVM and Roslyn? How will it help programmers researching neural networks? How will it help programmers writing line of business applications? Databases? Apps? Financial backends? I've given this idea quite a bit of thought. I've been wanting to do something in this space but haven't had the time to work on it yet. The idea I have proposed but haven't seen implemented anywhere is to follow what I call the "workbench model". The problem is we are "programming blind". Instead of thinking of programming as a series of abstract steps in a recipe, just start with some sample input and manipulate it towards the output. When you want to do woodworking you use a hammer, saw, sander, etc and manipulate it directly. It's intuitive and you can see what you are doing. The result is immediate. Modern programming is like writing G-code to run though a CNC machine. Instead of defining things in terms of a series of steps and trying to figure out how to visual that, flip it around and do it the other way. Pass in some parameters and let the user manipulate it however they want in real time. Record the steps they used to go from input to output (like a macro). There is your function. This also works quite well, but is not limited to, a postfix environment like Factor (or the HP-48 calculator RPN language if are more familiar with that). Now obviously there are multiple input scenarios that need to be handled uniquely. How do we do that? Simple, run each case separately and use pattern matching to qualify your actions. Ideally, this would be combined with "first-class citizen tests" (another pattern I came up). Basically, when you define a function you give it some sample inputs for the different scenarios and edge cases. You specify the outputs for each corresponding input. When working on the function you choose an input and then work towards the output. When the output is correct it turns green automatically. This happens in real time as you are manipulating the input values. It also tests the other input scenarios as well. If one or more of the other inputs don't match the required output then you add more pattern matching. When all tests are green your function is done.

bcheung 11y ago

> This attitude is a losing one. For all its warts, bumps, pains and bugs, programming today works somewhat decently enough. Sometimes pragmatism is the enemy of progress. As stated earlier in the article, you don't get the combustion engine by thinking how we can make horse drawn carriages faster. Thiel also recommends this approach in Zero to One.

bcheung 11y ago

One of the other problems is that people keep trying to find the one perfect tool or solution that will work for all cases. This is the wrong attitude. When manipulating any kind of object in the real world there are a series of tools. Each has their own feel, way you interact with it, and is used for a specific purpose. A hammer, saw, sander, file, router, nail, all do different things. The interface to them is unique. Programming needs to follow this model. Each scenario is different so they need to be handled separately. Allow for a comprehensive general framework and then people create tools for each scenario. The tools can be general purpose or very specific. Work with the general purpose AST with tons of annotations (comments, 2D coordinates for visual layout tools like NoFlow style, etc). Also, depending on what you are focusing on at the time you may want a different view of the code. Think how architecture is different. Framers have their own annotation. Then there are plumbing and electrical overlays. There are also wireframes and fully rendered views. Top, bottom, orthogonal, perspective, etc. You get the idea. Start with model, view, controller. Each is unique. It can be visualized and written differently. Right now we use the same text based language to describe each and to read each. When you have a general purpose AST then the code can be "read" in different modes (each with their own strengths and weaknesses). Also, sometimes is is easier to write in one form and read in another. For example, writing math using post-fix is really easy but reading it requires too much managing of the stack state in your head (cognitive overload). For reading, mathematical notation would work better.

dang 3y ago

http://web.archive.org/web/20160304045703/http://blog.comealive.io/Working-Toward-Bret-Victors-Learnable-Programming/ http://web.archive.org/web/20160304045703/http://blog.comeal...