4 ms·

"My biggest contribution so far at Google has been Blockly." Nice - https://developers.google.com/blockly/ https://developers.google.com/blockly/ no real fan o

"My biggest contribution so far at Google has been Blockly." Nice - https://developers.google.com/blockly/ https://developers.google.com/blockly/ no real fan of google, but the tools and code churned out by individuals there is pretty interesting. This I will play with.

hacker_9 10y ago
Blockly is awesome and often overlooked. It realises the idea of a real time scripting language, and should really be the thing devs reach for over flowcharts when they decide to implement a visual programming environment.
- BucketSort 10y ago
  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
- codeonfire 10y ago
  I saw the exact same app circa 1996 sans the web stuff. Our professor was trying to force this on us because it was his big research idea. It's not overlooked, just a really old idea that didn't pan out 20 years ago.
  - jldugger 10y ago
    IMO, the use case for blockly is those structured search and filter interfaces. Like RequestTracker or your email filter rules.
guelo 10y ago
Comparing the JavaScript vs blockly sample on that page I feel that the javascript would be much more readable even for a total newbie.
- jamesroseman 10y ago
  As someone with a few years in the industry who's currently volunteering to help teach high school kids coding for the first time -- you have no idea how easily code confuses newbies. Take even the smallest snippet: while (Count <= 3) { To you or me, this is pretty obvious. I've had kids ask me questions I'd never have thought of because I know this stuff already: * What do the parentheses mean? * What is Count, is it a Javascript thing? * Is Count being set to 3? (<= looks like an arrow, not necessarily less than or equal to) * What is that squiggle? (meaning the '{') * Is this a program? I'm with you, the Blockly stuff is hardly legible to me. But to kids learning this for the first time, I can tell you from first hand experience the color/shape/block aspect makes a huge difference.
  - mercer 10y ago
    Agreed! A simple for-loop can be complicated. First, they need to understand that a for-loop instantiates a variable (i). Then they need to understand that the next step is a limit: i < something. And then they need to understand that i++ means increment i every time that the below code is run. Nevermind that it makes more sense to go: i = 0, i = I + 1, i < something, that's how it works. Of course if they don't get that, they may not be cut out for programming. But its far from intuitive.
thomasahle 10y ago
Something I thought about while looking at this: How come the code is made "material", but the variables and "objects" of the code are still abstract/just named? Have anybody thought about how to make the data objects more real as well?
- eternalban 10y ago
  The 'flow' is "materialized" [using your terminology] since everyday intuitions accessible to anyone can serve as guide for 'assembling' an algorithm. For objects, we are talking structure, mostly. If you require that higher level of (semantic) expressiveness it seems at odds with using something like this. We can manifest a object (or structure) as a (say) box, with slots. But if you are doing that, shouldn't you just upgrade to Python?
ivan_ah 10y ago
Another graphical programming environment for kids is Snap! http://snap.berkeley.edu/ http://snap.berkeley.edu/ From the about page: One of the limitations of Scratch as a language for computer science education is that its lists are not first class, so you can’t have a list of lists. Making lists first class is enough of an extension to Scratch to allow the creation of any other data structures (trees, heaps, hash tables, dictionaries, and so on) in user-defined Snap! code, implemented as lists of lists. via https://snap.berkeley.edu/about.html https://snap.berkeley.edu/about.html
- jldugger 10y ago
  Blockly is basically a web version of snap.
  - Tempest1981 10y ago
    Snap! is web-based -- can you clarify?
    - jldugger 10y ago
      Sorry, my mistake. I was thinking of Scratch.
      - Tempest1981 10y ago
        Scratch is also web-based. I think it still uses Flash.

hacker_9 10y ago

Blockly is awesome and often overlooked. It realises the idea of a real time scripting language, and should really be the thing devs reach for over flowcharts when they decide to implement a visual programming environment.

BucketSort 10y ago
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
codeonfire 10y ago
I saw the exact same app circa 1996 sans the web stuff. Our professor was trying to force this on us because it was his big research idea. It's not overlooked, just a really old idea that didn't pan out 20 years ago.
- jldugger 10y ago
  IMO, the use case for blockly is those structured search and filter interfaces. Like RequestTracker or your email filter rules.

guelo 10y ago

Comparing the JavaScript vs blockly sample on that page I feel that the javascript would be much more readable even for a total newbie.

jamesroseman 10y ago
As someone with a few years in the industry who's currently volunteering to help teach high school kids coding for the first time -- you have no idea how easily code confuses newbies. Take even the smallest snippet: while (Count <= 3) { To you or me, this is pretty obvious. I've had kids ask me questions I'd never have thought of because I know this stuff already: * What do the parentheses mean? * What is Count, is it a Javascript thing? * Is Count being set to 3? (<= looks like an arrow, not necessarily less than or equal to) * What is that squiggle? (meaning the '{') * Is this a program? I'm with you, the Blockly stuff is hardly legible to me. But to kids learning this for the first time, I can tell you from first hand experience the color/shape/block aspect makes a huge difference.
- mercer 10y ago
  Agreed! A simple for-loop can be complicated. First, they need to understand that a for-loop instantiates a variable (i). Then they need to understand that the next step is a limit: i < something. And then they need to understand that i++ means increment i every time that the below code is run. Nevermind that it makes more sense to go: i = 0, i = I + 1, i < something, that's how it works. Of course if they don't get that, they may not be cut out for programming. But its far from intuitive.

thomasahle 10y ago

Something I thought about while looking at this: How come the code is made "material", but the variables and "objects" of the code are still abstract/just named? Have anybody thought about how to make the data objects more real as well?

eternalban 10y ago
The 'flow' is "materialized" [using your terminology] since everyday intuitions accessible to anyone can serve as guide for 'assembling' an algorithm. For objects, we are talking structure, mostly. If you require that higher level of (semantic) expressiveness it seems at odds with using something like this. We can manifest a object (or structure) as a (say) box, with slots. But if you are doing that, shouldn't you just upgrade to Python?

ivan_ah 10y ago

Another graphical programming environment for kids is Snap! http://snap.berkeley.edu/ http://snap.berkeley.edu/ From the about page: One of the limitations of Scratch as a language for computer science education is that its lists are not first class, so you can’t have a list of lists. Making lists first class is enough of an extension to Scratch to allow the creation of any other data structures (trees, heaps, hash tables, dictionaries, and so on) in user-defined Snap! code, implemented as lists of lists. via https://snap.berkeley.edu/about.html https://snap.berkeley.edu/about.html

jldugger 10y ago
Blockly is basically a web version of snap.
- Tempest1981 10y ago
  Snap! is web-based -- can you clarify?
  - jldugger 10y ago
    Sorry, my mistake. I was thinking of Scratch.
    - Tempest1981 10y ago
      Scratch is also web-based. I think it still uses Flash.