Programmers are humans too

Apparent Rule

Looking at GA= Georgia, and FL= Florida, it appears that there is no real rule.

The first letter of the code is the first letter of the state.
If the state name is two words, then second letter of code is first letter of second word (e.g. NY = New York)
Otherwise, the second letter is an apparently random choice out of the other letters of the state name.

Codes

NE: Nevada or Nebraska?

It's Nebraska, but NB would have been a better choice

MI: Mississippi, Missouri, Michigan, or Minnesota?

Codes

NE: Nevada or Nebraska?

It's Nebraska, but NB would have been a better choice

MI: Mississippi, Missouri, Michigan, or Minnesota?

It's Michigan, but MG would have been a better choice

Codes

NE: Nevada or Nebraska?

It's Nebraska, but NB would have been a better choice

MI: Mississippi, Missouri, Michigan, or Minnesota?

It's Michigan, but MG would have been a better choice

MS: Mississippi, Missouri, or Minnesota?

Codes

NE: Nevada or Nebraska?

It's Nebraska, but NB would have been a better choice

MI: Mississippi, Missouri, Michigan, or Minnesota?

It's Michigan, but MG would have been a better choice

MS: Mississippi, Missouri, or Minnesota?

It's Mississippi, but MP would have been a better choice.

Doing it better

I couldn't believe it wasn't possible to do the 2-letter codes better.

So I wrote a program (in ABC as it happens; more on that later).

The best rule I came up with:

For single-word state names, use the 1st and 4th letter, except:
For the 4 states with a double letter in the first 4 letters (Minnesota, Mississippi, Missouri, Illinois) use the 1st and 5th letter.

The point

My point here is that the 2-letter codes were introduced because of automation.

But that is no excuse for ignoring the needs of people.

Usability

Usability is about designing things (software/programming languages/cookers) to allow people to do their work:

Faster
With less errors
Whilst enjoying it

Efficient, Error-free, Enjoyable or
Fast, Faultless and Fun

HCI

A problem is that the people designing things are usually not the people who will be using those things, and yet they tend to design for themselves.

So... you have to use HCI techniques:

design for the user, not for yourself or the computer
worry about implementation later
user test
design iteratively.

Numbers

For instance, Roman numerals:

OK for representing numbers: CXXVIII
Reasonably OK for addition:
CXXVIII+CXXVIII
=CCXXXXVVIIIIII
=CCXXXXVVVI
=CCXXXXXVI
=CCLVI
Terrible for multiplication (which was a university subject until the introduction of Arabic numerals after the renaissance)
Disastrous for division.

Homework

I was helping my children with their maths homework, and a question arose for me:

Why do they make things so difficult?

So I went back to first principles.

What would mathematical notation look like if it were designed with consistency and usability in mind?

Warning

What follows was more than a year's work, using reams of paper. It is hard work making things simple.

When you achieve a final simple result, it often looks so obvious that it hard to appreciate how difficult it was to get there.

As a colleague who designs program interfaces remarked: "When you succeed in making an interface as easy to use as a coffee machine, they treat you like a plumber"

I'm only going to show you the tip of the iceberg here.

It resulted in a monograph that I wrote for my sons' birthdays. You can read it here: Numbers.

The first declarative definition

Procedural approaches describe how to achieve something.

Declarative approaches describe what to achieve.

In school you learn procedurally how to add, subtract, multiply and divide, and then you are told

The square root of a number is another number that when you multiply it by itself, gives you the original number.

Simple
short
obvious
understandable.

This doesn't tell you how to calculate the square root; but no problem, because we have machines to do that for us.

Procedural code

function f a: {
    x ← a
    x' ← (a + 1) ÷ 2
    epsilon ← 1.19209290e-07
    while abs(x − x') > epsilon × x: {
        x ← x'
        x' ← ((a ÷ x') + x') ÷ 2
    }
    return x'
}

What does it do? Under what conditions?
How does it do it? What is the theory behind it?
Is it correct? Can I prove it?
Under what conditions may I replace it, or a part of it with something else?

This is why documentation is so essential in procedural programming, because the distance between the description of the problem space and the code is so great.

Mathematical Notation

We have addition:

a+b

You can define subtraction as

(a+b) − b = a

This is a declarative definition. It tells you the what but not the how.

Monadic −

There is also a monadic version of −, which can be defined as:

−a = 0−a

Where 0 is the identity for addition, since

a+0 = a

Multiplication

Multiplication is at its heart repeated addition:

a × 3 = a + a + a

and it also has an identity value:

a×1 = a

Its complement is division, defined in the same way as subtraction:

(a×b) ÷ b = a

(I use ÷ instead of / because when user-testing with my target audience, they said "Please use the same symbols as on a calculator")

Monadic divide

Notably, there is no monadic version of divide. But if we define it using the same pattern:

÷a = 1 ÷ a

something surprising happens: identities that we know from the lower level have exactly the same form as ones at this higher level. For instance:

Up another level

Just as multiplication is repeated addition, raising to the power is repeated multiplication:

a↑3 = a × a × a

So we can define its complement in the same way:

(a↑b)↓b = a

This is of course what we know of as root, where x↓y traditionally, and weirdly, is notated

^y√x

So if ↑ is a higher version of multiplication, then ↓ is just a higher version of division.

The point

Defining it in this way suddenly exposes literally dozens of well known identities that have a similar form to identities at the two lower levels!

Just to pick a couple out:

Identities 2

a×(÷b) = a÷b
a↑(÷b) = a↓b

(I consider this so beautiful, that even if this had been the only result, the whole exercise would have been worth it!)