2019-05-28: Trnx exercise ideas; managing discomfort; language vs visual programming

I'm trying to get back into the habit of doing & making, after some years of accumulated fear around this. So this will be much rougher than my usual efforts. Read at your peril.

Idle thoughts, exercises, & ideas

So what are our exercises we're going to have fun with? Some ideas in rough order:

  1. Hello world
  2. Hello world loop (different forms)
  3. Fizzbuzz
  4. Fizzbuzz Print-if-divisible (stalled by lack of a stack)
  5. Stack to achieve subroutine calls with returns
  6. Macro to make call & return more fun
  7. Stack based concat lang like forth
  8. Notes app to require arrays, and illustrate heap
  9. malloc to illustrate stack & heap working together
  10. Quiz app

Another idea: at the moment we're just reading and writing plain text (apart from labels, sort of). Instead, write could have access to the AST and/or fill in placeholders maybe? E.g.

next: 2
write #3.args[0], "Hello, world!"
print "" // Or even a 'hole', like _

Tolerance and self

At some point in my projects the shine dips for a bit and I start to fear & maybe resent the work a little bit. This is where I often drop them. Previously I thought that this was unfortunate, and the only real solution is to push through it. I was right, but not in the way I thought. I was never really very good at it.

It has been reassuring to discover the split (black & white thinking) at the root of this — my belief that I will either do whatever I want all the time (euphoric but ultimately unsatisfying and gets me into bad situations), or have to do whatever everyone else wants me to do forever (very scary, since I can't defend myself against the needs of others). So my projects would get to a less enjoyable bit and suddenly I'd flip from seeing them as totally joyful to being something that my obligations to others were trying to force me to keep doing against my will.

In reality of course there is a place between these two things. Something one generally enjoys can have unenjoyable parts, which are something you endure to get the nice parts. To put it another way: I can endure frustration or boredom in service of my own enjoyment, not just the enjoyment of others.

This may sound like a small thing but it's actually very big, and I think it's one of the key compromises that constitutes a functioning self. Masterson has 10 things he thinks that having a self nets you, and two relevant ones are: the ability to soothe painful feelings, and the ability to make and stick to commitments. These things require that you are making these efforts for an entity — and the if we expect to achieve fulfilment as people it has to be our selves at least some of the time. So doing these things requires the construction of a sort of subject who I might ensure pain for.

And then when I actually experience this, and decide to endure pain for my own interests, I teach myself that pain doesn't have to be so scary and so self-destructive. It can be self-constructive, too.

Which means when I get bored, I am no longer faced with either:

  1. Continue with the project and be destroyed by the immense pressure of the universe upon me.
  2. Drop the project and pursue immediately enjoyment only, therefore never completing anything.

But instead, option 3:

  1. Make a decision based on both the long and short term prospects of the project, e.g. whether I will really enjoy it, how much tedium there is, what I want out of it and how important that is.

That decision might also not be DROP or ENDURE, but also an adjustment or a break or some other middle ground — backed up with a history that I can follow through.

Which is real nice.

Language-based programming vs visual programming

So everyone's obviously super into the whole Bret Victor thing, which... well I need to re-read but I have a straw-man-like summary in my head that says something like 'programming ought to be more than just text-based' (whether Victor actually believes this I have no idea), and a lot of people have been riffing on this and of course somebody somewhere is always working on a visual programming language.

And I've always been very skeptical of these things, but never really challenged myself to say why. I imagine one say I'll write something like "in defence of language as a means to program computers", so I wondered about what my argument might be, especially considering I'm creating a programming language right now.

I suppose my initial head-feel is "we have this extremely widely used tool (language) for communicating complex processes and ideas, that we always jump to first and even when we abandon it it's only so we can construct some new idea that we can then jump back to language to use again".

Another part of this argument is my belief that programming languages are languages first and programming second. They're a special kind of language, sure, but it's essential to remember that they're in this category.

And then I was thinking the other day, what is it that makes language so useful a tool for programming, and why does visual programming always feel so disappointing for serious work.

So I observed: it feels like visual programming absolutely requires you to be in front of the interface. The idea that I would walk away from the screen and still be able to come up with the solution feels wrong — I would have to start visualising and that would get quite annoying.

Whereas language, somehow we manage to thread through a bunch of complicated ideas in a working-memory efficient way. We have this very nice idea of sequence that somehow we marry up with the non-sequential nature of ideas. You read this sentence one word at a time, and you end up with a full idea in your head. Same with writing it.

Which is a rather neat trick. Describing even a simple sentence's idea in a visual form usually requires us to bust out the whiteboard — very challenging to do mentally.

And I wonder — maybe this is why language is so suitable for programming computers. I can interact with code by reading it into my working memory, making some transformation on it (e.g. to add some functionality) and then write it out. This means more of the work can happen in my head, and as I become a better programmer even more of it can. This both feels and is much more mentally efficient — which means we can be much smarter while we do it.

Whereas visual languages one is required to constantly be in dialogue with the medium — because you can't take so much of it into your brain and then write it out again. You have to operate in very small pieces, which is challenging. This is why you can't easily think about visual programming problems while brushing your teeth, but language programming problems you can.

To try to summarise: language is a way to express complex, non-linear things in a linear way. Programming is a way to perform complex, non-linear tasks in a linear way. That's why they are a very nice fit.