I'm very excited to announce that our article The Mind-Writing Pupil is now available at PLoS ONE! In this article, we describe a technique that allows you to—literally—write by thinking of letters. This sounds like a wild claim, but it's not; the technique is actually surprisingly simple. In the video below you can see a demonstration:

So how does this work?

First, let's look at the simple case in which there are only two letters: A and B. Both letters are presented on backgrounds that alternate between bright and dark; crucially, whenever the A is dark, the B is bright, and vice versa.

Now imagine that you are looking directly at the B. In this case, your eye's pupil would respond strongly to the brightness of the B (or rather its background); this is the pupillary light response: the constriction (shrinkage) of the pupil in response to brightness, and dilation (expansion) in response to darkness.

So if we would measure the size of your pupil while you're looking directly at the B, we would see that it follows the B's brightness. In this example, the B is initially bright, so the pupil would be small; then the B turns dark, so the pupil would become large; and then the B turns bright again, so the pupil would become small again. Therefore, we could simply measure how pupil size changes over time, and use this to determine with almost 100% certainty which of the two letters you're looking at …

Prefer video? Check out this YouTube tutorial.

Special characters are a pain for programmers, and a source of bugs. Whenever your code contains an accented letter, voil├Ā, funny-looking symbols appear; or, worse, your program crashes with an obscure error. Why does it have to be that hard!?

It doesn't. Character encoding is not that difficult once you understand the basic principles. Let's take a look.

Characters are interpretations

For a computer, there is no text, only bytes. Text is an interpretation, a way to visualize bytes in human-readable form. And if you interpret bytes wrong, you get funky-looking characters, or even an error. A character encoding is one specific way of interpreting bytes: It's a look-up table that says, for example, that a byte with the value 97 stands for 'a'.

Now let's consider these three bytes:

195-167-97

In Python 2¹, this is a str object: a series of bytes without any information about how they should be interpreted. Don't let the name confuse you: A str is not a string of characters; rather, it's a series of bytes that you can interpret as a string of characters. But the proper interpretation requires the proper encoding, and the problem is: A str doesn't know its own encoding!

Now let's turn to actual Python:

# Mystery string!
byte_string = chr(195) + chr(167) + chr(97)

We have three bytes (195-167-97), but no idea what they stand for. How can we decipher these bytes into actual text? Well, we need …

Object-oriented programming is a beautiful concept with a bad reputation. Many programmers, especially those without formal training, avoid it, because they believe that objects are complicated and abstract; in addition, many programmers don't have a clear understanding of what objects are good for. Why do you need objects at all? Can't you do everything with functions and loops?¹

Object-oriented programming serves several purposes. The one that you hear most is that it 'reduces code redundancy'; that is, it avoids you from having to type the same thing twice. While this is true, this is mostly relevant for large projects, in which duplicate code causes all kinds of problems. But object-oriented programming serves another important purpose, one that is useful for large and small projects alike: It's a way to think about programming that resembles how we think about the world.

To introduce object-oriented programming, let's start with an example that embodies its very opposite:

i = sqrt(9)

Here we apply a function (square root, usually written as sqrt) to a number (9). The result is another number (3), which is stored in a variable (i). This example illustrates a clear distinction between the data (the number 9 and the variable i) and the function that is performed with this data (sqrt()). This data-function distinction is characteristic of mathematics and traditional, non-object-oriented programming.

But now consider this:

The cuteness. Sources (CC-by license): Wikimedia and again Wikimedia.

We immediately recognize these objects as kittens. And we roughly know what properties and …

I like to write: blogs, papers, mediocre bits of fiction that never see the light of day, and even forum discussions. Each of these writings poses its own challenges, and requires its own style. When writing a blog, what is a good opening sentence? (Here I dived right in with "I like to write." Is that too blunt?) What's an acceptable length for a blog, given people's limited attention spans on the internet? (This blog is probably too long.) When to use, and when to avoid, parenthetical phrases? (Avoid, avoid!) When writing a scientific paper, how do you let the introduction flow naturally into the research question? When answering a technical question on a forum, how do you make sure that someone who is already struggling understands your answer?

And, in all cases, how do you avoid mistakes, and express yourself as clearly as possible?

Writing isn't easy, but it's not magic either. Below, in no particular order, are six books that I've personally found very useful in developing my own writing.

1. The Elements of Style

Let's start with a classic: The Elements of Style, by Strunk and White. This 'little book', as William Strunk Jr. called it, has an interesting history. Strunk was an English professor at Cornell University, and privately printed the first version of The Elements for his students. This was around 1918. One of his students was E. B. White.

The collaboration between Strunk and White started only in 1957, a decade after Strunk's death …

Try this little experiment:

• Look at yourself in the mirror from a distance of about 20 cm.
• Alternately look at your left and right eye.

Not much to see, is there? And that's exactly it: You don't see your eyes moving! Yet eye movements are clearly visible. You can verify this with a variation on the same experiment:

• Look at yourself in the front-facing camera of a phone (or any webcam).
• Again, alternately look at your left and right eye.

Now you clearly see that your eyes move, in small jerky movements called saccades. So what's the difference? Why can you see your eyes move in a webcam, but not a mirror?

When one does the second experiment, it is imperative that one duckfaces. (Source)

The answer is that your phone's camera shows things with a slight delay; therefore, you see your eyes move only after they have already stopped moving. In contrast, a mirror has no delay; therefore, to see your eyes move in a mirror, you have to see while your eyes move. And you usually can't—a phenomenon that is often called saccadic suppression. (Because vision is suppressed during saccades.)

An intuitively attractive theory is that saccadic suppression prevents you from seeing a dizzying movement of the world whenever your eyes move. The idea is simple: The eye is a camera, and when a camera moves too rapidly, the viewer gets dizzy. (Think of found-footage movies, which are recorded with a hand-held camera, preferably while the lead …