6 ms·

Watch Bret Victor's videos about Learnable Programming[1], in particular Stop Drawing Dead Fish. [2] Only because visual tools in the past were limited to putti

Watch Bret Victor's videos about Learnable Programming[1], in particular Stop Drawing Dead Fish. [2] Only because visual tools in the past were limited to putting properties in boxes doesn't mean that all visual tools have to be that way. [1] http://worrydream.com/LearnableProgramming/ http://worrydream.com/LearnableProgramming/ [2] https://vimeo.com/64895205 https://vimeo.com/64895205

hacker_9 11y ago
I have seen it, and while Bret Victors 'research' is interesting, none of it actually scales to a practical level.
- TuringTest 11y ago
  Because it is not engineered to industrial levels. It lacks encapsulation and packaging, but those can be added. Have you seen the tools by Chris Granger (Light Table, Eve)? Although they are not as spectacular as Victor's, those show a lot of promise to become practical tools.
  - hacker_9 11y ago
    Bret Victor's ideas lack a lot more than that. Complex systems contain hundreds of sub systems which in turn can contain hundreds of algorithms, which then contain many many variables. All interacting in some way. His ideas simply don't scale to this level (he works with < 10 variables, enough for a nicely packaged demo). Chris Granger himself stopped working on LightTable because he didn't believe in the project, and if you use it, the live editing gives minimal gains in productivity. As well as being buggy, slow, distracting and potential dangerous when blindly running half complete IO operations. As for Eve, well.. his first release was a visual programming tool that inflated 3 line sql statements to take up a whole page with, you guessed it, boxes and arrows. Now he is working on a 'card wiki' idea which effectively tries to hide all the program logic behind pictures and hyperlinks. Neither are good ideas, or once again, scale in any meaningful way.
    - TuringTest 11y ago
      Why do you think that doesn't scale? Hiding information is the basis for progressive disclosure, which is essential to handling the limitations of short-term human memory. Wikipedia is card-based,* and it is one of the five largest sites in the web. See Cognitive Dimensions[1] for ways to make visual systems scale. As soon as you add encapsulation and abstraction, the system can scale; it's no different than hiding code logic behind function declarations and object schemas. If you add easy composition, like modern functional languages have, such systems could be more scalable than traditional imperative languages; code outliners like Leo follow the same structural principle, and they're great for programming. [1] https://en.wikipedia.org/wiki/Cognitive_dimensions_of_notations https://en.wikipedia.org/wiki/Cognitive_dimensions_of_notati... * Ok, Wikipedia contains articles and not code, but my point is that the structure can handle lots of hierarchical content in multiple categories.
      - hacker_9 11y ago
        Wikipedia is also written in English, and made for human consumption. English is infinitely more scalable than any programming language, and the brain is far more capable of understanding than a computer. So comparing the two is unfair to say the least. Additionally simply adding 'encapsulation and abstraction' does not equal scale. Live programming for instance requires context and re-running of code on every edit (and we could be talking millions of lines of code that need to execute), re-reading of data files, re-running of prior user input and so on. There's a reason it is only implemented for small systems (read, useless practically).
        TuringTest 11y ago
        > English is infinitely more scalable than any programming language, and the brain is far more capable of understanding than a computer. So comparing the two is unfair to say the least. IMHO programming a large system shouldn't be all that different from writing an encyclopedia, or rather a math textbook; the same combination of informal explanation and formal demonstrations could be the shape that "visual" programs could take. Literate programming is written in English, and it provides much of the same advantages of the encyclopedia or technical book. Systems like IPython / Jupyter work in that direction, and they belong in the family of visual programming (although they use "classic" languages for the formal part, nothing stops them from also including graphical models as part of the code specification). Programming languages should be made for human consumption, and one of the promises of visual languages is that they use secondary notation to convey the meaning of the program, so that parts that are not visible to the compiler are still relevant. I believe that programming environments should converge towards a hybrid of programming, using the best representation for each concept - like text (to represent abstract concepts), diagrams (to represent more physical properties - time, data flows, and dependencies between modules), and raw text for the human-readable comments that explain how everything is tied together. If you build a programming environment like that, my comparison is not unfair at all. >Live programming for instance requires context and re-running of code on every edit (and we could be talking millions of lines of code that need to execute), re-reading of data files, re-running of prior user input and so on. There's a reason it is only implemented for small systems (read, useless practically). Modern IDEs are capable of doing a lot of that when in debug mode, I see no reason why having a language with a graphical syntax should make any difference - it just places a little more weight on the parser and graphic card.

