New Essay, Office Hours, and a short essay

Workshop Sold Out

The Alloy workshop is now sold out. Dang, that was fast. If you're still interested in this, please add yourself to the waitlist. If enough people add themselves the waitlist, I'll add a new day.

(Also, I've heard some people talk about being interested in a "European" schedule, so something like 2 PM to 10 PM central time. It is something people would like? I see no problem with that if there's interest.)

Office Hours and Screwup

Last week I said I was going to do an experimental timeslot but didn't actually include a room or password. Oops! as an apology, this week were doing both the experimental timeslot and the normal one. So:

• Dates: 8 PM Thursday CST (1 AM Friday UTC), 11 AM Friday CST (4 PM UTC).
• Zoom room: 559-533-7339
• password: coriander

As before, these are general office hours. Ask anything you like, though I will prioritize things about formal methods and what I do professionally.

New Essay

The Hard Part of Learning a Language. It's the final version of "Why Python is My Favorite Language", which I shared as a newsletter post a while back. Only two major changes: first, I made the title a lot more obviously about the process of learning languages, so that people wouldn't mistakenly think the essay was actually about python. Two, I cut out the entire discussion of how programming communities can fix these issues. It wasn't worth the words.

(Speaking of wordcount: this is pretty short for a standard essay! Excluding the Alloydocs announcement, the last sub-1000 essay I wrote was Python Negatypes, way back in September. That's a lot more recent than I thought!)

Terse Programming Languages

I've been on a vim kick lately, haven't I. In addition to the newsletter rant I shared on Friday, I also made this rant on twitter:

If you don't like reading tweets, the gist is that by turning your keyboard into 100 buttons, you can add all sorts of special-purpose commands that integrate into a person's muscle memory. It got this response:

For those of you don't know, APL is an extremely dense programming language. I'm not familiar with APL, but I do know enough J to be dangerous:

100\*(%+/)#/.~/:~(+/"1)0.95&<?500000 17$0

Very similar to vim, in that you can do very complex things with just a couple of keystrokes. It is very dense. And in fact I think about these two languages in the same way. Both languages excel at something that isn't quite interactive programming (because that already is a taken term), but a sort of feedback-oriented programming. Write a tiny bit, transform the system you're working in, write a bit more.

These two images share a couple of interesting and unusual things in common. First of all they are easily reversible. If I do the wrong thing in J, I just need to change a couple of characters to do a different thing. And in vim, any text transformation can be undone with the u key. It's no big deal if you make a mistake.

The other thing is that they emphasize very short commands over very descriptive ones. In J, +. is the Greatest Common Divisor verb. In vim, dt; will delete everything up to the next semicolon. They each also have small variations on core commands: in J, we can instead write *. to get the Least Common Multiple. Whereas in vim, we can type df; to delete everything including the next semicolon.

Generally we think that descriptive beats terse, but in the context of feedback-oriented programming terse has a major advantage: it's easier to type. When I'm writing J, I'm often trying something to learn something about the data, and then designing new things to try based on that, and occasionally deciding I hit a dead end and trying something else. If I had to type greatest_common_divisor() then any sort of change, addition, change, reversal adds that much extra overhead to my scripting. If I decide when writing prose that I should move the line at 10 to line 100, I can do that in vim by just writing :10m 100. That makes it easier to actually make changes.

(This reminds me of how data scientists will always use variables like x, df, n. It's harder for people to understand easier to write it out in the first place. As much as we value clean code, it seems that when it comes to actually writing a lot of code people naturally prefer writing terse code.)

(It also reminds about how I started using archive.org and sci-hub a lot more once I added AutoHotKey shortcuts to Firefox. When something is easy, we're more likely to do it in the first place. This includes writing scripts.)

No good conclusion to this one, just me throwing thoughts out.

If you're reading this on the web, you can subscribe here. Updates are once a week. My main website is here.

My new book, Logic for Programmers, is now in early access! Get it here.