some thoughts about some things

Roughly twenty years ago, I took a long camping road trip with my Grandma (Mary), covering almost every state in the western US. We drove, camped, hiked, and explored for three weeks. We also watched birds and saw more than a few prairie dogs. When we got back we had traveled 7000 miles, visited 14 states, and seen more than I’ve seen in any trip before or since.

A few weeks ago Donelle and I took a road trip to Nebraska and the Dakotas, and we saw some of the same places Grandma and I visited (including the Badlands of South Dakota and the mammoth dig in Hot Springs). Seeing those places again brought back so many memories it was almost overwhelming. It made me realize how lucky I am to have had such an amazing grandmother, to have learned so much from her, and to have spent that time with her.

It turns out I remember a lot more of the trip than you might expect after twenty years, so I decided to write those memories down for posterity. I’m including some of the photos we took as well, scanned from a very old photo album.

---

We started from San Antonio and took US 183 north through Oklahoma, Kansas, Nebraska, and into South Dakota. We didn’t stop much along the way and I remember being really surprised that 183 went so far. Looking at a map now I see that US 281 (running parallel to the east) actually goes all the way to Canada.

Unidentified rock formation from early in the trip

I don’t remember much about this stretch other than one night of camping. We stopped at some kind of reservoir in Kansas or Nebraska and pitched the tent, and it was so blustery that we finally moved the car directly against the upwind side of the tent to block the wind. I also tied a rope from the roof of the car to the top of the tent. In retrospect I think this was all probably for my benefit; Grandma was an experienced camper and had probably seen much worse.

Prairie dog (I think) from South Dakota

In South Dakota we visited Badlands National Park and camped overnight. The next morning we hiked the Saddle Pass Trail (a steep uphill climb) and part of the Castle trail. I remember it as pale, jagged, and moon-like. For some reason I was fascinated by a car we saw in the parking lot at the trailhead, and took a picture like you might see in an advertisement.

Unidentified car at the Saddle Pass trail head

Heading northwest from the Badlands we visited the mammoth dig in Hot Springs, drove past Mt. Rushmore, and took a tour of Jewel Cave. I don’t remember the cave but I can still picture the visitor center and parking lot in my head; it was cool and surrounded by tall evergreens, like Oregon or Washington.

Unearthing mammoth bones in Hot Springs SD

The last stop in that vicinity was Devil’s Tower in northeast Wyoming. We camped there, and I took lots of pictures. Pictures back then were on film (we took seven rolls of photos), so we didn’t see any of them until we got back, but I was thrilled to get one great shot of the tower. For a long time after that I had the idea that I might sell it to be put on a postcard, but I never did.

Devil’s Tower, as never seen on a postcard

We drove straight west from there towards Yellowstone National Park. I don’t remember much of the drive but I remember it being beautiful, and I remember seeing yellow-winged blackbirds by the road. That was really exciting and felt like one of my first real birding finds.

Of Yellowstone I remember the entrance station (evergreens, winding road, and a view of the park), driving around the edge of the massive lake (there was a white wood fence in one part), and seeing an osprey with a fish. I was so thrilled to see the osprey; it was the first big raptor I had ever seen and identified. I didn’t see one again for over a decade, but since Donelle and I have started birding I feel like we see them everywhere. They are still huge and beautiful.

One of the many hot springs in Yellowstone

Leaving Yellowstone to the west we drove through the corner of Montana – we got out of the car briefly so we could officially give ourselves credit for visiting the state. Then it was on to Idaho and Craters of the Moon National Monument. We camped there and explored some of the lava caves, which were fascinating and a major draw for me. I don’t think they were particularly exciting for Grandma but she humored me. We also went for a reasonably long hike; to balance out our age difference and substantial height/stride difference I carried a backpack and filled it with books and canned goods.

Further west we stopped briefly in the Snake River canyon to look for raptors (I don’t think we saw any), and then headed north to camp in Hell’s Canyon. The road to the campsite was a steep dirt mountain road, and part-way up was still covered in snow, so we had to give up and turn around. That was one of only two nights we didn’t camp; it was too late in the day to find another campground.

From there we drove north and west across Washington to Seattle. We stayed with some extended family (Aunt Frances maybe?) in a beautiful house east of town. I remember the area as undeveloped and heavily wooded. My aunt worked at Microsoft at that time and took us to the campus the next day, which was really exciting to me. We got an oil change in town (we were already 3,000 miles in to the trip) and to round out the visit we got a speeding ticket on IH-5. It may have been Grandma’s first ticket. She was *pissed* at the officer and only got angrier when she found out he had followed us past three speed limit signs before pulling her over. She was a very conscientious and law-abiding person, so I think it rankled her to get in trouble.

That night we camped at Mt. Rainier, although it was mostly still snowed in, so there wasn’t much hiking or sightseeing to do. My only real memory from this stop is a disappointing one. After we set up camp I walked back to the camp store to call my girlfriend from a payphone, and apparently I didn’t explain my plan to Grandma, so she had no idea where I was. When I got back (probably 30 minutes later) she was really worried and angry. I still feel bad about that.

