Niclas Nilsson home

Agile languages

I recently joined Agile Sweden, which I in hindsight should have done many years ago, now that I realize they’re having a lot of interesting discussions over there.

Since I’m a newbie on the list and I wanted to know the frames of the forum, I asked if agile languages was on- or off-topic. The question I got back was “What’s an agile programming language?”, and to my surprise, that ended up being a very interesting discussion of its own, about what can and what can’t be classified as agile.

What’s an agile language?

To me, an agile programming language is a language that helps fulfill the agile values and principles better than other languages, in the same sense as we think of agile methods and agile modeling.

But can a language be agile? Of course it can.

If you remember the times when everything under the sun was called object-oriented, you may think that calling a language agile is just a scam to give some languages false credibility by pretending to have an association with the agile movement, but that suspicion would not prove to be correct. For instance, Ward Cunningham, one of the most well-known authors of the agile manifesto, calls Python an agile programming language, and I fully trust that Ward understands the agile values and beliefs. The thought of anyone criticizing Ward for calling things agile, reminds me of the journalist who accused Paul McCartney for sounding like the Beatles.

Besides Ward, many of the other authors of the manifesto was well-known for their values when it came to programming languages, long before they became known for talking about processes.

Adaptable?

But of course, it all comes down to a matter of words. The agile manifesto specifies values and principles of agile software development. The dictionary on my Mac defines agile as ‘able to move quickly and easily’. In that sense, only humans can do that. That means that no language can be agile, but it also means that no method or process can be agile.

However, when the agile manifesto was created, the legend says that the original phrase they wanted to use was something along the lines of adaptive software development or maybe adaptable software development. Unfortunately, Jim Highsmith was already using words like that, so we got agile instead.

The word adapt is actually a better description in my point of view, so I’m not surprised that they wanted that word. Adapt is defined as ‘become adjusted to new conditions’. This is true for agile methods, but even though the method can (and should) be adapted to your needs continuously, the main agile target is of course the product you are building.

The same is true for agile modeling; it’s not really the modeling itself that is subject to a lot of changes - it’s the models.

What makes them agile?

So, what about agile languages? Well, many of the languages that I would classify as agile languages are very adaptable themselves, but the main target is still how easy the resulting code is to adjust to new conditions. Some people will tell you that the language has nothing to do with how easy the code is to adapt.

They’re wrong.

No matter how good developer you are, you can still not create code that is as easy to adapt to new requirements in assembler as you can in C, and the same goes for language comparisons higher up in the abstraction chain. The fact is that some languages are higher on the adaptable and agile scale than others, but that does not mean that these are better languages for all purposes, they just happen to be good at particular things - abstractions and expressibility. Some languages are better for creating abstractions, some are better for producing code that executes fast.

In my opinion, there is absolutely such a thing as agile languages. Naturally, this is a scale, just like some methods are more agile than others.

Agile-friendly?

During the discussion I referred to earlier, I tried to come up with another term that would capture the same intention as agile languages (and methods, modeling, …) does, that could be used to avoid any credibility-stealing discussions.

The term that I proposed was agile-friendly, but the problem is that I actually don’t believe in using another description myself. I think agile methods, agile languages and agile modeling are very good descriptions, and that they all map well to the agile values and principles.

Before agile languages were called agile languages, they were often referred to as lightweight languages, just like agile methods were called lightweight methods at that point. One of the reasons to not use the word lightweight for either the methods or the languages, is that it is easy to draw the conclusion that they can not be used for real projects, which of course is utterly wrong.

Agile != dynamic

Another criticism that I want to address is the myth that the term agile languages is unnecessary, since there already are good, descriptive names; scripting languages, interpreted languages or dynamic languages.

In my opinion, that’s a misunderstanding. Neither of these descriptions means the same thing, and neither of them means the same thing as agile languages does. I would for instance rank Haskell rather high on the agile scale, but I wouldn’t call it a dynamic language. Sure, there is a big overlap between dynamic languages and agile languages - but that doesn’t exclude a very static language from being agile, as long as the code is a lot easier to adapt to new purposes than similar code in many other languages.

Conclusion

The discussion made me more certain that the term agile languages is a good term. I have respect for the argument that tools, processes and languages can’t be agile themselves, but I don’t think that’s how people perceive the terms, and I think it becomes too awkward to call things agile-friendly - especially since the underlying meaning is adaptable.

But, I reserve the right to be agile and change my opinion if my understanding changes. After all, I’ve been wrong about words before.