July 13, 2019

Celebrate Programming Verbosity

Photo by Chris Ried / Unsplash

I've been a Perl 5 developer for over 20 years, and still find it's the language I connect with most. Every other one I've tried, I'm surprised at the hoops I have to jump through to do what would be a simple task in Perl. Whether it's data structures, regular expressions or inline functions, few others make it so easy.

But by no means is it a perfect language, and I very much understand where things could be improved or simplified. It's unlikely you will understand what all those symbols are on first glance, and it's very easy to express your idea as something looking a bit like line noise.

Perl 5 is not the language of choice of most people, and ultimately I believe most programming languages become popular in one of two ways - force or simplicity.

Javascript is the best example of force. It doesn't matter that it's burdened by poor design decisions, if you want to run some code in your web browser there's effectively no other choice (although Dart and VBscript tried). Developers have spent an awful lot of effort trying to make it better - ES6, TypeScript, CoffeeScript etc - because there's just nowhere else to go. Eventually they decided if they were being forced to write it, they may as well write it everywhere, and that's how you get NodeJS.

Objective-C and Swift are also similar examples. The momentum behind Apple and iOS is so great, it doesn't matter whether these are great languages or not. You don't have much other choice. You can try, but if you're not writing in the preferred platform vendor language, it's just going to be harder to get support. See Microsoft and C++ then C#. You can pick holes in all of them, but they still won out.

Even PHP won through force. If you were on a shared web host in the late 90's or early 2000's, PHP was the only language you could run. Like Javascript, it's what was there.

If you can't succeed through force, then you can try simple. Python is the poster child for this category. Both old and new programmers can look at it and recognise most of what's going on very quickly, which is why it's so often used as a teaching language. People choose to use it because it's so readable, the anti-Perl. There are no funny symbols.

Code is read far more than it is written. Simplicity triumphs because most programmers forget how the code they wrote last week works, let alone the code they wrote 5 years ago. Simplicity triumphs because the rest of your team have to understand what was in your head too. Google leaned heavily into Python because there was a greater chance that developers would solve problems in similar ways - there's only one way to do it.

A friend Tweeted a link about Perl 6 myths, and it convinced me the developers and advocates of that language have an entirely different view of the world.

Every time I see a fan of Perl 6 talking about how amazing it is, it's usually followed by a snippet of code that looks like they were testing out if all the keys on their keyboard actually worked correctly. What they see as a shortcut solution to what would be multiple lines in another language, I see as another reason not to ever attempt using it for development.

From that article, trying to debunk the myth that Perl 6 is hard to read...

If you don’t know Perl 6, it will fly right over your head. It is so dense with information that skipping a single symbol might drastically change your interpretation of the entire bit of code. Want to see how dense Perl 6 can be? This is a automatically parallelizable map and fold on a list of numbers 1 to 100, using subroutines f($x) to map each number and g($x, $accum) to fold the list:

[[&g]] (1..100)».&f

Every single symbol in that line of code carries a significance, and the code would be drastically different should any of the symbols be missing or different.

I'm not sure how that busts the myth that Perl 6 is hard to read. The argument seems to be that it's only hard to read if you don't know Perl 6, and that you can't read a language that you don't know. But for programming languages, that's simply not true. Most programmers would be able to recognise a while loop, or an if construct, or a function definition in any c-inspired language. You have no chance of understanding what that line is going to do, so the myth stands.

Admittedly, the precedence rules are confusing and the left & right binding seems to change willy-nilly.

Sounds great!

At this point the article says you don't need to use that kind of construct, and that you could be more verbose...

This complexity is all there and it’s all ready to be used. But if you’re a beginner, or if you’re just not planning on diving deep into the language, you have no reason to use it! It’s all hidden from the programmer who doesn’t want to get down and dirty with it.

And that’s what’s important: the complexity is layered.

There's a fine line between expressiveness and complexity. I like Perl 5 because it's expressive. If I want to pass a function as an argument to another function, I can just declare it the same way as I would anywhere else. A lot of programming languages make things like that impossible, or require special syntax (including Python).

But complexity arises when you push that boat out too far. When you start looking at ways to reduce the burden of certain tasks, you instead introduce more cognitive load than would have been there to start with. It may seem like reducing 10 lines of code to 2 would reduce the load on the programmer. But they next time they read it, they'll be unpacking those 2 lines in their head back into 10 again.

As soon as one of your developers decides to go deeper down the layered complexity rabbit hole, now everyone on the team needs to go down the rabbit hole with them. Everyone is unpacking those 2 lines into 10, all without the experience of having written them. Every layer is a weight that's going to sit on top of you every time you come back to that code. That great solution you had to a problem before you went off on holiday? The one that used all those significant symbols that we saw earlier? Good luck understanding what you meant when you come back. Good luck to all of your team members trying to do the same while you're away.

Verbosity is often seen as bad programmer practice. It's what newbies do. Perl 5 programmers used to compete with each other to see who could complete tasks in as few lines as possible. Those are the ones leading the Perl 6 charge.

But verbosity should be celebrated. It's what will make my code easier to read now, later, and by the rest of my team. And even though I'll have more lines, I'll also have less bugs. Code review will be simpler, and mistakes won't be able to hide in a tightly packed row of symbols. Don't be afraid to express your idea in a way that won't have people arguing in 500 years whether your code is smiling or not. Enigmatic is not a good programmer trait.

In the meantime I hope people keep trying to produce the language that strikes a better balance between expressiveness and complexity than we have today. We can do better.

  • LinkedIn
  • Tumblr
  • Reddit
  • Pinterest
  • Pocket