I forgot until I was looking at the photos, but after we left Mt Rainier we drove to Mt. St. Helens, which still showed (and today shows) the scars of the most recent eruption. There are thousands of bare trees and Spirit Lake is still clogged with logs.

Mt. St. Helens from the road to the viewpoint

Heading south from Washington we stopped at Crater Lake. We never actually saw the lake, because the top of the mountain was covered in clouds. I remember driving up into the cloud from underneath as we made our way to the campground. We only had one evening and morning there, and the clouds never lifted, so we moved on without seeing much. Years later my mom and I took a trip there – it was beautiful and worth the wait.

South again and into northern California – the next stop was Lava Beds National Monument. The lava tubes at this park were particularly well developed, and I really wanted to explore one, so Grandma agreed to wait for me. I don’t remember if she wasn’t interested or if the trail was too challenging or what. I remember being exceptionally geeky and deciding to do a battery-replacement drill with my flashlight in an unlit section of the cave. This was probably not a good idea.

From there we drove east across Nevada, and I don’t think we stopped for much. My only real memory of that section was the thrilling sight of a huge raptor perched on a sign by the road. We slowed down to get a better look but it flew away before we could see it very well. At the time we decided it was a golden eagle, and it was another first for me.

In southern Utah we visited Bryce Canyon National Park, possibly Arches National Park (I don’t remember), and drove through Zion National Park. Of this I only remember the beautiful sculpted sandstone features from a hike in Bryce Canyon.

Bryce Canyon, or maybe the Grand Canyon

We left Utah to the south and in Arizona we found Grand Canyon National Park, Meteor Crater, and Petrified Forest National Park. I don’t remember any of the Grand Canyon, but Meteor Crater was massive and sobering. From the Petrified Forest I remember two things: firstly, I saw a raven close up in the parking lot, and it was huge. That was another first-sighting for me (what Grandma called a “lifer”). Secondly, I remember talking with another visitor about his car and realizing that you can talk with just about anybody if you want to, and people are pretty friendly in general. As an older and more aware person I now realize that my experience was heavily influenced by being white, male, straight, and middle class. Even so, the experience had a real effect on me, and after that trip I have always felt much more at ease interacting with strangers.

A friendly lizard I found in the Petrified Forest

The same lizard, showing off

One of only two pictures of me in the album

The only picture of Grandma from the album

I don’t think we stopped for much in New Mexico, but if I recall correctly we did visit White Sands National Monument. It was and remains a beautiful place.

From there we made our way back to San Antonio, and to our regular lives. For me it was summer and a part-time job, and for Grandma it was church, charity work, quilts, and probably twenty other things. I will always be grateful for her time, her teachings, and her love. She passed away in the spring of 2015.

Grandma around 2014 — Photo credit Mareena McKinley Wright (I think)

I was thinking recently about metaphors for software development. There are lots of metaphors, my favorite being the garden metaphor, but I’ve also heard software development compared to bridge-building. To me the comparison is wildly inaccurate, and for fun I decided to develop the analogy farther.

Building a typical enterprise software tool as a replacement for the Golden Gate Bridge:

• Before building starts, the designers debate for weeks over whether the bridge should be made of steel, plastic, or air gel. The virtues of air gel are touted with great smugness and the steel advocates are shown to be woefully behind the times. Nobody takes the plastic advocates seriously.
• A month into construction, the width of the Golden Gate channel doubles, and the rock underneath changes from granite to crushed gravel. Construction is delayed for a month while the bridge is redesigned. Air gel is found to be inadequate and the builders switch back to steel.
• Two months into construction, a freak electrical storm causes the bridge to entirely disappear. Construction resumes again after much wailing, finger-pointing, and an off-site backup bridge is created in Oakland.
• A week later another freak electrical storm causes the bridge to disappear again, but it’s restored from the Oakland backup without mishap.
• At 75% completion it’s discovered that the road bed will collapse whenever a Toyota drives on the bridge. The builders explain that Toyotas were never meant to cross bridges in the first place. Toyota drivers are directed to the Sausalito ferry.
• On the first day of active service, a last-minute Beatles reunion concert is scheduled in Napa Valley, causing the entire population of San Francisco to mob the bridge all at once. The bridge disappears and reappears four hours later. Everyone misses the concert.
• A year after the bridge is completed, the rock under the channel is upgraded from crushed gravel to decomposed granite. The bridge sits at a funny angle for six months until the foundations are rebuilt.

See what I mean?

Equivalence

Take a look at the following pairs and decide whether the two things are equivalent (the same):

“cat” vs. “cat”

“dog” vs. “Dog”

4 vs. 2+2

“color” vs. “colour”

“wanna” vs. “want to”

1+2 vs. 2+1

Your specific answers probably differ from mine, but I bet you said “the same” for some, “different” for some, and maybe “it depends” for some.

For instance, I’m sure we agree that “cat” and “cat” are the same. We would probably say that “dog” and “Dog” are the same thing too, at least most of the time. What about “color” and “colour”? I’m betting that most English speakers would say they’re essentially the same thing, just two ways of spelling the same word. An etymologist might disagree and say that they differ in some interesting technical sense. Someone with strong American or British pride might give you an earful.

