Just Another Perl Punk

Perl was my gateway programming language. As a kid, I experimented with various flavors of BASIC, Logo, and even a bit of 6502 assembly. But my engagement with Perl was longer-lasting and more consequential. Perl is no longer my tool of choice, and hasn't been for years. But on reflection, I think there are reasons that it that it was a good fit at that time that it was.

In its disdain for academic categories and focus on getting the job done quickly if not necessarily elegantly, Perl embraces an ethos not entirely unlike the DIY ethic associated with punk rock. Punk musicians, unencumbered by music theory or the bounds of conventional good taste, found expressive power in the brief and determined application of a few predictable chords; Perl "hackers", often armed with little more than regular expressions and an acquaintance with the Perl Hash, have accomplished a great deal with improvised CGI scripts and one-line data transforms.

Practitioners of more disciplined languages have frequently condemned the non-conformist excesses of Perl culture. Python countered the anarchic exuberance of TMTOWTDI ("There's More Than One Way To Do It") with TOOWTDI ("There's Only One Way To Do It"). Although I later came to appreciate a more rigorous approach to the craft of making software, I am grateful to the artistic license which characterizes the Perl Way for making it possible to get started on what became my career.

Semicolons and the limits of Aesthetics-Oriented Development

In case you missed it, there has been a dust-up on Github where the author of "JavaScript: The Good Parts" made it pointedly clear that he was not going to extend JSMin to support an energetic application of one of what he calls "The Awful Parts": Automatic Semicolon Insertion (ASI).

Given his unsparing condemnation of "the tragedy of semicolon insertion," Crockford's position on modifying JSMin to be more tolerant of omitted semicolons is predictable.

I find it more surprising that a major project like Twitter Bootstrap is flouting a canonical prescription for effective JavaScript. After all, it's not just Crockford who thinks that relying on semicolon insertion is a bad idea. Consider Marijn Haverbeke in the more recent, also influential "Eloquent JavaScript":

In some cases, JavaScript allows you to omit the semicolon at the end of a statement. In other cases, it has to be there or strange things will happen. The rules for when it can be safely omitted are complex and weird. In this book, I won't leave out any semicolons, and I strongly urge you to do the same in your own programs.

Or Stoyan Stefanov in "JavaScript Patterns":

Just like with curly braces, you should always use semicolons, even when they are implied by the JavaScript parsers.

Nevertheless, there seems to be a robust "NO;" movement. Just a few days go, the author of the Zepto project announced that henceforth the project will be "semicolon-free". One of the maintainers had spelled out his thoughts in a blog entitled "Semicolons are optional," making the same argument as the Twitter Bootstrappers:

Suppose I have code that works in every JavaScript implementation that I target ... If I run it through your minification tool and it breaks my code, then I'm sad to report that your tool is broken.

Node.js core committer Isaac Schuleter even wrote "An Open Letter to JavaScript Leaders Regarding Semicolons." "The leaders in this language community have given you lies and fear," he proclaims. Without semicolons, "you can write code that you find beautiful."

Perhaps he didn't have Backbone/Underscore/CoffeeScript creator Jeremy Ashkenas in mind when he called down plagues on the leaders of the JavaScript community for irresponsibility, dishonesty and a lack of expertise. Nevertheless, Ashkenas was kind enough to respond:

We put semicolons at the end of each statement, even though it's shorter to leave them out, because it's how JavaScript is written, and how others are comfortable reading it.

He makes a subtle point that is worth magnifying: The semicolon is, with a few exceptions, the way that lines are terminated in JavaScript. JavaScript does not use newlines as a terminator, like Ruby or Python or CoffeeScript do. When semicolons are omitted from the end of a statement, it is an error. An error with well-defined consequences is still an error.

JavaScript's creator Brendan Eich, in his response to today's controversy, is more explicit:

ASI is an error correction procedure. If you start to code as if it were a universal significant-newline rule, you will get in trouble.

It seems to me that this dispute highlights a cultural problem in contemporary software development. Code has an aesthetic component with objective and subjective aspects. The movement for software craftsmanship has called attention to the importance of aesthetic values in the production of code which is less prone to error and easier to maintain. But it is possible to emphasize the aesthetic at the expense of more significant concerns, or to emphasize a subjective aesthetic at the expense of universal values.

Announcement: Slickback v0.3.0

Version 0.3.0 of Slickback is now available, adding support for SlickGrid v2.0, the current stable version of SlickGrid. Slickback is a javascript library that makes it easier to use Backbone models and collections with the SlickGrid jQuery datagrid. Slickback v0.3.0 is released under the MIT license and available on github.