My First Tangle With the Tower of Babel

A while back, I was reading the blog of somebody smart (can’t remember who), and a comment jumped out at me: “If you really want a black belt in computer science, try writing a programming language. The depth and breadth of experience you get when you invent Python or Lisp or Smalltalk or C++ or C#–and implement its ecosystem, not just code a parser for a CS class–gives you a wisdom and education that’s rare and precious.” (I’m paraphrasing here, but that’s the gist of it.)

Sounds good, I thought. I think I’ll give it a shot.

“Confusion of Tongues”, by Gustave Doré. The Tower of Babel resonates beyond moral history. Image credit: Wikimedia Commons.

I began doing research and taking notes. I thought hard about which features I liked and detested in programming languages. I read critiques and tributes to various languages by detractors and fans. I identified pieces of syntactic sugar that I wanted to support. I took a wad of existing code and tried to rewrite it using the language I was drafting. I picked some conventions for filenames. I played with yacc and antlr and experimented with definitions of context-free grammars.

And then I stalled.

It wasn’t good enough.

My new language was nifty. It combined a lot of the best features of my favorite languages: closures, list comprehensions, lambdas, static if, robust type inference, unified function call syntax, with blocks, variadic templates, mixins, nullable primitives, built-in support for design by contract, and more. I actually believed (perhaps naively) that I knew how to implement a good portion of these ideas in a compiler.

But I began to intuit that nifty != great. And the longer and harder I thought about it, the more convinced I became.

Continue reading

Code Isn’t Art

Programmers, tell your inner artist to shut up.

One of the defining aspects of the Ruby programming language is that it is very flexible. It takes a very UNIX-like approach of having a few simple and well-defined functions that allow you to build rather complex systems. Unfortunately, it also ends up encouraging programmers to start thinking of their code as art, and then they start writing “clever” code. There’s nothing necessarily wrong with finding an unconventional solution to a coding problem, but that often falls apart when you have to involve another human in reading your “art”.

Let’s use an example from SQL of a “clever” solution. Take a look at the following query:

SELECT cl.Language, c.Name AS “Country Name” FROM CountryLanguage AS cl INNER JOIN Country AS c ON cl.CountryCode=c.Code SORT BY c.Code

How long did it take you to read that query? Probably a good minute or two because you had to expand out all of the aliases to figure out what it’s doing. Compare that to the unaliased version below:

SELECT CountryLanguage.Language, Country.Name AS “Country Name” FROM Country Language INNER JOIN Country on CountryLanguage.CountryCode=Country.Code SORT BY Country.Code

As you can see, it isn’t a “clever” query, but it sure is a lot more readable to a third party.

A lot of programmers will probably come back with “so what? I can read my own code and it gives me the result I want.” The fatal flaw here is that code is written not for machines, but for people. (Odds are good you’re also not going to be the only person that sees that code.) If we were writing for machines, you’d be using pure binary. All programming languages are made to give humans a way to express this in terms that are much more easily understood. Heck, SQL had an explicit design goal to be easily understood by accountants that needed to work with a database. The human element is crucial.

This is especially frustrating for those of us in support roles. I have a long history with SQL, some PHP experience, and I’ve done some dabbling with Ruby on Rails, but that’s atypical. Most support people don’t have any programming experience. What if they’re in a situation where they need to decipher the scripts that support a product or, heaven forbid, peruse the source code to try and find the cause of a particular error? They can probably figure out verbose code from having dealt with pseudo-code examples but will run straight into a brick wall if a programmer decided to be “clever”. Now the engineering team has to be drawn into something that could have potentially been resolved by support.

The question you have to ask yourself is if the ego boost from “clever” code is worth the increased work created when others don’t understand your “art”. I’m going to bet that your team members, members of supporting teams, and any management you report to won’t look favorably upon it.

Jesse Harris has been a geek since cutting his teeth on the Commodore 64 in pre-school. He currently works in support at RSA, the security division of EMC, and has been doing support, systems administration, and web development for 13 years.