29 December 2014

Why I Don’t Use Syntax Highlighting

When I’m programming, and a fellow programmer looks over my shoulder, the first thing they invariably say is some variation of “Wow, no syntax highlighting? I can hardly read that.”

Ever since I started programming almost 15 years ago, I have preferred very minimal syntax highlighting—typically just keywords, comments, and string literals. I have synaesthesia, so I find anything more involved to be distracting, due to the mismatch between my perception of the colour of a word and the colour in which it’s rendered on the screen. So now my default programming theme is simply black text on a white background, usually in Source Code Pro.

When I see someone working in a wild palette of pinks and purples and yellows and greens, I can agree that it looks pretty—but it interferes with my ability to read the code. It feels nothing but gratuitous. When you read a novel, the words aren’t highlighted for their grammatical categories; when you read mathematics, the symbols aren’t highlighted for their syntactic categories; so why do we do this in programming?

Perhaps it’s because our notations are impoverished by their rendition in monospaced fonts using the subset of ASCII that’s convenient to type on an American keyboard—but couldn’t we use proportional fonts and better input methods? Perhaps it’s because our languages include lexical elements such as comments and (sometimes) string literals that can span multiple lines and “run away” to produce odd syntactic errors—but couldn’t we make such error messages smarter? Perhaps it’s because we don’t know our own languages well enough, so we need interactive help on which keywords are available and which syntax is valid—but why do our languages have so much syntax?

Often, syntax highlighting is outright incorrect, particularly in syntactically complex languages like C++ and Perl. Just as often, it’s misleading to beginners, who tend to interpret things highlighted in a way they don’t understand as erroneous, even if they’re actually correct.

Every justification I can find for syntax highlighting can be refuted by an appeal to better tooling. It appears that we only use syntax highlighting as a workaround for the lack of these tools, and because it’s something to which we grow accustomed by virtue of its ubiquity.

28 December 2014

A Simple Argument for Immutable Objects

You have an integer value 4 stored in the variable x.

int x = 4;

You change x.

++x;

In doing so, you have not changed 4 into 5, you have merely changed x to refer to the value 5.

Now suppose you have a class.

class Person {
  …
};

Instances of this class are values representing states of an object in your problem domain.

class Person {
private:
  string name;
  int year_of_birth;
  …
};

You want to ensure that these values always represent valid object states. You can do this by prohibiting invalid state transitions.

class Person {
private:
  string name;
  int year_of_birth;
public:
  void set_name(const string& name) {
    if (name.empty())
      throw invalid_argument("name must be non-empty");
    this->name = name;
  }
  void set_age(const int year_of_birth) {
    if (year_of_birth <= 0)
      throw invalid_argument("age must be positive");
    this->year_of_birth = year_of_birth;
  }
  …
};

You can also do this by prohibiting the construction of invalid states, and prohibiting all state transitions.

class Person {
public:
  const string name;
  const int year_of_birth;
  Person(const string& name, const int year_of_birth)
    : name(name), year_of_birth(year_of_birth) {
    if (name.empty())
      throw invalid_argument("name must be non-empty");
    if (year_of_birth <= 0)
      throw invalid_argument("age must be positive");
  }
};

Now the values are correct by construction and immutable. All of your validation logic is cenralised, so you can verify it in one place. When you want to represent a new state, you simply construct a new value to represent it.

auto me = make_shared<Person>("Jonathan", 1991);
me = make_shared<Person>("Jon", me->year_of_birth);

Creating a new Person to represent the person I am after adopting a nickname does not change the Person I was before adopting a nickname. I am only changing what me refers to.

Whereas a mutable object pretends to be a state, an immutable object represents a state. The latter is not only simpler to reason about, but also more honest about what software is actually doing: representing.

17 December 2014

Caffeine vs. Nicotine

I had been experiencing some pretty severe anxiety off and on for a few months, and I was aware that my love of caffeine was exacerbating this anxiety, so I decided to look for a stimulant that would help me focus, while not worsening my anxiety.

I eventually settled on nicotine, for a few reasons:

  • It is a stimulant that is known to relieve anxiety.
  • By itself, it is not known to be a carcinogen.
  • It is only significantly addictive in conjunction with MAOIs, which are present in cigarettes but not in ecigs.

Experiment

Take ~1mg of nicotine per day by vapouriser, equivalent to 1 or 2 cigarettes, for three weeks, and document the results.

I chose an e-liquid solution of 6mg/mL nicotine suspended in vegetable glycerin (VG) with flavour. Most e-cigarette liquids contain propylene glycol (PG), but I am mildly allergic to this, so I excluded it.