Likewise, the difference between 4 and 2+2 is arguable. In some senses they are the same thing, since they can both be seen to represent the quantity 4. However, if you wanted to tell someone what time your kids come home from school, you probably wouldn’t say they come home at “2 plus 2 o’clock”, so they obviously aren’t totally interchangeable.

The crux of the matter is that equivalence is context dependent. Whether 4 is the same as 2+2 depends on whether you’re in a mathematical context or a social context. The equivalence of “dog” and “Dog” might depend on whether you’re typing the words into a search engine, where you’ll probably get the same results for both, or using them to start a sentence, where one is correct and the other is wrong.

So why do I care about equivalence being fuzzy? Mainly because computers aren’t very good at “fuzzy”.

Fuzzy problems

One of the most common things computers do is compare things. For instance, a tax program might compare your income against some threshold value to determine whether you owe more or less money. Or it might check to see if your age is greater than 65, to help determine eligibility for retirement benefits. Comparisons that involve numbers are generally pretty easy, so computers do reasonably well at this. But what happens when we try to compare something like a name?

Imagine you have a customer account with bunnyslippers.com. When you registered the account last year, you provided your name (Fred Flanders) to create a customer account. Each time you log in, the server looks through the list of known customers and decides whether any of those names matches “Fred Flanders”. If it finds one, it can verify the associated password and allow you to proceed.

Now what happens if you try to log in and accidentally type “FreD Flanders” instead of “Fred Flanders”? If it was a human handling this sort of request, they would probably not even notice that you accidentally capitalized the D in “FreD”. On the other hand, a computer might or might not see the two as the same, depending on how careful the programmer was being. By default the computer actually sees the letters as numbers; ‘d’ is 100 and ‘D’ is 68. So when you ask a computer whether “Fred” and “FreD” are the same, it sees two different sets of numbers, and it says they aren’t the same.

So why not just tell the computer that “d” and “D” are the same? Okay, done. Hopefully you don’t mind if Microsoft Word now occasionally replaces all the d’s in your term paper with D’s. They’re the same now, so what difference does it make?

Hopefully the problem is becoming clearer now. Sometimes we want our computers to see “d” and “D” as the same thing, and sometimes we don’t. The difference is in the context.

Computers aren’t fuzzy

The fundamentals of computing are deeply rooted in mathematics. The earliest computers were designed to calculate solutions to complex ballistics problems, and for the most part they remain glorified calculators. The only things they can really do are math and various operations on individual bits. In this sort of basic math, there’s not a lot of room for context. The number four is always the same, so there’s not much fuzziness to deal with.

As befits their mathematical underpinnings, most programming languages support operations like addition, subtraction, and the like. They also support comparisons, including tests for equality (many languages use “==” for this instead of “=”, since the latter is often employed for another purpose). These operations make good sense for working with numbers, but it gets trickier when they get applied to other sorts of data.

For dealing with textual data, computers use something called a “string”, which is a sequence of characters (single letters). “Fred” can be treated as a string, composed of the characters “F”, “r”, “e”, and “d”. Most languages allow the equality test (==) to be used on strings, and here’s where things get tricky: by default this test looks for a very strict numeric equivalence, the kind that says “d” and “D” are not the same. The human programmer may not have intended that, though; the programmer is quite often aiming for some fuzzier form of equivalence.

To deal with this, computer languages often provide various specialized ways to compare strings, which can be used in different contexts. One way is the super-strict “no differences whatsoever”, but you can also specify a comparison that ignores case (so that “d” and “D” become the same), or even a comparison that first applies all kinds of interesting linguistic normalizations to smooth out variations. The strict comparison can be used in strict contexts (e.g. verifying passwords), and the looser comparisons can be used for things like finding names in customer databases.

Identity is fuzzy too

So far, all the examples I’ve used to talk about equivalence have been simple, interchangeable things, like apples. Two totally identical red apples are more or less the same, and you’d probably be equally happy to have one vs. the other. There are lots of things like this in life, but not everything fits that description. If I were to replace your favorite old leather jacket, which smells like your dad and has years of old memories attached to it, with an old leather jacket I found at Goodwill, you likely wouldn’t be happy at all. As another example, if you repainted your red Ford Mustang to be chartreuse, you’d still expect everyone to know it was your car, right?

What I’m getting at is the concept of identity. Just like equivalence, identity is something we understand naturally and deal with all the time. Everyone understands that the lime green car you’re driving today is the very car you were driving yesterday: it’s your car, the particular car that you own. Likewise, your old leather jacket has specific unique value to you; it has a particular identity which distinguishes it from other similar leather jackets. Identity is closely related to continuity over time; the significance of your jacket’s identity has a lot to do with it being the very jacket that you had on all those previous occasions in you life.

