# The 'mind blind' approach

Read the article about the 'mind blind' approach to

• a) drawing / art

• b) block-based programming (in my comment under the article here).

Interesting. I guess I believe it about artists, although I hadn't heard of this before, but I'm not sure about programmers. You seem to be suggesting that non-mind-blind block-based programmers visualize (as in "visual"!) their programs before writing them. I'm quite sure that's not true for me, and not because I couldn't. The visual appearance of the program just isn't important (just assume "to me at least" at the end of all future sentences in this post). Blockness is important, in the first place, to make programming less intimidating for beginners; that's why we use saturated colors and Lego-looking command blocks. The other thing that's important is that the palette serves as a kind of reference manual cheat sheet, a reminder of the language's repertoire of behaviors. The different colors are like chapters in the manual, grouping procedures by purpose.

As a teacher, I do find a kind of visualization useful in thinking about complicated programs, but it's not visualization of the actual code. Here's an illustration I made for Computer Science Logo Style:

In the diagram, I've circled the names of seven procedures. If you understand the purpose of each of these, then you will understand the general structure of the entire program. (Don't turn to the end and read the actual procedures just now. Instead, see if you can understand the following paragraphs just from the diagram.)

Ttt is the top-level procedure for which I gave a rough outline earlier. It calls initialization procedures (draw.board and init) to set up the game, then repeatedly alternates between the human opponent's moves and the program's moves. It calls getmove to find out the next move by the opponent, youplay to record that move, then pickmove to compute the program's next move and meplay to record it.

Make.triples translates from one representation of the board position to another. The representation used within ttt is best suited for display and for user interaction, while the representation output by make.triples is best for computing the program's strategy. We'll look into data representation more closely later...

It's not a picture of the code, but a tree structure of the subprocedure/superprocedure relationships. (Not a flowchart; the lines don't represent a sequence of events.)

And this picture represents a Logo program, not a Snap! program, emphasizing the point that it's not a picture of code.

One lesson here is that there no one-size fits all approaches to constructing programs. Or thinking about them.

About 30 years ago I was giving a talk at the MIT AI Lab about a visual programming language I was working on and Richard Stallman kept interrupting my talk with many negative comments. Afterwards he came up to me and apologised saying he was so critical because he personally saw no value in what I was presenting, but by the end of my talk he understood that what I was talking about was valuable to a subset of the population who thought differently from him. And spreading programming to those people was a good goal.

That sounds so Richard!

As someone with aphantasia, I can relate to the Glen Keane's experiences when it comes to drawing.

I can't speak for everyone, but my mind "blindness" is limited to "sight." While I can't imagine sheet music, my audiation (i.e. imagination but for sound instead of images) is perfectly fine. Similarly, I can't imagine blocks or flow diagrams, but that doesn't prevent me from having a good sense of program flow before actually writing any code. Since my first programming language was Scratch, I started out using the tinkering approach to programming, but I've gotten into the (probably bad) habit of writing hundreds of lines of code before testing when starting a new program. The programs usually work fine after fixing a few typos. So I can say for certain there's no one "mind blind" approach to programming.

Wow, I thought I knew everything about you! :~)

On a related note, I've noticed that I make a little bit of use of the possibility of 2D layout of scripts in Snap!. Though I avoid horizontal scrolling so I don't use the x dimension as much as I otherwise would. But I wonder if it was friction free whether I would organise my scripts in a plane and have a sense of neighbourhoods and a mental map of where components are.

P.S. I also have aphantasia (though not in my dreams).

In my own Snap! programming, I never use 2D except as a buffer for a chunk of code I'm moving or copying from one place to another. But when writing projects for pedagogic purposes I sometimes put two scripts next to each other to point out symmetries or commonalities between them. (A common example would be a set of four scripts to respond to the user typing an arrow key, arranged in a diamond.)

Had to search that up (it is an adjective "relating to teaching", only word I know of with that meaning)

Most keyboards (not mine, though) have the arrow keys arranged like this:

  ___
__|^|__
|<|v|>|


Yeah, that's a compromise between what they mean and the preciousness of keyboard space.

My up and down arrow keys are squashed to be in a one-key space.

Oh, even more of a compromise!

12 posts were split to a new topic: Fantasia

Your up and down arrows together are the same height as your left and right arrows?

Same here.

kinda like that game maker thing

Inspired by you, I tried to make something similar for my Text Editor project.

I wonder if it would be possible for Jens to automatize constructing of such connector diagrams between all the 'broadcast message' ('and wait') blocks, on one hand, and all the 'when I receive message' blocks, on the other.

What do you think? Would this be possible?

More here.