Observations

  • Nicotine is an effective stimulant. It increases my motivation and focus, and makes me more productive by decreasing my propensity for distraction. It is comparable to caffeine in this regard.
  • Caffeine makes me feel anxious. Nicotine makes me feel relaxed.
  • Caffeine interferes with my ability to think creatively. Nicotine does not.
  • Caffeine interferes with my ability to sleep. Nicotine does not.
  • Nicotine reduces my desire to drink alcohol. Caffeine does not.
  • I suffer mild withdrawal symptoms (headaches, irritability) when ceasing caffeine. I also suffer mild withdrawal symptoms (agitation) when ceasing nicotine.
  • Nicotine increases my blood pressure slightly more (4±1mmHg) than caffeine does.

Conclusions

Nicotine is an effective choice for my use case, and I am happy with this choice. The stigma against nicotine appears to be due to its association with cigarettes—which I must emphasise are disgusting, dangerous, and outdated. Nicotine should be reconsidered and accepted for its own merits.

12 September 2014

Artificial Expertise

Artificial expertise is a term that I tend to use in real-life discussions, which I would like to document in order to help make people aware of the concept. It refers to the specific kind of detailed knowledge that you get from working with complex systems that require a high amount of skill to operate—when those skills are not transferable to other systems. The expertise is not inherent to the problem, but incidental to the solution, and thus artificial.

As far as computing science goes, I can give you two very good examples of systems that generate artificial expertise. What’s wonderful is that they’re at absolute opposite sides of the spectrum of delight.

C++ is a cult of artificial expertise because it encourages—often necessitates—the constant consideration of details typically irrelevant to the problem at hand. The choice of passing parameters and storing objects by value, reference, pointer, or smart pointer needs to be considered for every declaration. All this takes place in the exciting context of a complex interplay between implicit conversions, exceptions, mutable memory, and silently undefined behaviour.

When I use C++, or help my coworkers to, it makes me angry and tired.

Perl is a cult of artificial expertise because it has many “tricks” for producing more compact and expressive code. You could think of a trick as anything non-obvious. I’m loath to use the term because I regularly see programmers labelling as “tricks” many perfectly ordinary language features and programming techniques, such as Python’s list comprehensions or Haskell’s lazy evaluation. In Perl, many of these take the form of sensible defaults that can be left implicit, or special variables used to control the behaviour of common operations.

When I use Perl, I feel empowered and clever. Like C++, Perl gives you many opportunities to improve your code or write it in the manner that you deem best suited to the problem, and in the hands of an expert it’s a powerful tool. Here’s the critical difference: Perl code that I have seen written by a beginner tends to simply not use the “expert” features; C++ code tends to accidentally use them, and often thereby run into undefined behaviour through their miscombination.

Now, knowing either of these languages puts you in imminent danger of getting yourself employed. And I believe this is no coincidence. Creating inefficiency is an excellent way to create jobs—it’s creating efficiency that creates careers.

14 August 2014

Adjective Valence and Linguistic Relativity

There is a concept in linguistics that I could have sworn I’ve read about, but now cannot seem to find mention of anywhere. I call it adjective valence, and examining it can give you insight into how you conceptualise the world around you, how language influences and is influenced by that, and where language is lacking.

The valence of an adjective is its directionality—whether the word is perceived as the essential quality of a trait (positive valence) or its antonym (negative valence), and in what direction the axis goes in spatial metaphors concerning that trait.

For example, hot and cold are antonyms. We can observe that hot has positive valence in English by noting that when something gets hotter, its temperature is said to increase; cold has negative valence because when something gets colder, its temperature decreases. It’s fine for a thing to become more hot, but our language makes it slightly unusual to say less cold for the same concept. This has a sound physical basis: a higher temperature implies a higher average internal kinetic energy.

Not all languages have the same valence for all adjectives. For example, in English, we think of ourselves as moving forward in time, that the future is before us and the past is behind us. This valence leads to many idioms such as “I’m looking forward to it” and “put it behind you”. But in the Aymara language, the future is behind you—after all, you can’t see it—and the past is in front. This was also true in Ancient Greek (ὄπισθεν = behind = in the future, πρόσθεν = in front = in the past) and modern Chinese shows some evidence of a switch from front-past to front-future.

We can use this information to discover linguistic assumptions we make about the world. By inverting the valence of an adjective, we can challenge those assumptions and perhaps achieve insights about whether our intuitions correspond to real physical phenomena. For example, let’s replace temperature with its reciprocal, such that “absolute zero” is considered infinitely high on the scale of coldness. If this were our basic assumption, we would have no trouble accepting that such a temperature is unattainable in any physical system. And it turns out that that quantity, the thermodynamic beta, is a useful one, rigorously defined in terms of the energy and entropy of a system.

This is an argument in favour of the weak form of linguistic relativity, the notion that language influences thought. It’s not difficult to consider the implications of inverting the valence of an adjective, but we rarely think to do so, and talking about the implications is often hilariously difficult. This metal ball has a high mass, and a low—what? Take notice of these things in conversation and try inverting them to peek behind the curtain of your own thoughts.