The word “same” can refer to both equivalence and identity, even when the two concepts are in opposition (that pesky fuzziness again). For instance, if we’re talking about identity, I might say that the green car I see today is the same car that you were driving yesterday (i.e. both cars were you particular Mustang). However, visually the cars are not equivalent, so I could just as correctly say that the car is not the same today as it was yesterday.

Computers and identity

Programmers often refer to the “identity” concept above as “reference equality” (as distinguished from “value equality”, which is the equivalence concept). For reference equality we usually pick some stable identifier, such as a VIN or an email address, and use that for identity. Reference equality is often less fuzzy than value equality, but there’s still room for error; for example, if you use an email address as the identifier, do “fred@domain.com” and “Fred@domain.com” identify the same account? Probably they should.

Sometimes computers and programmers don’t pick the right type of equality to match our expectations, or they don’t implement it the way you’d expect. A good example is that term paper you wrote last week on your computer: “The Strange World of Ocelots”. You probably view that paper as having a particular identity, after slaving over it for hours. If I asked you where the paper is right now, you could presumably tell me what computer and folder it sits in. You might even have created a shortcut to it on your desktop.

So what happens when you rename the file to “Ocelots – Strange but Wonderful”? I’ll tell you what happens: the shortcut on your desktop may not work anymore. That’s because most computers consider the identity of a file to be solely a matter of the file’s name (as well as the names of the folders it lives in), and you just changed the name. Of course, this behavior seems totally wrong to the average person, because in our minds, the paper on ocelots is still perfectly well identifiable as itself.

By the way, this example does actually work in newer versions if Windows, thanks to the Distributed Link Tracking service. However, the need for a specialized service just to make this work just emphasizes the fact that this is a tricky problem.

Where am I going with all this?

The point of all this is that equivalence, identity, and sameness are hard; hard to describe, and hard to correctly implement. I don’t have any magic solutions to offer, but I believe that thinking more about this topic can help programmers write better software with less effort and pain.

Some specific ideas for programmers to keep in mind (including my future self):

• When designing new systems, think about what types of equivalence/identity might be involved, and what behavior the user will expect.
• Be careful with standard/easy ways of comparing things (e.g. operator== and Object.Equals). Does the easy way actually have the semantics you want?
• Better yet, be explicit about how two things will be compared. For instance, use function overloads which explicitly specify string comparison modes.
• Make sure you understand the language and use it as intended. For example, C# provides a very simple reference equality for reference types. It also uses value equality for built-in value types, which means you should usually do the same with your own value types (so you don’t surprise people).
• Find or build automated tools to help verify your code’s correctness. For instance, you can use FxCop to verify that you’re explicitly specifying string comparison modes whenever possible.

Are you already a user of Powershell? You should be, if you work with Windows at all. Microsoft describes Powershell thus:

Windows PowerShell® is a task-based command-line shell and scripting language designed especially for system administration.

That description is accurate but it really only scratches the surface. I would say Powershell is useful for anything from simple repetitive tasks to complex scripts or even full-on programs. For instance, my wife and I took a trip a few years ago, and we both took several hundred pictures with our respective cameras. I wanted to be able to put the pictures in an online album and have them arranged in proper chronological order. My pictures had names like P123456 and hers had names like CIMG1234; for both cameras the numeric part would increment with each picture. The problem is that standard alphabetic sorting would result in her pictures and mine staying separate. Enter Powershell: with one line of typing I was able to rename all the pictures so that an alphabetic sorting would properly show the pictures in chronological order.

That’s probably not enough to sell you on the idea, so here’s a slightly more structured pitch:

It’s great for customer support
Whether your customers are the normal kind (the ones that pay you in dollars) or the informal kind (the family members that pay you in cookies), Powershell is great for customer support. All recent versions of Windows come with it already installed, so if you know how to use it, you have a ready-made tool for solving problems. No extra work required. This can be a life saver if you don’t have access to your regular geek toolkit.

You don’t have to be a programmer
Powershell was designed to be used by non-programmers. You don’t have to understand all the rules of C# or Java, you just have to understand a few simple concepts and be willing to experiment. You can also find tons of recipes online and in print for solving different problems. You’ll find you can do amazing things with very little typing.

It will make you smarter
If you already know how to program, Powershell will help you learn to think in different ways, since working with the object pipeline is comparable to functional programming, whereas most programmers do imperative programming. Or you can stick to what you know and write it like it’s C. Or you can mix and match!

It makes a great bridge to “serious” code
Since Powershell is built on the .NET platform, it easily connects to existing C# components. This means that you can do anything that the huge .NET Base Class Library can do. It also makes a great tool for automating large applications, especially if you take the time to build proper cmdlets.

There you have it – four good reasons to learn Powershell. What are you waiting for?

I’m reading The Most Human Human and ran across the following:

I tend to think about large projects and companies not as pyramidal/hierarchical, per se, so much as fractal. The level of decision making and artistry should be the same at every level of scale.

I really like this way of looking at things, and it matches my personal experience very well. I can easily imagine our company this way. At large scale you can see big departments and projects and the decisions that guide those. Zoom in to the level of one department or project and you find more interactions and decisions, which have smaller significance, but which still take time and creativity to perform well. Zoom in even further and you find individuals, who are applying themselves to small portions of a problem space, making decisions and looking for elegant solutions to whatever bit of the problem they’re working on. Every level matters.

