Program representation (7)

On Pranab’s site

DRAFT (needs work or removal)

Show/Hide contents
  1. Syntax description
  2. Syntax features
    1. Easy translation
    2. Auto-formatting
    3. Sharing
    4. Significant whitespace
    5. Accessible
  3. Future

Visual programming is so close to text programming.

Have a look at the following code snippet and visual code.

for fruit ["orange" "banana"]
	peel fruit
	eat fruit

Block representation of above code

These are representations of the same program in the same programming language. I think their relation should be obvious.

If I gave you the following visual representation, could you guess its text representation?

Block representation for code hidden below

Answer
let name "world"
greet name

The key feature is that the visual representation is backed by the text representation stored in a plain text file. You can version control this file, edit it with text code editors, grep and cat the file, drag blocks around with your mouse and snap them together to edit it, and share the file with other people. There’s no conversion, exporting, or importing.

Like how one person can write Markdown in Vim while another edits the file in a GUI app, one person can write code in Vim while another snaps blocks together in a GUI app. And they can both use these files directly.

People can use a visual editor to learn programming without syntax errors. They can create packages used by text programmers. They can share code snippets. They can tap into the experience of text programmers.

These connected representations provide first-class visual programming and collaboration with text programmers.

Syntax description🔗

If the syntax feels a bit fuzzy, here’s how it’s put together, so that the rest of the post makes sense.

Here’s the rules for the text syntax:

Here’s the examples for the block syntax, before I explain how it relates to the text:

Block representation of first code snippet

Block representation of second code snippet

Sample blocks for function call, key-value pair, and list

Syntax features🔗

Here’s an example of both representations before we dive in further:

let name "world"
greet name

Block representation for code hidden below

Easy translation🔗

I assume you had little difficulty translating the examples at the beginning. I think most of the difficulty comes from the missing commas, equal signs, and keywords. Even Python didn’t dare to remove commas, and Clojure added them in as whitespace, though all CLIs keep getting away with it. A bit of practice should make it easily readable.

Another thing that makes this syntax easy to translate is that any constructs, like looping or conditionals, use the same layout as a function. let is a “function” that that takes two arguments — the first argument is the identifier, and the second is the value. for is a function with variadic arguments — first a variable for each item of the loop, second a value to loop over, and everything else as steps in the loop. This layout is heavily inspired by S-expressions.

let fruits ["orange" "banana"]
for fruit fruits
	peel fruit
	eat fruit

This way all blocks have the same shape, documentation is straightforward to read and write, and you get editor support for them telling you what goes where, and you can read the other format if you need to.

A simple syntax makes it easy to translate for the computer as well.

Auto-formatting🔗

This one came in at the last moment, but is quite important. How would you avoid writing block positions in the file? Using automatic block layouts, like auto-formatting. People focus on the program, not the formatting.

Sharing🔗

Sharing code snippets is just text. No need to take screenshots. A dedicated site can even translate it to whatever representation the user prefers.

Significant whitespace🔗

Significant whitespace means less visual noise, less typing, and fewer formatting crimes.

Even users of the block representation will likely have to read the text representation, and they might even need to write it on rare occassions. Additionally, text editors provide some workflows that cannot be easily reproduced with a structured editor, and others might only use a text editor in restricted environments, even though they’re beginning. Significant whitespace helps all these use cases.

Significant whitespace is also popular with beginners. Python’s popularity is a testament to this. Even the Godot engine’s Python inspired language was so popular that they remove visual scripting with little protest from their users.

Accessible🔗

Backing the visual representation with a text file gives it a base level of accessibility, and the opportunity to improve it more easily. More users will then be able to use the tools create software for themselves, and collaborate with others.

Future🔗

Here’s some future directions to ponder as I put together posts and designs for them, in rough order of importance for beginners: