humancode.us

A ranking system for vanity plate inscrutability

February 3, 2024

I propose these levels of understandability for (California1) vanity license plates, from most inscrutable to most understandable:

(Most inscrutable)

  1. Physical comedy, where you have to manipulate the plate to get it: X32TTU8 (read it in a mirror), 3SI73 (flip over to read ELISE), BLONDE mounted upside-down.
  2. Inside jokes. Only 4 people will get it: N4BLOOP. What the hell does it even mean?
    • 2.a. Uncommon language plates. I think this one is a subcategory of Inside Jokes because most people have no idea what they mean.
  3. Topical memes for the Chronically Online: COVFEFE, SKIBIDI.
  4. Nerd references: NCC1701, GANDALF, FFFF00 on a yellow car.
  5. Car People Things That Only Car People Get: 997C2S, RMR6MT.
  6. Car People Things That Non Car People Get: GO2FAST, REVVIT.
  7. Major sports teams: 40NINRS, KCHIEFS.
  8. Description of car ownership: WIFEYV8 or BOBSLEX.
  9. Names and nicknames: SLAPPY,JIMBOB.
  10. Nouns: 3LATTES, SHIHTZU.
  11. Common phrases: BRUHH, OHWOW, LOLOMG.

(Most understandable)

Did I miss anything?

PS: I think EV jokes like GIGWATT, LOLOIL, HIGHI2R belong to Car People Things that Only Car People Get. It was suggested that Tesla plates should get their own tier, but I think they belong on an axis of insufferability that is orthogonal to this ranking system.

PPS: There are two other orthogonal axes that exist for vanity plates. The first is getting it which is how well the plate combines with the car in a satisfying way, and the other is insufferability which is how insufferable the car owner looks because of the plate. A plate that says IMRICH on an old beater is funny and not insufferable, but the same plate on a million-dollar car is not funny and very insufferable.

  1. This ranking is based on my experience with California license plates. For what it’s worth, California license plates are typically limited to seven alphanumeric characters, and maybe a space or half-space if it fits. 

Always be making

January 13, 2024

Magnetic domains in a ferromagnetic material aligned by an external magnetic field

By MikeRun - Own work, CC BY-SA 4.0

I like to think of myself as a maker. I like to learn skills and construct things. But all too often, I get so discouraged by my daily busyness that I forget to want to make something. When I get an unexpected stretch of discretionary time, I sometimes don’t know what to do with it: I spend it doing random chores, playing games, or just resting—all very good things to do—but I leave a lot of potential on the table.

We often complain we don’t have time to do what we want. But the truth is, even the busiest adult has some time at their discretion; it just comes in tinier chunks. An hour here, 15 minutes there… but taken together, it adds up to a lot. The question is: when one of these precious opportunities falls in your lap, would you know what to do with it?

Read more…

Thoughts on generative AI and responsibility

January 8, 2024

Here’s an illustration of a rudimentary mental model that I use when thinking about advances in computing tools.

x-y graph. The x-axis is “resources” and the y-axis is “skill”. Concentric circles are drawn about the origin in the positive quadrant. The closest to the origin is labeled “Anyone can do it”. The next is labeled “Experts only”, and the last is labeled “Impractical”. A red line shows a dot moving from “Experts only” to “Anyone can do it”.

Computers are already (essentially) Turing-complete, so anything that can be done can in theory already be done using any existing technology. But what these leaps do is that they bring down the skill and resources needed to accomplish a certain task. The red arrow in the image is what such a leap does.

Generative AI is such a leap. The red dot represents not only something genuinely useful that people used to have to learn a skill or pay someone to do, but can now do with ease (removing a distracting object from a photograph), but also vectors of abuse that similarly gain the same level of ease (crafting misinformation, generating fake revenge porn). With every leap, thousands of these red dots move toward the origin, some good for humanity, and others bad.

Read more…

All about libraries

January 3, 2024

After writing the post about mergeable libraries, I thought I should write a post about how libraries work in general, and capture some recommendations on how to use them.

Let’s start at the beginning, with what happens when a source file is compiled.

A compiler creates object files from source files

A compiler takes a translation unit (a source file with any imported headers), and produces a compiled object file, containing the code and data defined in the translation unit.

Exported symbols

An object file may export symbols. Exported symbols are strings that identify data structures within the object file, which may be function implementations, constants, initialized data, whatever.

// sound.c

static int tweetCount = 0;

extern void tweet(void) {
    tweetCount++;
}

The file above compiles into an object file sounds.o which exports the symbol _tweet for the implementation of the tweet() function1 2.

Some symbols are purely internal to the translation unit. tweetCount, for example, is not exported.

In addition to open/public (exported) and private/fileprivate (not exported), Swift symbols have an access control option, package, which makes the symbol visible only within a Swift package. As far as libraries are concerned, package symbols are exported.

  1. By convention, C functions are exported with a leading underscore. 

  2. By default, C symbols are exported unless marked static. You can flip this behavior by setting GCC_SYMBOLS_PRIVATE_EXTERN = YES, and using visibility attributes to export symbols. 

Read more…

Measuring the performance of mergeable libraries in iOS apps

January 2, 2024

I was curious about what the use of mergeable libraries meant for a typical app that may have a lot of library dependencies, so I devised a test which would measure the performance of merged frameworks versus old-school dynamic frameworks.

To read more about how mergeable libraries work, read this post.

The results

Let’s start with the results. These were taken on an iPhone 14 Pro using Instruments.

Graph. X axis shows number of frameworks from 0–100. Y axis shows time to UIKit initialization. First series: “individual frameworks”. The line goes from around 40 ms at zero frameworks, to about 60 ms at one, and rising linearly to just over 600 ms with 100. Second series: “merged frameworks”. The line hovers around 50 ms, and stays flat and rises slightly to just under 100 ms at 100. Third series: “merged frameworks with intermediate non-merged framework”. The line remains about as flat as the second series, but at a slightly higher plateau around 80 ms. The line rises steadily at 70 to reach about 180 ms at 100. Fourth series: static libraries. The line stays flat at around 30–50 ms.

And here is a close-up of the region around the origin:

Close-up of the previous graph around the origin

As you can see, the difference is dramatic. Virtually all of the O(n) cost of dynamic library loading is gone, even when an intermediate merged framework is introduced. It’s almost like the dynamic libraries have been turned into static ones, and that is not far from the truth.

Read more…