I’ll leave you with the following lyrics from Mandelbrot Set by Jonathan Coulton. The song really has nothing to do with the above (other than being about fractals), but it’s fun.

Mandelbrot Set, you’re a Rorschach Test on fire
You’re a day-glo pterodactyl
You’re a heart-shaped box of springs and wire
You’re one badass fucking fractal
And you’re just in time to save the day
Sweeping all our fears away
You can change the world in a tiny way

I just finished reading Coders at Work, by Peter Seibel, and it was awesome. The book is a collection of interviews with some of the most respected and well-known programmers of our time. These are Turing Award winners, inventors of languages and operating systems that have touched millions of people, and authors of the most widely known and respected computer science literature you can find.

I kept a list of notes as I read through the book, things that resonated with my own years of experience in the field. There isn’t any particular theme here, but I wanted to capture these ideas before they got away from me.

Working programs are a given

Bernie Cosell, who helped develop Arpanet (predecessor of the Internet), made a great point about the responsibilities of a professional programmer:

You don’t get credit because the program works. We’re going to the next level. Working programs are a given.

What he’s saying is that when you work as a programmer, you job isn’t done just because the program works. You need to generate something of high quality that you and your coworkers will understand six months from now, and which can evolve as the customer’s requirements change. Professional musicians don’t just play the notes, race car drivers don’t just drive around the course, and serious programmers shouldn’t be content with an ugly program just because it works.

Magic is dangerous

Guy Steele had a great way to sum up why programming is hard:

[Being] able to get a machine to do what you want is the closest thing we’ve got in technology to adolescent wish-fulfillment. And if you look at the fairy tales, people want to be able to just think in their minds about what they want, wave their hands, and it happens. And of course the fairy tales are full of cautionary tales where you forgot to cover the edge case and then something bad happens.

For example, take the story of King Midas, who wished that everything he touched would turn to gold; when granted in its most literal sense, this wish became a terrible curse.

Unfortunately for programmers, computers are the epitome of the fickle genie, interpreting us at our most literal and wreaking havoc when we don’t clearly specify what we want. Therefore, as programmers our job is to provide such excruciatingly detailed instructions that the computer can’t possibly misinterpret us and do the wrong thing. This can be one of the most frustrating things to communicate to non-programmers; it’s not magic, and translating a simple idea into code is far from mechanical.

Microsoft’s tools are awesome

Say what you want about Microsoft, but their developer tools are world-class. Most of the interviewees in this book come from the non-Microsoft parts of the programming world, and often bemoaned the lack of good quality debugging tools. In fact, it sounds like many of them do their debugging with little more than print statements. This is one of the oldest and most basic forms of debugging, and it has its place, but to paraphrase one of my favorite Despair posters, just because you’ve always done it that way doesn’t mean there isn’t a better way. A good interactive debugger is worth its weight in gold for a lot of problems, and I’m glad to be working with one of the best there is: Microsoft’s Visual Studio.

Names matter. A lot.

Programs are nominally a set of instructions for the computer to follow, but they also have to be understood by humans who come along later and want to understand or change things. A program whose code can’t be understood is in fact nearly useless, like a book written in a forgotten language.

One of the most crucial elements of legibility is using good names for things. If you write a procedure that flushes program data to the hard drive, and you call it FlushDataToDisk, a reader can immediately understand the basic purpose of the function, and might be able to skip reading all of the gory details of how it works. On the other hand, if you call it WriteStuff, the name tells the reader nearly nothing, and forces her to read the whole thing to discern its purpose. The problem is that when you’re writing the code it’s easy to just use the first name that comes to mind, without considering the impact that choice may have a few months or years later.

I’ve only recently started to take this issue so seriously, but given how many programmers in this book seem to feel the same way, I think I’m on the right track. I now regularly consult a dictionary and thesaurus as I write, and you should too.

The title of this post was inspired by a classic geek joke, which has been lovingly immortalized on a t-shirt by ThinkGeek:

There are only 10 types of people in the world: Those who understand binary and those who don’t.

The joke is that most people will read this as “there are ten types of people in the world”, when in fact the correct reading is “there are two types of people in the world”. That’s because “10” is being used to represent the number two, as written in binary.

Taken at its most literal, this is a (hopefully friendly) poke at non-geek types, who likely have never been exposed to binary numbers. On a deeper level, though, I think it’s a great introduction to a very interesting distinction: the difference between a number and its representation. As a programmer, I deal with this distinction regularly, and a recent conversation made me decide to write about it.

Huh?

At this point, it would be perfectly legitimate to ask what it even means to distinguish between a number and its representation. Is there really a difference?

