I've played with it a little bit now, and my response is mixed.
On the pro side, I like the visual nature of it. If I may say, I find the Quest GUI editor to be hard to use to actually visualize large pieces of code. I'm not sure why that is. It just seems cluttered to me, and hard to pick out the nice structure you can get in a code view. Blockly solves that in spades. I haven't written a large chunk of code in it yet, but it really organizes things well visually. The indents are nice. The items are compact. You can scan the code from top to bottom and just *see* what it's doing,
I also really like how it makes code more spatial. I tend to think about code that way myself, and I've often wondered how it would be to have blocks you could move around. Lego Mindstorms had a programming UI similar to this.
So I like it as an interface.
The mixed: I was playing with the "Graph" demo (http://blockly-demo.appspot.com/blockly ... ml?lang=en
), and I had an interesting experience. I wanted to graph "y = sin(180*x)". So I dragged the sin block onto the "y=" block. Then I had to tell myself that the next block would not be 180 - it would be the "something op something" block, which I then dragged the 180 and x into. It's not a big leap, and perhaps after a while it will feel like second nature to people. I just wonder how easy it would be for non-programmer/non-mathematics types to work that out.
Also, for more advanced things, they did the best they could. Again, it might become second nature how parameters are done (for example), but I was able to map what I wanted to Blockly given that I knew what I wanted. It's hard for me to know how neophytes would take that.
The other con is a bit of inflexibility in the interface. Code can often be malleable, on the large scale. (If people are just creating room description scripts, this might not be as pertinent.) The evilness can be seen by the fact that they have a different construct for a procedure that returns a value and one that does not. What happens if you decide half-way through that you do indeed want a return value? In Quest and other languages, you just do it around what you currently have. In Blockly, you'd have to rip out the guts and put into the other construct.
Also, I wondered what happened if you needed to change parameters, especially if you are already calling the procedure. Adding a parameter is ok - a new "socket" appears on the blocks for the added parameter. If you remove a parameter, it actually disconnects all the orphaned parameters from any existing calls and leaves them floating. If you accidentally remove a parameter and add it back, you'd have to manually reattach all the params.
All in all, I think it's promising. I'd want to play with it a bit more. I think the JS generation could be a big problem if it uses globals like that. It's going to be nothing but headaches to not have scoped variables. I also don't see any support for data structures, which is key for larger code development (even the Quest SDK).