I found that indentation in programming languages like Python, at least with some of my students, seems to be a point of confusion. This idea of introducing spatial thinking and jumping around seems to conflict with our learned way of reading text on a page. The closest thing is textual paragraph indentation. Maybe there are some studies that contradict me, but couldn’t braces or begin/ends actually be better? Or something built-into the editor. Why couldn’t this be acceptable?

# instead of:
if bla:
    do_bla()
   if blabla:
       do_blabla()
   else:
       other()
else:
    other()

# do
if bla {
do_bla()
if blabla() {
do_blabla()
} 
else {
other()
}
else {
other()
}

Okay it’s hard to read, but it makes me think: any block of code could really be its own function, and suppose we had a kind of function that was purely an inline macro to jump to without any stack rules. The goal would just be to make code look as procedural/linear as possible.

if bla do_bla() else other()

#define do_bla somewhere somehow in a way that keeps the same scope without param/stack rules

Sure this would probably require more annoying steps and jumps for some, but I do wonder how it might impact early learners or maybe prove useful (or not useful) for understanding control flow Maybe if an editor could automatically inline code folding off and off with these macros… Probably more of a structured/dynamic editor that isn’t just pure text. I’m sure this path has been followed before, but I wonder. It’s really just closer to ASM languages with the conditional jumps and islands of code. Strangely, I find those pretty not so hard to understand. No nesting.

Yeah, this feels like a solid case where learning recapitulates the historical path. Control flow is just syntactic sugar for GOTO statements; and function calls are just GOTO with a stack, as you suggest. How to Design Programs has an excellent deep-dive on the whole learned wisdom here. I wish someone had pointed me at this book in undergrad. https://htdp.org/2024-11-6/Book/part_preface.html#%28counter._%28figure._fig~3athe-design-recipe%29%29

Ah thanks. I’ll take a look. Is the “spoiler” that there’s a reason it has to be this way, or is it worth exploring again? I also thought a custom editor could reduce the amount of jumping around by just artificially inlining code temporarily.

That would be the scope and encapsulation, yes. I've been chewing on membrane computation one of the anti-encapsulation substrates; instead of a call graph, think reaction pathways.

I’ve not heard of membrane computation. Strangely though I still think forward gotos make a lot of sense. Or at least one way I think of it is as train tracks.

I'm really just going off of Isaac's generative poetics from his thesis. I thought he'd written about the 'bag of recombinable operators' as kind of the self-assembling Lego bricks, if the bricks were train tracks in your analogy.

This is all new to me. Interesting. Basically, I’m trying to find new ways of teaching this. Or coming up with new tools to make it easier to visualize paths in languages that force this style? — I could probably draw/mock-up something.

Ah, you're trying to get at something visual, does this example of code folding do the thing? https://mastodon.gamedev.place/@johnaustin/113845457744971617

Oh that’s cool. Not exactly only visual. It’s both “what would a textual language look like” and “how could I visualize what I’m doing more easily?” More like, you know how gpu code often unrolls loops? I’d like to be able to do that for code I’m reading. e.g. branches, function calls, struct/type definitions. As opposed to jumping to a different line or file. I think it’s already somewhat possible in existing editors, but not explored deeply as a default feature. EDIT: oh when I said I could make a mockup, I meant that to explain what I’m thinking about, I could draw something,

Ye, visualization of compiler internals is juicy

• non-programmers learn to sequence steps of a recipe in a flat, numbered manner without using indentation • when recipes (programs) get big, non-programmers resort to hot-links or node-and-arrow sketches that show data flow (not control flow), or, ... nothing, in which case they get into trouble (aka "... add more tabs to the spreadsheet ...") • programmers use scoping and indentation of blocks of text because 1950s hardware could only handle text, and, because textual scoping was the best way to structure text to show that some actions were constrained • when programs weren't so large, programmers laid out software in a non-indented manner (assembler, punch cards, BASIC) • when programs became big, programmers just did "more of the same", wasting brain power on work-arounds like textual 'imports' statements and complicated namespacing tricks to enable them to continue using 1950s text-only notation • this approach brought along baggage like "global variable" issues caused by visually-open notations like "{...}" that visually-closed notations like closed figures - boxes and ellipses - would have prevented, given that programmers had already learned how "not to colour outside of the lines" back in kindergarten • unfortunately programmers continued to find work-arounds to text-only-based issues instead of simply switching to a more suitable representation

Super interesting. I wonder what the data flow recipe arrows look like though. I’d be curious to experiment with the other representations more. Clearly we don’t have to use just text. Hotlinks make sense.

data flow notations: • what I call "0D" (node and wire stuff, scroll down the README to the pictures): https://github.com/guitarvydas/0D • FBP: https://jpaulm.github.io/fbp/ control flow notations: • StateCharts: • https://drakon-editor.sourceforge.net (click on "learn more..." then the 3 tutorial PDFs) [more will likely come to me in a few hours - keep prodding me if interested]

Thanks a lot for the references, and thanks for your patience. I imagine I appear as though I’m just walking along already-explored territory.

I don't know if anyone has said it straightforwardly... So I will share my simplistic answer. before whitespace mattered, it didn't. Brackets did. Brackets were hard to read the nesting level of, so people indented the contents. At which point the information conveyed by the indentation made the brackets visually redundant. But it's useful for parsing to know precisely if a new sub-scope is intended, so they made a new, deeper indentation level equivalent to an open bracket, and returning to a previous indentation level equivalent to as many closing brackets as required. As a learner, once I had the idea in my head that a deeper indentation level is a subscope, and the parser is counting spaces to see where it ends, my issues with whitespace went away. If I was trying to teach it, I would show the history. Good luck, and apologies if all that is obvious.

That all makes sense to me. I think part of this is teaching the concept of branching in the first place, in addition to the history. Also, subjectively, I think it’s hard to read where a scope ends without an end delimiter. Easy to miss one. That’s the part I think something like Ruby does better. In terms of inventing a new visualizer/extension to a simple IDE, I wonder if it’s worth playing with it.

Always. Play is what we are for. 👍🏻

It’d be best if it led to something, but yes.

I share the desire to make a difference. I have always been most effective at that when I was playing. I think because the effort is sustainable. But if you want something to come of it, just share your prototypes here. You will think of things that are new, or validate other ideas. Either way we win.

That’s true. To be honest, I’d really enjoy an opportunity to work on a team towards a project or paper. It means a lot to get ideas out there.