Monday, September 30, 2013

I Love Limitations in Programming Languages

I'm not being sarcastic! I really do love them. Here's the thing:

Writing code is a very free-form exercise. Each developer has their own style, there are usually many ways of accomplishing the same task, and everyone has their own idea of what 'pretty' or 'clean' code looks like. The computer, of course, doesn't care. It just cares that, basically, there is some code. It finds this 'some code' and it happily compiles or interprets it.

Humans, however, care about more than that. At the most fundamental level, humans care about understanding what the code is doing. (At least, they should!) Now, what is easier to understand: one thing or 100 things? I hope you said one thing.

And this is exactly my point: If the language only provides one way of doing something, it makes it easier for every other developer to understand what the code is doing. If the language provides 100 ways of doing the same thing, well, then every developer has to know all 100 ways.

So some might look at that language that only provides one way as very limiting. "There's only one way! Psshaww!" But I look at that language and say "That's so easy to understand!" I love those kinds of limitations because they make things easier. And I love easy.

Now, if the designers of the language were clever, they will make it such that the one way happens to be the best way. In other words, they build the best practice into the language and don't allow you to (or at least, make it difficult for you to) deviate from it. In this case, I really love the limitations! Because when you learn the language, you're also learning the best practice by default! And it becomes very hard to do it the wrong way.

Let's pause for a quick example. I really enjoy the C# programming language for this reason.  C#, like C++, is object-oriented. But unlike C++, everything in C# is an object. Is that a limitation? Yes: everything has to be an object. Does it help? Yes: you only need to know one way to treat everything (like an object).

Critics of C# would say that this business of everything being an object makes the code more verbose. And I agree. But you know what? I like verbosity too!

Recently, there has been a push for more concise programming languages. Quite frankly, I think this is misguided. Remember, a human's foremost concern should be understanding the code. Code will be read (and hopefully, understood) many more times than it will be written. So emphasis should be placed on ease of understanding, not ease of writing.

Another example. C# has a method called "ToString". Ruby has a method called "to_s". If you have never programmed in C# or Ruby before, which of those two method names do you think would be clearer?

"But," some may say, "if you are calling the method many times, those extra characters add up to a lot of extra development time!" This is wrong for several reasons.

The first reason is Intellisense or other code-completion tools. Rarely do you have to type every character in a language like C#. The IDE makes intelligent guesses as to what you are about to type and gives very accurate completion options.

The second reason is that the actual typing of your code should probably be a small portion of your development activity. Hopefully, you spend more time thinking and designing than you do typing.

The third reason is that, as mentioned above, code will be read more often than it is written. So speeding up the reading [ie. understanding] of code should take precedence. Granted, anyone experienced in the language will understand the built-in abbreviated method names. But those shortcuts create a sort of 'culture of obfuscation.' Developers will follow that same standard in code they write and then the whole code base becomes difficult to understand. True, a language like C# has a 'culture of long method names,' which may look silly. But silly or not, I don't have to guess at what they do. And that is what matters to me.

To sum it up, limitations make it hard[er] to write bad code. And limitations + verbosity makes your code easier to understand - both by yourself and others. So why the push for more free-form, concise languages? I really don't know. I will say that if a language can be more concise, without sacrificing understandability, that's great! But I do know that I'd rather read Java over Perl any day of the week.