in reply to block-based programming...
You'll see the downsides of that approach as soon as you reach blocks F, G and H, which do the "same as .. with ..", which clearly looks like you want to have block C as a function, taking cartein arguments, being called from certain points of your main program with different parameters. I mean, you could write your block-based program and then refactor out all the redundant stuff that you find. Personally, i'd try to find the obvious things before and not write block-stuff at all.
Perhaps writing a subroutine for each block may help. While you write each sub, try to make it as flexible as possible. Finally you only need a main script, keeping the main program's state variables and calling the subs accordng to the overall logic.
You might want to think of an OO model for your data, not only refactoring to subs, but to classes and methods. The main program does then not just keep state "variables", but objects, which you might want to reuse somehwere else...
I'm sure you won't need named blocks in the end, only "if", "while" and subroutines. No redo, but tail recursion.
http://fruiture.de