Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Blockly - a visual programming language

code.google.com

Post reply on HN
Print view View original

111–120 of 129 posts

Re: Google Blockly - a visual programming language

#111

Post by ch »

jmaygarden wrote: post #100
ch wrote: post #95

Earlier quoted context omitted.

Still, the blocky code reads "count with i from 0 to (get n)", but the loop generated is accessing A[0-1]..A[n-1]. JavaScript is forgiving here, but A[0..n] is not the same as A[-1..(n-1)] (at least I'm not familiar enough with JavaScript to think otherwise).

If they are mapping index 1 to index 0, then it makes sense that 0 would map to -1 since it is one less than the first index. The bug is in the blockly sieve. As an aside, Lua also uses 1-based indexing.

I understand why they are offsetting the index, it just makes things somewhat unintuitive. In most programming languages A[-1] is the same as A[len(A)-1] (assuming zero based indexing) ... so in Blocky is A[0] expected to mean the same thing as A[len(A)-1]? Nothing here is a show stopper, just a detail that could use a bit of tightening up.

Re: Google Blockly - a visual programming language

#113

Post by xarien »

saurik wrote: post #99
xarien wrote: post #94

Earlier quoted context omitted.

Keep in mind that I specified that this is an optimal solution for this particular map. General solutions are great, but if you have additional information for leverage, you use it. In fact, as stated in explanation of the solution, the solution solves maps which the following precedence preference: Right > Left > Straight. Just FYI, it's not a bug if you understand the limitations of a solution. General solutions fo…

Then, as I said, "you may as well just hardcode the answer to this one". It takes 15 blocks to hardcode an answer with the optimal solution and almost no time thinking. This solution not only takes 15 blocks to build but executes in exactly that much time. Alternatively, you can spend a bunch of time proving to yourself that you have a solution that takes advantage of properties of this specific maze that gets you do…

You're assuming the fallacy that it takes less time for an explicit solution. The solution took less than 2 minutes and most of that time was spent trying to figure out how to manipulate the puzzle pieces. Now if you're talking execution time, yes conditionals and loops add to the complexity of the execution, but for any non-trivial graph, the implementation time of a non-pattern recognizing solution would be much greater.

In any case, the points I'm trying to make are simple:

1) Solid program execution is much more important than line reduction.

2) Defining a problem space / limitations allows for better code / reuse.

3) When the implementation trade off is sufficiently small, it's better to increase the scope of the solution for possible reuse.

Re: Google Blockly - a visual programming language

#114

Post by tluyben2 »

lifthrasiir wrote: post #56

I should note that the appearance of Blockly is very similar to App Inventor[1]. It seems that visual programming languages with imperative and sequential semantics converge to one direction: "blocky" combining core primitives and custom primitives. In this sense I think it's THE future of domain-specific languages. [1] http://www.appinventor.org/

Came here to say this.

Re: Google Blockly - a visual programming language

#117

Post by garethadams »

xarien wrote: post #75

I noticed something interesting and disturbing after reading some of the answers: people are more concerned with the length of the code rather than the optimal solution (no extra turns / backtracking). This reminds me of interviewing at MS about 12 years ago and all they cared about was the ability to write recursive code. IMO, yes, elegant code is fantastic, but don't lose track of why we write code in the first pla…

`if not... else if not...` Sounds like you could simplify that a lot by reversing the order of those statements:

http://i45.tinypic.com/votkcw.jpg

Re: Google Blockly - a visual programming language

#118

Post by espertus »

majke wrote: post #12

This seems to be done by an extraordinarily smart guy - Neil Fraser. He's behind "google-diff-match-patch" [1] project, which is AFAIK the machinery behind realtime collaboration on google docs. Definitely worth watching. [1] http://code.google.com/p/google-diff-match-patch/

I've worked with Neil, and he is indeed extraordinary. I'd say he's who I want to be when I grow up except it's not clear he's grown up. See, for example, the centrifuge in his living room (http://neil.fraser.name/hardware/centrifuge/).

Re: Google Blockly - a visual programming language

#119

Post by agf »

saurik wrote: post #83
agf wrote: post #43

https://imgur.com/VBsht while (true) do if not (wall to the left) then (turn left) while (wall ahead) do (turn right) (move forward) This uses the general maze-solving logic of following the outer wall in one direction until you find the exit. It never turns then turns back or runs into a wall.

This will not solve general mazes. S=Start, G=Goal, O=Empty O-O-O | | O S-O-G | | O-O-O

I should have been more clear. That's the general logic for mazes where both the entrance and exit are on the outer edge.

Re: Google Blockly - a visual programming language

#120

Post by agf »

garethadams wrote: post #117
xarien wrote: post #75

I noticed something interesting and disturbing after reading some of the answers: people are more concerned with the length of the code rather than the optimal solution (no extra turns / backtracking). This reminds me of interviewing at MS about 12 years ago and all they cared about was the ability to write recursive code. IMO, yes, elegant code is fantastic, but don't lose track of why we write code in the first pla…

`if not... else if not...` Sounds like you could simplify that a lot by reversing the order of those statements: http://i45.tinypic.com/votkcw.jpg

That version will run into walls, turn left when it shouldn't, etc.
Post reply on HN