5 ms·

I completely disagree. I think it looks horrible and cluttered and wouldn't like to look at a complex version of this over flowcharts.

bootload 10y ago
"it looks horrible and cluttered and wouldn't like to look at a complex version of this over flowcharts" You are right. It looks horrible and cluttered and could be made better. Though visuals and design aside, the idea is sound. There is a real barrier b/w textual/visual in software. You don't see this in other physical disciplines like EE. It would be interesting to have a better (easier to read, standardised etc.) version of these flow charts. Not impossible and possibly easier to trace, explain and see alternatives/improvements in design.
- dyarosla 10y ago
  There have been very many attempts. Scratch is a pre-cursor to Blockly[0] Code.org has an in-house build on top of Blockly[1] and then there are mobile apps like Hopscotch & Tynker based on Scratch[2][3]. There's also full-fledged game engines like Stencyl[4] based on Scratch as well. To be totally honest, the whole paradigm looks cluttered and illegible to me, and I've been researching learn-to-code environments for quite some time. I'm not so sure "it could be made better". That's not to say I think it's a lost cause: I think it works great for short, 5-10 line programs. Once programs grow larger it becomes very hard to reason with, like with most VPLs. [0] https://scratch.mit.edu/ https://scratch.mit.edu/ [1] https://code.org https://code.org [2] https://www.gethopscotch.com/ https://www.gethopscotch.com/ [3] https://www.tynker.com/ https://www.tynker.com/ [4] http://stencyl.com/ http://stencyl.com/
  - bootload 10y ago
    "VPL" I missed/mis-understood this bit. I think of the visual side as another slice of how code is constructed/works/understood. I've limited experience of VCL (windstorms) and thought it was terribly clunky, got out an editor and used text. Visual coding has a place in geometric construction. This has to do with feedback maybe less so on understanding code.
  - bootload 10y ago
    "That's not to say I think it's a lost cause: I think it works great for short, 5-10 line programs. Once programs grow larger it becomes very hard to reason with, like with most VPLs." Interesting comments. I'm not sure about the failure on larger programs. The idea of these visual languages is to allow different learning styles and a quicker way to absorb the program details into your head. The best understood programs are the ones we can hold in our heads. Yet it isn't too hard a visual problem to show complex situations graphically. You do this with scale. EEs manage to show complex logic in circuit diagrams (and other diagrams for states) so I see no reason why more complex programs cannot be shown graphically. (cf: background in technical graphics/cartography/gis/programming). The biggest limitation is the way programmers think. They convert textual code and parse it in their head. Aside from logic diagrams, flow charts (and others) I don't think 4GL programs have really taken off because the source code is the most efficient way to write, read and show software. When it comes to graphics programmers don't natively grok graphics as they do text and shun such tools. I've noticed that I have to switch modes of thinking text when programming, then graphical for other things. It's a hard thing to do and the precision of programming breaks my ability to visualise and draw. The scaling idea is simple. You have blocks of code that are represented as Blocky. As you look at more aspects of the program, you scale out and see a smaller scale view of the code represented visually. You do this with maps all the time. The complexity of the data is orders of magnitudes of the landscape is more complex with respect to software. You zoom in and out of the landscape as needed to understand, measure or picture the lay of the land. The key thing I get from this is the union of primarily textual programmers to people wishing to visually understand has a shallow overlap.
    - dyarosla 10y ago
      I've done a lot of research into other VPLs as well, and in theory, all of these ideas are sound. Unfortunately, it seems like VPLs only work well for well-defined domains (say, a VPL for shaders, a VPL for compositing, a VPL for EE, a VPL for business logic) Once you try to go general, and add "zooming in" and "zooming out" mappings, the number of ways that people would prefer to visualize each becomes exponentially more complex to display/interact with; so much so that then simply using text seems like a general-enough solution. I'm still hopeful that a general purpose VPL could exist and work for 'real' programs, but so far my search has come up empty. A good reference list to look at for existing VPLs: http://blog.interfacevision.com/design/design-visual-progarmming-languages-snapshots/ http://blog.interfacevision.com/design/design-visual-progarm...
  - deleted 10y ago
    [deleted]
  - rixed 10y ago
    Just for the record I have to add snap to this list, which is the only one that worked with my kid. It's like a much cleaner alternative to scratch, as a single JavaScript page designed to world offline too (which I've found to be a requirement for a distraction free environment). http://snap.berkeley.edu http://snap.berkeley.edu

