Programming alternative pasts

Social
1

Positing alternative pasts is a thing and many books and movies have been produced wondering what would have happened if some event of history had not worked out as it has. What if Carthāgō dēlenda est was never achieved? What if the lightning bolt had killed Martin Luther rather than scaring him into taking holy orders? What if Jobs and Wozniak had never met?

Somewhere back in the dim and distant people gave instructions to computers using switches, then teletypes and then terminals. What if we had had to speak instructions to the computer from the outset? Would we have had punctuation-heavy languages like the C-family (viz, “if open-parenthesis exclamation-mark file dot exists open-parenthesis open-double-quotes” etc)? How might we have represented these languages visually? Could a programming language exist that doesn’t require a keyboard?

I can almost imagine someone reading FORTH.

2

Yes, programming languages exist today that do not require a keyboard. The keyboard is only an input device, and one of many.

If the question is “Doesn’t require letters?” instead, there are those as well. Whitespace is such a language, and I think we have recently heard talk here of Piet, a language that uses color.

3

So can you prepare a video demonstrating yourself programming in “whitespace” without using a keyboard? And similarly for Piet, how do you prepare a Piet program for execution?

4

I would imagine a Piet program being prepared using oil or water colors.

I would imagine a clutch or tone detection (like we do for telephone inputs) for whitespace entry.

Morse code is another interface that did not require a keyboard (though, yes, a key pad was used).

5

Alternative past: Redefining the text editor

OK this is kind of weird. I was giving a presentation once where I was going to live-code Minesweeper in Clojurescript.

I wanted to avoid the situation where the audience doesn’t quite know where the live-coder started from, i.e. how much of what they’re doing is dependent upon the development environment, so to create an experience where it would feel like we were all on the same page, I purposely showed up without a computer so that I would be forced to do it truly from scratch on someone else’s machine.

When it came time to write the first text file, I knew everyone would be thinking, “What text editor are they going to use?” Vi? Emacs? Or a web browser in disguise?

So I decided I was going to disappoint everyone and not use any. I opened up the terminal and typed:

cat > core.cljs

I wrote my initial code, hit Ctrl+D and enter. (It was a bit confusing because the person had bound their Fn key to Ctrl and vice-versa, but I recovered quickly).

The cool thing about doing it like this is that everyone could still see all of the commands in the terminal above where I was writing the file. No clearing of the screen, no disrupting the flow of commands. Often when I’m doing a demo, or even just following a tutorial, say I forget to open a separate terminal to fire up my text editor (or can’t because it’s just a TTY, or there’s limited screen space), I experience a tinge of anxiety (or a lot) because my ADHD brain loses the context of what I was doing in the terminal. Then I cannot refer back to my command history until I then exit the editor, at which point I can no longer see the text file! Oh, the agony!

The problem is, you can only do so much with cat. Not only is there no multiline editing, you can’t even backspace! So it’s really only practical for quick one-off files. what I want is a more fully-featured, multiline ed.

The vi editor was in fact originally built as the visual mode for ex, which was from the lineage (no pun intended) of line-based editors like ed, and obviously this solved a major pain point and drastically increased productivity. But what if through this transition we actually lost something? I believe that something is mental continuity due to the screen-clearing. Practically speaking, this is a necessary consequence of needing to assess the dimensions of the terminal in order to calculate the rendering positions, and provide a full-screen visual experience akin to a nice, blank slate to begin one’s work.

But what if we had ameliorated that pain-point another way, and instead increased productivity by creating a more polished line-editing experience? I have often toyed with the idea of building a text editor that just sits there in your terminal and completely stays out of your way.

The closest thing I know of to this is a Clojure REPL called Rebel Readline by Bruce Hauman. I’ve taken it as a source of inspiration for how to practically build it and what it would look and feel like. It’s actually a really nice multiline experience with syntax highlighting, autocompletion, variable lookup, etc. All that is really missing is the ability to save files. And it’s a Clojure REPL, not a text editor.

Initial experiments:

BTowersCoding/med: Multiline text editor (github.com)

6

I like this, and have done similar with ex (EXtended editor) for this purpose as well. Keeps distractions low, and I had noticed the same thing, less distractions.

1 Like