In a word, yes. There’s as much difference between a written “6” and the abstract number six as there is between the word “cow” and a smelly, cud-chewing quadruped. One is a name, a label, and the other is the thing that is named or labeled. In the case of numbers, the thing being labeled is a concept, rather than a mammal, so a more apt analogy might be the difference between the word “angry” and the feeling of anger. If you aren’t convinced that there’s a difference between the word “anger” and anger itself, consider the fact that the word “angry” would mean nothing to a non-English speaker, but that such a person almost certainly knows what it feels like to be angry. Thus, the name is clearly not the same thing as what’s being named.

Getting back to numbers, I can be clearer now: “6” and “six” are both labels for a concept: the quantity six. Of course, I used “six” in describing what “six” labels, so that’s cheating, but here’s an example of the quantity I’m referring to: @@@@@@ (six @ signs). The point is that quantity is a distinct concept, and two people from different countries or even different planets can still agree on whether they are looking at six widgets or seven, even if they use different words to count them. Likewise, the quantity two is the same whether you call it “two”, “dos”, or “dva”. Since “quantity” probably has less association with written forms than “number”, I’ll use the former to refer to the pure concept of a number.

Representing quantities

Now that we’re clear on the distinction between a quantity and its representation, I can get to the next interesting bit: the representations themselves. I’ll bet that you know of at least three distinct ways to represent the number six. If you’re a programmer, you probably know more.

First the most basic one, the one you’ve probably known since you were only a few years old. You may or may not have given it up since then, but I’m sure you still know how to do it: counting on your fingers. Go ahead and do it – hold up six fingers – and you’ll see a very simple representation of the quantity six. This is the most basic and possibly the least often used (among educated adults), but in my opinion it’s also one of the best. It doesn’t get much clearer than holding up six fingers and saying “this many”. I’m guessing that this is one of the first ways that kids learn to use numbers.

The next most obvious forms are the ones I’ve used throughout this discussion: the common spoken form “six”, and the common numeral form “6”. These are good once you start working with bigger quantities, since humans run short on fingers pretty quickly. These are also where the question of representation starts to gain more depth.

The spoken and numeral forms typically build up numbers by parts. Generally the biggest parts are named first, and then the smaller parts. So you might say “five thousand one hundred and two”, indicating five groups of a thousand, one group of a hundred, and two more. Adding up the parts gives you the actual quantity of interest. “Thousand” and “hundred” are just handy names for certain quantities, ones that are used often enough to warrant their own names. The numeral forms are similar: “132” is understood by convention to indicate the one group of a hundred plus three groups of ten plus two more.

Numeric bases

An interesting thing to note with “132” is that there’s nothing that really requires that the leftmost digit be counting groups of a hundred. It could be groups of seven, or groups of eighty-five; it’s really just a matter of convention. Of course, using the digits to count powers of ten is one of the most common conventions, so that’s how many people will read it. Since ten is in some sense the “base” of this series, we call this system “base ten”. Most people have base ten so deeply ingrained that we don’t even consider other possible ways to name quantities. Its popularity probably comes from the fact that most people have ten fingers for counting on.

Even so, many folks have heard of at least one or two other bases. For instance, you may not realize it, but you likely have also had some exposure to base twenty. The Gettysburg Address opens with “Four score and seven years ago”, and while it may sound antiquated, it’s still reasonably clear: it means four groups of twenty, and seven more. You could write this as “47”, where the “7” represents ones and the “4” represents twenties.

You could use base twenty to represent larger quantities too. Since we’re using powers of twenty, the third digit from the right represents four hundreds, so eight hundred and sixty five would be “235”: two groups of four hundred, three groups of twenty, and five more. Actually, you probably wouldn’t speak it the way I did, since “eight hundred” obviously still employs base ten. Maybe you’d have a name for four hundred, like “tav” in Hebrew, and you’d say something like “two tav three twent and seven”. It probably feels weird to break things down into powers of twenty, but it’s really not much different from base ten, and in fact base twenty has been used by a number of cultures throughout history.

Another common base, used heavily by programmers and other computer people, is base sixteen, or hexadecimal. Here the digits represent powers of sixteen, so “23” would correspond to the quantity thirty-five (two sixteens plus three). An interesting problem here (and with base twenty) is how to represent a quantity like twelve, since it has to fit in one digit. The most common solution for hexadecimal is to use the letters “A” through “F” to represent ten through fifteen, so twelve would be “C”, and thirty would be “1E” (one sixteen plus fourteen).

As I mentioned earlier, we programmers also use base two, or binary. This means we’re working with powers of two, so the rightmost digit counts ones, and moving to the left you count twos, fours, eights, sixteens, etc. So “1011” would be one eight, one two, and one one, for a total of eleven. And with that, we’re finally back to the joke from the beginning: while the most common reading of “10” is ten, you can also read it as two, if you view it as a quantity represented in binary.

Speaking of numbers…

Another fun thing about this joke is that it doesn’t play if you try to speak it verbally. That’s because the spoken representation of a quantity is usually unambiguous, at least in English. If you read “10” as “ten”, you’ve blown the joke, and if you read it as “one zero”, it just sounds weird.

