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.

Announcement: Slickback v0.2.1

Version 0.2.1 of Slickback is now available. Slickback is a javascript library that makes it easier to use Backbone models and collections with the SlickGrid jQuery datagrid. New features in this version include support for displaying and editing Backbone model fields as text, integers, fixed precision numbers, and for selecting field values from dropdowns. Constructors for non-paginated Slickback collections are also new in this version. Slickback v0.2.1 is released under the MIT license and available on github or via npm.

Announcement: A Plugin Named Slickback

Slickback version 0.1.0 is now available on Github and via npm. Slickback is a javascript library that adapts Backbone collections to work with SlickGrid, a jQuery-backed datagrid. Extensions to Backbone include support for paginating collections and composing filtered queries using an interface modeled after Ruby on Rails ActiveRecord's "named scopes". Slickback, like Backbone and SlickGrid, is released under the MIT license.

At home he's a tourist: FFI for Ruby internals

FFI stands for "foreign function interface". That describes the most common use case: Creating Ruby bindings to external native libraries. But it's also possible to use FFI to spelunk Ruby's internals. Consider:

Foreign? Far from it. You've now got access to all of C-ruby's innards. For example, if you're using Ruby 1.9:

With this you've got a handle on the otherwise inaccessible RubyVM core object. As a pointer, it's not all that useful. But with a little more mischief...

... now you can treat the RubyVM core like any other object. One interesting (if unwieldly-named) method that it offers is "core#define_singleton_method". It accepts an InstructionSequence -- compiled YARV bytecode -- and uses it to set up a singleton method in the object where it is invoked. Let's make it a little easier to use:

Now it is easy to create methods using bytecode sequences:

(Complete code example)

Good Reasons to Use RSpec

It's been recently suggested that RSpec owes its popularity to fashion, and that people don't understand the alternatives. My experience is different.

I've been using RSpec to test Ruby code for about five years. Before RSpec, I used Ruby's Test::Unit, as well as a number of other xUnit-style frameworks for Perl and Java. I was never happy with the earlier frameworks, but I was convinced that unit testing was worthwhile so I made do with what was available.

I switched to RSpec because in very little time I found it more helpful than other frameworks I had used. The reason is this: RSpec helps me to alternate between writing code and writing tests without having to switch contexts.

By using the description of behavior as the model of testing, RSpec answers the question of what to test before you have to ask. It's more than syntactic sugar. It's conceptual sugar. I find that not having to think so much about the testing framework, I'm freed up to think about the tests themselves, so I write better tests and more of them.

RSpec has "no discernible benefit" over other frameworks? It depends on who is doing the discerning. I find plenty of good reasons to use RSpec, and I have a lot of company.