bootload 10y ago

"it looks horrible and cluttered and wouldn't like to look at a complex version of this over flowcharts" You are right. It looks horrible and cluttered and could be made better. Though visuals and design aside, the idea is sound. There is a real barrier b/w textual/visual in software. You don't see this in other physical disciplines like EE. It would be interesting to have a better (easier to read, standardised etc.) version of these flow charts. Not impossible and possibly easier to trace, explain and see alternatives/improvements in design.

dyarosla 10y ago
There have been very many attempts. Scratch is a pre-cursor to Blockly[0] Code.org has an in-house build on top of Blockly[1] and then there are mobile apps like Hopscotch & Tynker based on Scratch[2][3]. There's also full-fledged game engines like Stencyl[4] based on Scratch as well. To be totally honest, the whole paradigm looks cluttered and illegible to me, and I've been researching learn-to-code environments for quite some time. I'm not so sure "it could be made better". That's not to say I think it's a lost cause: I think it works great for short, 5-10 line programs. Once programs grow larger it becomes very hard to reason with, like with most VPLs. [0] https://scratch.mit.edu/ https://scratch.mit.edu/ [1] https://code.org https://code.org [2] https://www.gethopscotch.com/ https://www.gethopscotch.com/ [3] https://www.tynker.com/ https://www.tynker.com/ [4] http://stencyl.com/ http://stencyl.com/
- bootload 10y ago
  "VPL" I missed/mis-understood this bit. I think of the visual side as another slice of how code is constructed/works/understood. I've limited experience of VCL (windstorms) and thought it was terribly clunky, got out an editor and used text. Visual coding has a place in geometric construction. This has to do with feedback maybe less so on understanding code.
- bootload 10y ago
  "That's not to say I think it's a lost cause: I think it works great for short, 5-10 line programs. Once programs grow larger it becomes very hard to reason with, like with most VPLs." Interesting comments. I'm not sure about the failure on larger programs. The idea of these visual languages is to allow different learning styles and a quicker way to absorb the program details into your head. The best understood programs are the ones we can hold in our heads. Yet it isn't too hard a visual problem to show complex situations graphically. You do this with scale. EEs manage to show complex logic in circuit diagrams (and other diagrams for states) so I see no reason why more complex programs cannot be shown graphically. (cf: background in technical graphics/cartography/gis/programming). The biggest limitation is the way programmers think. They convert textual code and parse it in their head. Aside from logic diagrams, flow charts (and others) I don't think 4GL programs have really taken off because the source code is the most efficient way to write, read and show software. When it comes to graphics programmers don't natively grok graphics as they do text and shun such tools. I've noticed that I have to switch modes of thinking text when programming, then graphical for other things. It's a hard thing to do and the precision of programming breaks my ability to visualise and draw. The scaling idea is simple. You have blocks of code that are represented as Blocky. As you look at more aspects of the program, you scale out and see a smaller scale view of the code represented visually. You do this with maps all the time. The complexity of the data is orders of magnitudes of the landscape is more complex with respect to software. You zoom in and out of the landscape as needed to understand, measure or picture the lay of the land. The key thing I get from this is the union of primarily textual programmers to people wishing to visually understand has a shallow overlap.
  - dyarosla 10y ago
    I've done a lot of research into other VPLs as well, and in theory, all of these ideas are sound. Unfortunately, it seems like VPLs only work well for well-defined domains (say, a VPL for shaders, a VPL for compositing, a VPL for EE, a VPL for business logic) Once you try to go general, and add "zooming in" and "zooming out" mappings, the number of ways that people would prefer to visualize each becomes exponentially more complex to display/interact with; so much so that then simply using text seems like a general-enough solution. I'm still hopeful that a general purpose VPL could exist and work for 'real' programs, but so far my search has come up empty. A good reference list to look at for existing VPLs: http://blog.interfacevision.com/design/design-visual-progarmming-languages-snapshots/ http://blog.interfacevision.com/design/design-visual-progarm...
- deleted 10y ago
  [deleted]
- rixed 10y ago
  Just for the record I have to add snap to this list, which is the only one that worked with my kid. It's like a much cleaner alternative to scratch, as a single JavaScript page designed to world offline too (which I've found to be a requirement for a distraction free environment). http://snap.berkeley.edu http://snap.berkeley.edu