hacker_9 11y ago

I have seen it, and while Bret Victors 'research' is interesting, none of it actually scales to a practical level.

TuringTest 11y ago
Because it is not engineered to industrial levels. It lacks encapsulation and packaging, but those can be added. Have you seen the tools by Chris Granger (Light Table, Eve)? Although they are not as spectacular as Victor's, those show a lot of promise to become practical tools.
- hacker_9 11y ago
  Bret Victor's ideas lack a lot more than that. Complex systems contain hundreds of sub systems which in turn can contain hundreds of algorithms, which then contain many many variables. All interacting in some way. His ideas simply don't scale to this level (he works with < 10 variables, enough for a nicely packaged demo). Chris Granger himself stopped working on LightTable because he didn't believe in the project, and if you use it, the live editing gives minimal gains in productivity. As well as being buggy, slow, distracting and potential dangerous when blindly running half complete IO operations. As for Eve, well.. his first release was a visual programming tool that inflated 3 line sql statements to take up a whole page with, you guessed it, boxes and arrows. Now he is working on a 'card wiki' idea which effectively tries to hide all the program logic behind pictures and hyperlinks. Neither are good ideas, or once again, scale in any meaningful way.
  - TuringTest 11y ago
    Why do you think that doesn't scale? Hiding information is the basis for progressive disclosure, which is essential to handling the limitations of short-term human memory. Wikipedia is card-based,* and it is one of the five largest sites in the web. See Cognitive Dimensions[1] for ways to make visual systems scale. As soon as you add encapsulation and abstraction, the system can scale; it's no different than hiding code logic behind function declarations and object schemas. If you add easy composition, like modern functional languages have, such systems could be more scalable than traditional imperative languages; code outliners like Leo follow the same structural principle, and they're great for programming. [1] https://en.wikipedia.org/wiki/Cognitive_dimensions_of_notations https://en.wikipedia.org/wiki/Cognitive_dimensions_of_notati... * Ok, Wikipedia contains articles and not code, but my point is that the structure can handle lots of hierarchical content in multiple categories.
    - hacker_9 11y ago
      Wikipedia is also written in English, and made for human consumption. English is infinitely more scalable than any programming language, and the brain is far more capable of understanding than a computer. So comparing the two is unfair to say the least. Additionally simply adding 'encapsulation and abstraction' does not equal scale. Live programming for instance requires context and re-running of code on every edit (and we could be talking millions of lines of code that need to execute), re-reading of data files, re-running of prior user input and so on. There's a reason it is only implemented for small systems (read, useless practically).
      - TuringTest 11y ago
        > English is infinitely more scalable than any programming language, and the brain is far more capable of understanding than a computer. So comparing the two is unfair to say the least. IMHO programming a large system shouldn't be all that different from writing an encyclopedia, or rather a math textbook; the same combination of informal explanation and formal demonstrations could be the shape that "visual" programs could take. Literate programming is written in English, and it provides much of the same advantages of the encyclopedia or technical book. Systems like IPython / Jupyter work in that direction, and they belong in the family of visual programming (although they use "classic" languages for the formal part, nothing stops them from also including graphical models as part of the code specification). Programming languages should be made for human consumption, and one of the promises of visual languages is that they use secondary notation to convey the meaning of the program, so that parts that are not visible to the compiler are still relevant. I believe that programming environments should converge towards a hybrid of programming, using the best representation for each concept - like text (to represent abstract concepts), diagrams (to represent more physical properties - time, data flows, and dependencies between modules), and raw text for the human-readable comments that explain how everything is tied together. If you build a programming environment like that, my comparison is not unfair at all. >Live programming for instance requires context and re-running of code on every edit (and we could be talking millions of lines of code that need to execute), re-reading of data files, re-running of prior user input and so on. There's a reason it is only implemented for small systems (read, useless practically). Modern IDEs are capable of doing a lot of that when in debug mode, I see no reason why having a language with a graphical syntax should make any difference - it just places a little more weight on the parser and graphic card.