The programming language Clojure is enjoying a surge in recent activity and interest, capped by a presentation by its inventor at the end of the Lisp50 program at OOPSLA. Lispy has a good recounting of Hickey’s talk on his blog. There’s interest in forming a study group here in the DC area, under the auspices of Fringe DC. And Clojure is appearing in a lot of blogs I’m reading, surrounded by almost dreamy language like “nirvana” or “I should / wish I were learning this now.” I’ve sat down with the beta version of Stu Halloway’s Programming Clojure, and I’ve read the first third and coded up some examples, and I’m very excited with what I’m finding.
I’ve been spending too much time with javascript lately. It probably isn’t healthy for me. I’ll get back to my own Clojure project and paying Ruby work soon enough, but right now I’m working on an interface-intensive project, so I’m up to my neck to explicit returns and key:value notation.
I was looking into improving my code (less coupling, more encapsulation, greater readability for me when I inevitably come back to extend it), and that led to some playing around with call, apply, and a prototype.js library method, Function#wrap, that puts this sort of casting and scope-alteration to use to enable metaprogramming. I sensed I was skirting the edge of a real revelation about how functional programming meets OOP in languages like javascript. But that’s for another post. Right now, I’d like to bite off more than I can chew on a different topic: how straightforward it appears to be to implement some RSpec-like Behavior-Driven Development specification-testing magic on javascript objects using Function#wrap.
So I’m building a web application that uses javascript (with the canvas element) to draw a chart of student grades over a period of time. It also lists each grade in a table on the side of the chart. Since the grade data is dynamic (coming in the form of JSON either at page load or asynchronously upon update), I have to draw the table programatically. For a while, I did this in a really nasty way, then I discovered the Prototype.js Template class and javascript’s own Element.cloneCopy function. And then it started to get all better.
(Update: It turns out IE wasn’t as amenable as I thought, so I’ve updated the code for working with the cloned table node below.)
I haven’t posted anything to this blog for a while. Apparently I’m not alone. Not blogging is the new blogging: so says Wired. My Scheme-mate Chuck seems to have thrown off his blog as a matter of self-preservation. At the same time, we’ve both been active on Twitter. It is a lot easier to fire off a pithy comment on Twitter than log into WordPress and compose something anyone can read. But Twitter can’t replace blogging. And just because blog posts are harder to write and the standard for their quality has gone up–that’s no excuse to give up.
Long-time blogger Tim Bray recently put up a post called On Blogging in 2008 about his idea that blogging is best for medium-length thought-expressions: shorter than a book, but more substantive than a simple remark. I think this is an excellent formulation. Few of us write books (and even fewer write more than one), so the essay is a vitally important vehicle for communicating and collaborating. It’s also a worthwhile exercise even if no one else reads it.
When I was last working full time, I sort-of managed projects with cranky developers. You were guaranteed to anger a developer by asking for a description of their progress. “I don’t have time to talk about it.” I’ve been the developer in this scenario too, and it does kind of hurt to have to stop working with the machine and try to put your problems into English. It seems like lost effort. But funny enough, I think it hurts because it’s work. And it’s fruitful work too. Not only do you communicate with another person who may be able to help you, but putting your thoughts into words kind of builds up your thoughts too. Often enough I find the answer to a question or find a pattern in a problem just by trying to describe what I’m doing.
So blogging is good. And I need to get back into it. I’m looking for freelance work again, and no one should take on a freelancer who doesn’t blog, or otherwise contribute, for anything more complicated than a web page. Also, I have some things to share. I’ve been doing some really interesting things with Javascript. I’m getting much more adept with Rails and RSpec. And it’s looking like we’re going to have a Clojure study group here in the DC area this winter. So let’s keep up the conversations.
I’m still going to keep twittering, though. It’s just too gratifying to imagine I’m a brilliant wit.
A little while ago I posted about my indulgent use of a linked list in a Ruby on Rails project I’m working on. The list allowed me to define the linked objects’ methods in the recursive case analysis style I’ve learned from programming in Scheme. I wrote that I was surprised that this decision hasn’t felt unnatural and has proven fairly easy to build upon. Each object in the list is also the head of the remainder of list (from that object to the end), so you can call methods on that single object and all the recursion necessary to find the information you want is abstracted behind the object’s interface.
Today I got a few minutes to play around with an idea I had while on vacation: implementing an each method on the grade range class so that I can include the Enumerable module, in case I wanted to use Ruby’s rich set of functional structures on the list. It turns out to be a piece of cake!
An old friend of mine, Harris Wulfson, passed away suddenly last week. I hadn’t seen him in years, and we’d only run into each other once since we worked together at Music Boulevard in the 90’s. That running-into happened at a Jazz show in Brooklyn, NY. Harris was a musician and music composition grad student as well as being an excellent software developer.
What I remember most vividly about Harris was the way he developed possibly the most important application in the Music Boulevard platform, a bulletin board system that brought together music fans and generated a lot of unexpected traffic and sales, as a skunkworks project. In fact, he built it when he was supposed to be doing other things — I remember other colleagues of mine complaining that he was dragging his heels updating HTML pages. I’ve never forgotten that. He contributed the most when he was supposed to be doing something else.
Harris is one of the few real-life hackers I’ve ever met. I don’t call him that because he produced a lot of cool software. Music was really his passion. (Although maybe he did — I don’t know because we fell out of touch ten years ago.) I’m thinking of his attitude. He understood that the best use of his time fell outside of doing what he was being told to do. He had an intuition, an itch, and he followed it. Not necessarily the best trait for an employee — it’s more reminiscent of a jazz musician.
Calling Harris a hacker in the days after his death isn’t meant to pay him a compliment. Really, it’s the other way around. Harris improved and expanded my appreciation for improvisation, risk-taking, and, yes, good coding. I don’t think better of my friend because I think of him as a hacker. I think better of hacking because of what I learned from Harris.
I recently realized I have more things tagged ruby and toread on del.icio.us than I can possibly hope to process. I’ve never been close to a developing technical community before, if following blogs and news sites, and occasionally trying stuff out for myself counts as being close. Is this how it normally goes? Just when you feel like you’re keeping up with one web framework, here come two more. Finally got the hang of Active Record? Forget that, it’s for losers! All the cool kids are using something else. Thor’s Hammer? Johnson? Good grief. Take a look at RubyFringe’s program. Are you on top of all that?
Maybe it’s just the process of better things displacing others, or spurring them to improve themselves and compete. But I wonder, how many of these new technologies will survive the calendar year? Maybe you should look now, and don’t blink, because this looks more like churn to me. There’s nothing wrong with that — sometimes a good idea won’t make it big, but it influences a slicker execution, albeit one you’d have to learn an entire new language to use. Heck, maybe Ruby will only serve to get us all programming in Erlang. One thing is certain: grokking a new framework, or a continuation-based web server, or an ancient programming language, isn’t a task for a single distracted afternoon. It’s going to continue to be hard work.
Nathan Sanders‘ recent post about functional programming in Ruby includes some advice about not trying to force too much mapping and folding into Ruby. Here’s how he expresses it: “Ruby! OOP! Remember?”
But I couldn’t help myself. I spend a good deal of time these days in student mode, programming in scheme, and I really like the elegance of recursion, especially when it’s used on data structures that support recursion and iteration, like linked lists. So I indulged myself a bit while writing some practical Ruby code. I marked it mentally as something I would probably have to come back to and replace, but a funny thing happened. I still like it. I think it works really well.
I decided a couple of months ago that my haphazard unit testing practices were not covering enough of my Rails projects’ code. It’s easy, when you’re the only developer on a project, to get pretty lazy about a lot of things, and testing is one of them. See, I believe firmly in testing. Untested code is unreliable code. I wanted to be more rigorous. So I decided to use RSpec. I’d been poking around it for a while, but I decided to commit and dive in. It has been a rocky road. Read on for my Pro-and-Con review of programming with RSpec.
Quite some time ago, I set out to work through the course materials at MIT’s OpenCourseWare website for the introductory Computer Science course Structure and Interpretation of Computer Programs. I wanted to tackle the fundamental CS concepts that the course presented, but I also wanted to learn Scheme, the elegant Lisp dialect that SICP uses to illustrate its concepts. I was lucky enough to have some excellent help from a group of people who wanted to work through the course together. However, the going got tough, pressing business pressed, and soon I was stopped. Last month, I got started again. I worked through the environment model, which is itself worthy of a post, but what I’d like to discuss right now is the section on object-oriented programming, which surprised and then delighted me. Not only is OOP possible yet cumbersome in Scheme, but its very cumbersomeness has given me a deeper understanding of OOP than I’ve gotten from object-oriented languages.