Thinking about how people verbalize numbers makes me think of something else too, something I’ve always found odd about spoken Spanish. I’m thinking of how telephone numbers are read: I often hear the first three digits read as “five hundred twenty three” (in Spanish, of course), rather than the English “five two three”. The oddness here comes from the fact that telephone numbers are not actually descriptions of any quantity, but rather arbitrary sequences of digits used to uniquely identify a telephone. So it seems odd to use quantity words like “five hundred” when you’re not actually talking about a quantity.

On the other hand, there are some things that make more sense in Spanish than they do in English, like the naming of years. In standard English, I was born in “nineteen seventy-nine”, but years actually are quantities, specifically a number of years since some starting point. So it would make more sense to call it “one thousand nine hundred seventy-nine”, which is exactly how it’s spoken in Spanish (but again, in actual Spanish). English has switched back to using thousands for this decade, since saying “twenty nine” would be heard as 29 rather than 2009, but I’m sure many people will go back to “twenty ten” next year. Presumably we Americans prefer this form because it saves some syllables.

Wrap-up

So there you have it: a nerdy joke made even more nerdy by a bunch of blathering about quantities and bases. Nothing kills a joke like having to explain it, but I still think the whole thing is pretty interesting.

We live in a right-handed world. Most people don’t notice it, particularly you righties, but it’s the truth: our world favors the right side. And realistically, that’s probably how things should be, since the majority of people are right-handed. Wikipedia puts the estimate at 90-93%, or only 7-10% lefties. Still, I was interested (and proud) to read that Barack Obama is a fellow southpaw, as were four of the last six presidents.

Today I thought it would be interesting to take stock of just how many things give preference to the right hand. This partial list was compiled over the last month, and while I don’t claim that any of these were deliberately designed to favor righties, I also don’t claim that they weren’t.

Cameras: Almost all of the interesting controls are on the right.

Can openers: Hold ’em with the left, crank ’em with the right.

Cars: In the US, almost all of the controls are on the right side. Could you righties shift with your left hand? Brits, don’t answer that.

Computer mice: Many can be used by either hand, but they’re usually on the right side and (by default) expect to be clicked with the right index finger. Some can’t even be used by the left hand without extreme awkwardness.

Corkscrews and screwdrivers: Usable by either hand, but you can get a lot more leverage in the tightening direction if you use them right-handed.

Iced tea makers: With mine, the pitcher goes on the right, to be picked up by the right hand. My left hand gets to hit the button, though, so maybe it’s a wash.

Microwaves and toaster ovens: Controls are almost always on the right side.

Toilets: I can’t speak for other countries, but in America, the majority of toilets have the flush handle on the left (as you’re facing the thing). That’s because the right hand is too good for such distasteful work. In fact, in some countries it’s actually a horrible insult to offer your left hand to someone, because it’s assumed that you use that hand for wiping.

Scissors: Try using a fancy pair of sewing scissors with your left hand. It doesn’t work. Interestingly, I seem to have learned to cut right-handed very early on, and never ended up needing the left-handed scissors my parents always bought me.

Sewing machines: Speaking of sewing, all of the interesting sewing machine controls are on the right, too.

Watches: Wound by the right hand, unless you wear yours on the right wrist, in which case you probably have to take it off to wind it.

Wedding rings: In the US and some other countries, wedding rings are worn on the left hand. As a lefty, I find it frustrating to have a chunk of metal on my dominant hand – it’s far too easy to accidentally scratch things.

The English language (and lots of others): Boy, there’s a lot to say here. First of all, try writing an essay in pencil with your left hand. Don’t spend all afternoon, just fill one page. Then take a look at the outside edge of your hand. Your skin should now have a nice silvery coating of graphite, and you’re going to leave smudges until you wash your hands. It’s gross. Also, if you happened to choose a spiral notebook for your experiment, did you notice how incredibly uncomfortable it was to have your hand mashed against the spirals? Yeah, elementary school sucked.

Now, there are some advantages to being a lefty, such as a higher chance of being ambidextrous. I have always assumed that this was because we lefties are more frequently required to use our non-dominant hand for things (as demonstrated by the previous list), but I have no proof of this. Lefties are also reputed to be more creative, and some evidence suggests that we’re better at multitasking.

Overall, I’d have to say that I’m quite happy to be a lefty. I feel like a member of an exclusive club. It’s still fun to imagine throwing you righties into a left-handed world, though.

(or, why platypuses don’t make good biologists)

Douglas Hofstadter loves the idea of self-reference. As a cognitive scientist, author, composer, and teacher, his works commonly refer back to themselves or fold in on themselves in strange and delightful ways. His recent book I Am a Strange Loop is all about self-reference, and I can’t recommend it highly enough. A few years ago I had what I would call a Hofstadter Moment, a surprising and unexpected case of self-reference. It came as I was developing Foogle, a tool to index and search computer code.

As a software developer, I work every day with a code base made up of many thousands of files, containing among them millions of lines of code. I often need to search this code, to find where and how different parts of the system are used. Having grown accustomed to Google and its ability to instantaneously search billions of Web pages, waiting five or ten minutes for Windows Search to find what I was looking for just didn’t cut it. So I decided to write a tool that could index our code every night, and let me perform fast and accurate searches of that index any time I needed. In homage to Google (my favorite search engine) and “foo” (the official nonsense-word of programmers everywhere), I decided to call the tool Foogle.

