Ruby: Language of the Programming Übermensch?
I spent a couple of hours this evening writing my first real Ruby code for the Lexical Semantics course I am taking this fall. It's excellent. The syntax is very appealing. Tokens are strangely verbose, replacing "{" and "}" of C descent with "def" or (insert block starting token here) and "end". For the first 30 seconds after encountering this on page 1, I wasn't sure how I felt about it. It seemed verbose. But now I see that "end" is much easier to type than "}", whose presence in Java forces me to reach and twist for basic program vocabulary. Maybe it would be different if I weren't on Dvorak, but words as delimiters rather than punctuation is a definite win. And while the tokens are fat—in a good way—they are also few. The syntax is remarkably terse, but not at the peril of clarity as I feel is the case with Perl. Ruby makes me understand the power of judicious syntactic support for common tasks. String interpolation is an obvious and immediately addictive feature. Built-in regular expression literals are also a plus. And there is an elegant interplay between these syntactic features on both a functional and visual level. As syntax is concerned, Scheme has represented a year-long exile in the wilderness. The bare minimalism of S-expressions was good for me. Scheme's uniform and parsimonious syntax let me focus on concepts that are fundamental to high-level programming: recursion, higher order procedures, and data abstraction. Scheme taught me by giving me only a handful of powerful tools and then training me to use them well. Now I think that Ruby can empower me by equipping that sharpened outlook with richer facilities for the completion of the common tasks. Its assumptions are friendly to my most cherished and hard-won programming intuition, but they also cater to the harsh realities of programming in an imperative world.
Paul Graham says that languages are evolving ever-closer to Lisp, and he asks, why not skip directly to it? And I think that I finally have an answer. Perhaps the ideal programming experience is purely functional, and the mainstream's gradual adoption of purely functional features reflects this truth. But there are other truths. Tim O'Reilly presents another point. He says that as new computing paradigms emerge, new languages seem to rise with them, suggesting that from a pragmatic standpoint, a language's "goodness" is sensitively dependent on the world in which it is used and with which it must interact. Every time I have programmed functionally for practical applications, I am always keenly aware of how imperative the world outside my program really is. The operating system doesn't behave functionally, and I/O operations certainly never could. There has to be a reason why these languages are so popular, beyond the simple fact that they are easier to learn for programmers whose first language was C. My conclusion is this. In the real world of computing, one finds explicit notions of state; one finds assignment. The computing hyperscape is not (yet, perhaps) very functional. State-oriented computational objects seem a natural complement to our false intuition of objects existing in the real world as well. Nietzsche would say that there are no objects, and, indeed, there aren't even any facts. There is only "will to power". Sounds remarkably similar to me trying to explain to C programmers that there is no data, and there isn't, in fact, any need for assignment. There is only Lambda. I think Nietzsche is right and I think Steele and Sussman were right, but that truth does not mean that the illusion of objects is an utterly worthless one. If we actually cognized the outside world as consisting only of "will to power" rather than tables and chairs and people, we'd never get anything done. And perhaps, similarly, when we pretend that everything is a Lambda, we face similar difficulties in interfacing this remarkably beautiful, completely true notion with an ability to do anything about it.
These ideas, are, I guess, nothing new. Haskell's monad system, from the cursory understanding I have of it, is a formalization of them, a clean interface between the rough and tumble outside universe and the sublime purity of Haskellspace. But if I'm not going to use an airlock, maybe a clever, elegant, and even artistic bridge between functional wisdom and imperative truth will suffice. For now, Ruby seems to be a pretty decent attempt. Lambda may be vulgarized into a quirky codeblock, but in a language in which shell commands are syntactically supported, at least it exists.