It's hard to pick out trends in the industry because most things that we would call trends are really swings of a pendulum. This was brought home to me a few months ago when I was sitting across a table from someone who told me that the problem with IT is that we just don't have enough meta-data. If we had meta-data for everything, all of our problems would go away. I tried to tell him that this had been attempted number of times in the software industry and that it was quixotic - sort of like programming in pictures. But memes rise and fall. We each have to learn the hard way that the light you see from a distance isn't always as illuminating as we expect once we get to it.

Recently, another meme has been on the rise. The meme I'm talking about is the notion that code becomes better as it approaches English. I'm seeing this in a couple of different places now. One is the Domain Specific Languages community. While it's true that DSLs don't have to become English-like, there are a quite a few people who try.

The Behavior Driven Development (BDD) community also tends toward English-esque readability. Here is an example in rspec from Luke Redpath's blog:

  specify "should be invalid without a password" do
    @user.email = 'joe@bloggs.com'
    @user.username = 'joebloggs'
    @user.should_not_be_valid
    @user.password = 'abcdefg'
    @user.should_be_valid
  end

It's fine, it reads like English. But, is that good?

I think that, fundamentally, we have at least two different ways of understanding text. One is narrative and the other is symbolic. In the narrative mode, we are approach text like prose and read through it the way we would read through English or any other natural language - it tickles the verbal centers of our brain. The symbolic mode is more visual. It helps us understand code like this even if we would fumble when giving a verbal explanation:

  primes = sieve [ 2.. ]
           where
           sieve (p:x) = p : sieve [ n | n <- x; n mod p > 0 ]

We have to decode it, but the decoding is often swift and more precise than what we are used to with natural language.

I like to see narrative approaches in tools that can be user facing, like rspec's Story Runner, and FIT's DoFixture, but in code written by and for developers, I have mixed feelings. This code: 

  5.days.fromTomorrow.at(2.am)

reads very well, and it's hard to imagine a good symbolic alternative, but there are times when a symbolic approach can make code comprehension a breeze. The C++ iostream library is a good example. With the use of a couple of operators, much of the arcana of I/O is stripped away.

Ultimately, I think that some domains are more suited to the narrative approach than others but the criteria are tricky. On the one hand, if you are working in a domain like dates or scientific units, with settled definitions and nomenclature, it can pay to use a natural language style in your API. When definitions are settled, there is less of a chance that the machinery of a DSL will have to be refactored as much over time. On the other hand, once definitions are settled and well understood, you can eliminate a lot of cruft by moving toward a symbolic approach. The price, of course, is a steeper learning curve. It seems that there is a sweet point between those two poles and I have the sense that it might be narrower than we expect.

The narrative meme is rising. Many people are trying to write English in Java, C# and Ruby. I just hope that we learn where it is applicable and where it isn't. Natural language should not be the only direction we explore when we look for expressivity. Hopefully, after a few years, we'll walk away with a stronger sense of where natural language helps and hinders.