Foogle’s job would be to scan through each code file, break it up into individual parts (‘tokens’, in programmer-speak), and add an entry for each part to the index, which could later be searched. This would be very much like indexing a book, where you would separate the text on each page into individual words, and then add the words of interest to the index. The big difference is that computer code isn’t nearly as easy to decipher as the written word – it tends to look like an explosion of letters and punctuation. This meant that the code for tokenizing a file was relatively tricky to write.

Once I had a working prototype, I turned it loose to start indexing code. First I tried it on some simple, made-up code files, and things worked pretty well. Then I tried letting it index our entire “utilities” folder, which happened to contain the code for Foogle itself. Much to my surprise, when it hit the Foogle code, it broke – it couldn’t index itself. Not only that, but as I investigated further, I was amazed to find that the line of code that couldn’t be indexed was the very line of code that had the bug! 

This line of code, when running as part of a program, was unable to cope with its own written representation. It’s a bit like the double-take you might experience when reading the following: “I like the color red” (psychologists call this the Stroop effect).

As it turned out, fixing the problem was relatively easy, and before long I had a working program. Still, this was one of the most interesting bugs I’ve ever found, purely because of its strange, self-referential nature. It seemed rather like a platypus trying to be a biologist. With their furry bodies and duck-like bills, their laying of eggs and nursing of young, platypuses¹ just don’t properly conform to any of the standard animal categories. Imagine a platypus as a biologist, on the day when it walks past a mirror and realizes that it can’t even categorize itself!

1. You might say I’m wrong and that ‘platypi’ is the correct form. However, I’ve consulted Wikipedia, and I stand by my ‘platypuses’ (and my platypuses).

Today I noticed something interesting on the way home. I was riding the bus, looking up at the display (an LCD) which normally shows the time of day and various information about where we were five minutes ago. The display is made up of fifteen or so panels, each of which displays one letter or digit. As usual, the displayed time was off by an hour or so, but that’s not what interested me. No, the weird thing was that one of the panels was nearly black, while the rest were a sort of cheery orange-yellow color.

I stared at it for a bit, and noticed that as my head moved around the appearance of the panel changed. Eventually I discovered that if I looked directly through my sunglasses, the panel was black, but if I looked over the top of the glasses, it looked just like the others. Tilting my head left and right as I looked through the sunglasses yielded various intermediate colors, and putting the glasses frame right over the panel gave it a sort of split effect.

A bit of physics

It turns out that LCDs are polarized, as are my sunglasses. Briefly, polarizing filters block (or pass) light based on how the squiggles of each light wave are oriented: if the light is oriented on the same axis as the filter, it gets through, otherwise it doesn’t. Actually, somewhere between all and none of the light gets through, depending on how close the orientations of wave and filter are. Here’s a picture to help visualize it, showing unpolarized light passing through a vertically-oriented polarizing filter:

(click the image to read the entire article)

As you can see, only the vertical “component” of the wave makes it past the filter.

Normal ambient light, from the sun and most typical light sources, is composed of zillions of light waves, all with different polarization. This means that if you put on a pair of polarized sunglasses, things look a bit darker, because some of those waves have been blocked, but things look more or less like they did before. The interesting effects show up when the light hitting your sunglasses is already polarized for some reason, like the light coming out of the LCD on the bus. Apparently most of the panels on the display were polarized in approximately the same direction as my glasses were, but that one weird panel was close to 90 degrees different, so that together they filtered out almost everything. Another place you’ll notice this is car windshields, which often take on an odd bubbled-rippled-rainbowy look, because of how they’re pressure-treated at the factory.

Anyway, I highly recommend getting yourself some of these sunglasses, and then wandering around to see what you notice. As a bonus, they also work really well for their intended use, namely making it easier to see in bright light.

A bit of politics

As I sat there and tilted my head around like a goof, watching how the LCD panel got lighter and darker, I got to thinking about a more common use of the word “polarize”, namely https://en.wiktionary.org/wiki/polarize: “To cause a group to be divided into extremes”. I was particularly thinking about how, in my eyes, that LCD looked totally different than it did to the rest of the people on the bus. They saw a normal time display, and I saw “6:1▮ PM”. Whose view was the right one? In this case, it’s pretty clear that I was in the minority, but it sure looked weird to me.

It’s even more interesting when you consider the broader picture, with a hotly-contested presidential election on the horizon and an economy staggering toward the unknown. Political and economic polarization are as strong now as they ever have been, and I can’t help but wonder if our own mental filters make it really hard for us to see the world clearly. I know how the world looks to me, but that’s just one perspective: that of a middle-class Democrat with (I hope) a secure job. The problem with biases (and polarized sunglasses) is that it’s really easy to forget they’re there. Am I missing something really important because I’m so focused on getting a Democrat into the White House? Have some Republicans been partially blinded by their heartfelt conviction that we have to win before we can leave Iraq?

I don’t know, but it’s worth thinking about.