Saturday, January 1, 2011

The "private" Keyword Disregards Professional Courtesy

Five years ago (ish), when Ruby on Rails first became an issue for part-time interweb microjournalists to nadger each other about, the arena's 900-pound gorilla was Java. This gorilla's worshippers, to mix metaphors, launched a religious war against the red, jewel-y intruder and its champions. The principal issue in contention: language features.

[picture here a battlefield; an army of coffee-drinking gorillas doing battle with a small, fierce cabal of wizards and pugnacious upstarts armed only with transparent red daggers and exotic magics]

Java, its adherents claimed, was more scalable, not only due to its superior server technologies (which claim had some merit at the time), but also due to the fact that you couldn't make certain types of mistakes. Java was a power tool, an Instrument of Serious Business™, and as such it had safeguards, in the same way that a chainsaw ships with a built-in hand guard to prevent you from lacerating and/or decimating your own appendages. Access control keywords like private, protected, and public, along with the most insanely complex reflection framework known to humanity or indeed any other spacefaring species, prevented programmers from doing any scary "magical" "metaprogramming."

Rubyists countered that it was impossible to prevent bad programmers from fucking up; such restrictions only resulted in a straitjacket which prevented great programmers from doing great work.

Rails saw a huge adoption curve, Ruby went from a bizarre and obscure hobby to an Instrument of Serious Business™ in its own right, and even the fiercest critics of Rails ended up copying its ideas all over the place. Most of us who were around at the time consider the battle firmly decided in Ruby's favor, and consequently consider the larger matter, of programming power vs training wheels, to be an overwhelming victory for the advocates of powerful language features and laissez-faire language design.

But all you young whippersnappers don't seem to remember this. And thus Ruby's own private keyword still sees use, despite the fact that it messes up my code indentation and urinates all over professional courtesy.

We turn now to some ranting from Twitter. Loren Segal asked how on earth somebody was supposed to refactor their code's internals while providing programmers with a consistent API in the absence of a private keyword; I replied that the solution is to simply separate the "private" methods by file and by name, marking them as unsupported and internal, but without enforcing it in the language. Strife ensued.



As with most strife, nothing was resolved. Loren did not change his mind and I have yet to seize control of the Papacy. And so an uneasy tension will persist until the Chosen Day when the the foreign movie that is God anoints me Its Supreme Scribbler of Subtitles. Soon, my brethren. Sooooooon.

In the meantime, I can only rest serene in the knowledge that somewhere out there, in some alternate universe, some Alternate Universe Giles has written a book called Ruby: the Good Parts, and while this book is much thicker than JavaScript: the Good Parts, and much more fun to read, you will not find private on any one of its pages, any more than you would the Perl-y special variables like $:.