Semicolons in THT

A design note from my work on THT, a programming language for building websites.

There seems to be a trend in programming language design to remove semicolons as statement terminators.

So instead of this:

let greeting = ‘Hello World’;

You have this:

let greeting = ‘Hello World’

As a fan of simplicity, I can see the appeal: most programs have one statement per line, so semicolons are mostly redundant.

Newer languages like Swift make them optional. Ruby and Python seem to be successful without them.

So why are semicolons required in THT?

It mostly comes back to the main design principle for THT: to be familiar to both PHP and JavaScript programmers, because they are the vast majority of the millions of web developers.

PHP has semicolons. In JavaScript, they are optional, but most style guides require them because of potential bugs that come from relying on automatic semicolon insertion (ASI).

Still, I kept wondering if semicolons were a big enough problem that it was worth deviating from PHP and JS.

Eventually, I decided no. For a few reasons:

1)  They are easy to type. The semicolon key is on the home row of the keyboard, and does not require a Shift keystroke.

2)  They are visually lightweight (very little extra “ink” on the screen). At the same time, they are visible enough to notice when you’ve left one out.

3)  Forgetting semicolons might be a common mistake for novices, but after a while, they become muscle memory. In my experience, it’s not a common source of annoying typos. (I overlook commas in JS objects about 100x more often.)

4)  It’s possible that semicolons make line endings more consistent in a way that gives the reader another visual hint at the program structure. For example, most lines will end in “;” or delimiters like “{ … }”.

5)  My initial prototyping showed that removing semicolons would make the parser more complex. Newline characters have to be interpreted in multiple ways and there are no obvious rules for when a line should continue.

I know other languages like Python manage to solve this reasonably well, but I found it is not as straightforward as it first seemed.

6)  Typographically, it’s natural to have a visual terminator in human languages (i.e. a period at the end of sentences.)  I think it’s ok to have a little redundancy here, both for humans and compilers.

So I believe semicolons are right for THT, but I don’t have a strong opinion about it in other languages.

In fact, if I were designing a language completely for myself, I would probably omit them.

As with other programming language design topics, it would be great if there were more usability research available, especially based on eye-tracking.

For more fun on the topic, here’s an older exchange with Larry Wall, on why Perl has semicolons:

Creating with Concept

When you hear someone talk about the “concept” behind their work, you might be skeptical that they are hiding behind… well, intellectual bullshit.

Like this painting, for example:


Melancholy Paradox & Metamorphosis II

by Joe Lesko (Price: $3,500,000)

Regardless of how you feel about modern art, I have found concept to be one of my most powerful tools for all kinds of creative work.

I was personally inspired by the book Basic Design Index, by Jim Krause:

Concept is abstract, intangible, and untouchable — and yet, without its binding influence, the elements of a design fall from the page and land in the gutter.

Concept is notion; idea; direction; look-and-feel; the point behind the point.

In other words, concept gives a creation — whether it’s an app, a story, or a game — a sense of wholeness. It pulls all of the parts together into a clear sense of identity that the viewer can connect with.

Concept is that intangible quality that makes something feel well-designed.

Imagine a spiral galaxy like the Milky Way.   There is a massive black hole in the center, which is completely invisible (by definition!). Yet, it’s so powerful that you can see its presence on the billions of stars swirling around it.


Concept is the gravity of design.

So for any given element of a design, I always ask:  “How can I make this relate to the central concept?”

I first applied this approach when I was designing Totally Tiny Arcade.  I had planned around 30 arcade minigames, all tied together with a meta-game that involved navigating the arcade itself.  I was overwhelmed with hundreds of design decisions that I had to make on my own.

How was I to know if I was making a good decision at each point?

I kept going back to the concept, which I imagined as “A wonderland of 80’s arcade games.”

From that idea, I had the main character literally fall inside each minigame, like Alice falling into her imaginary world.  I filled each game with absurd enemies, hidden treasures, crunchy 8-bit bleeps, and 80’s synth music.  Everything – from the screen transitions to the pattern on the carpeting – was informed by (and in turn reinforced) this one idea.


Totally Tiny Arcade (PC, 2007)

The danger of designing without a concept is that you often end up with a Frankenstein of ideas, all mish-mashed together.

You often see this with new game designers who want to throw all of their favorite mechanics into a single game. e.g. “A massively multiplayer side-scrolling arcade platformer with RPG elements. And a crafting system.  And a puzzle-based tactical combat system.”

When you describe something simply as a list of features, that’s a warning sign that there is no clear concept.

A good concept will help you decide which features or ideas belong in the design, and which ones should be cut.  Sometimes that means cutting something that you really like.

But in return, it will help narrow your focus to something you are more likely to finish, and the final design is more likely to click with your audience.

How to Name Things

Coming up with a name for a project, game, or business can be really difficult.

I used to get attached to the first clever idea I came up with, as if it came from divine inspiration.  But I eventually noticed that my first ideas were often very similar to the ideas that everyone else comes up with.

For example, if I were naming a Pet Grooming company, my first idea would probably be something like this:


But if I were to take a step back and do a search for “pet grooming” in the local area, I would see a list of companies like:

  • Bow-Wow Bath Time
  • K-9 Kleaning Krew
  • Purrfect Pawlish
  • etc.

It’s clear that “Wash-N-Whiskers” would probably get lost in the crowd of other pet puns.

So nowadays, here’s how I avoid coming up with “samey” names:

  • Make a list of the names that are already out there in the same category.
  • Put them in groups, to figure out what the common themes are.
  • Think of ways to break from those patterns in an interesting way.

For example, when I was coming up with a name for my tabletop roleplaying app, a lot of the existing apps had techy sounding names like MapTool and D20Pro.

I named mine Fabletop — to capture the storytelling side of tabletop roleplaying.

What would I have called my hypothetical pet grooming company?

I would avoid pet puns and maybe try something more serious, like “J Lesko, Expert Pet Stylist“.

Or maybe something that sounds like a high-end salon, like “Animalé“:


In this case, the name itself would help me re-think how I could make my pet grooming company unique. That’s what the art of positioning is all about.

For more about naming, I highly recommend this guide:

The Igor Naming Guide