The Snowtide Blog

While at dinner with a friend of mine a couple of weekends ago, we got to talking about how certain programming problems, usually the hardest ones we’ve faced, are ones where we ended up having to simply work the problem: stare at the code, stare at the reference / specification / dataset, hunker down, and plow through the tough stuff with more determination and tenacity than engineering or design rigor. While we were talking about this dynamic, I inadvertently summed up that kind of experience and approach with what I think is a pretty apt phrase: sometimes, you just need to “burn it down” (’it’ being the problem at hand).

The phrase “burn it down” has been rattling around in my head incessantly since then, so I’m hoping to exorcise it here. Perhaps the reason why it’s stayed with me so long is that there’s a pretty good chance that that phrase has a lot of applicability to life in general. Looking back over the years, I’ve often found myself in situations where the key to survival and (ostensibly) success has been my ability (tendency?) to wage a war of attrition against that which stands in my way.

The most immediate case is a programming challenge: you’re sitting there trying to solve a problem for the umpteenth time, and the algorithm in your head or on the page in front of you is laughing at your inadequacies. Ideally, you’d like to step up to the whiteboard, and bang out a description of how this data structure should look, a proof for how that graph-walking algorithm can be sped up by an order of magnitude, whatever. I’ve seen programmers do this – they’ll pull out a small pad, and in about 8 minutes, they’ll knock out some pseudocode for an implementation of some algorithm that might take you an hour to comprehend, never mind implement.

Unfortunately, only a vanishing minority can seize hard problems like that on a regular basis; the rest of us are left wanting to be smarter than we clearly are. So, despite all of your hopes, your text editor simply stares blankly at you, the whiteboard is inert, and you’re left with two options: failure, or the last resort of the almost-overwhelmed, unyielding determination.

(This is very simply the same thing that Edison talking about: “Genius is one percent inspiration, ninety-nine percent perspiration.” Of course, I don’t think we’re in genius territory here…competency, perhaps?)

I’ve experienced that exasperation so many times while working on PDFTextStream and other Snowtide products. I’m fond of saying that I’m a math idiot, and while few people believe me, it’s entirely true. There are things in PDFTextStream that required me to slowly, painfully learn more about esoteric corners of computational geometry than I would ever care to know otherwise, and the same goes for various other specialties in mathematics and computer science. For me, understanding formalisms in those fields is like feathering a chicken by running it through a keyhole. The only way I’ve been able to ship a single bloody line of code has been to Burn It Down.

Of course, programming is a very narrow domain, but I think the same strategy is the only tool that us humans have to use in coping with the crush of life and disorder that surrounds us. Through growing up, getting an education, finding a job, starting a business, sustaining a life partnership, raising children, and coping with the march of time, the only common thread of human endeavor is rage. Even that majickal 1% of prodigies and bona fide geniuses have areas of their lives where their only hope of enduring is to simply endure. In a way, it’s comforting to know that despite the pretensions of some, the only sure way to succeed in programming (and likely even loftier domains) is to lay siege to (or perhaps, depending upon your mindset, to practice judo with) whatever challenge is ahead.

The day is young. Burn, baby, burn.

We have one open position, and we are also accepting internship applications. Do you feel up to a challenge?

Last night, we had the privilege to host a talk by Rich Hickey on concurrency in Clojure at our offices in Northampton.  A good portion of the Western Mass. Developer’s Group showed up for the event.  Many thanks to Lou Franco for coordinating things, and Shawn Fumo for arranging to have Rich’s talk taped for posterity (a link will be coming soon, I would think).

And, of course, thanks go to Rich who took the time to make the drive up to Northampton from New York City.  (Fanciful thought: does this mean that the developer’s group constitutes a programmer’s oasis?  Is Western Mass. the new center of gravity for innovative software development in New England? *wink*)

Lou’s notes on the talk itself capture its content far better than I’ll dare to attempt at this point.  Suffice it to say that it was a great presentation by Rich, who clearly has a penchant for teasing apart complex topics and evangelizing Clojure very effectively.  Luckily for the rest of us, there are a number of other talks about Clojure by Rich floating around in the ether.

It should come as no surprise to anyone who knows me at all that I love what Clojure has come to be.  I followed Rich’s prior attempts to marry Lisp and Java (specifically, Foil and jFli), but Clojure tops those efforts handily on essentially every front.

But, what of my fervent love of Scala, so earnestly professed in this very space?  Clearly, I’m not particularly monogamous when it comes to programming languages.  Clojure and Scala have a lot in common, but they are very, very different from each other — although they share the common traits of (a) being better than “straight” Java in so many ways, and (b) enabling functional programming on the JVM (and of course, .NET via ikvm).  You can love both; maybe it’s a right-brain, left-brain thing.  (I can clearly imagine Professor Stillings scowling at me for that one.)

Anyway, again, a big ‘thank you’ to Rich Hickey and everyone else who made last night possible.

In a thread on the Google Group dedicated to discussing languages hosted on the JVM (i.e. Scala, Groovy, JRuby, et al.), it was asked by a fellow named Jon Harrop whether something like F# (an OCaml / Standard ML derivative that targets the .NET CLR) would find any traction if it were made available for the JVM. Well, some unremarkable discussion ensued about the costs associated with developing languages, how existing efforts attract funding, etc., and then things turned towards the question of “Why not just use Scala?”, since Scala does fold in a lot of functional programming primitives.

Mr. Harrop’s replies centered on various aspects of ML-style languages that he misses in Scala, and aspects of Scala that he finds irritating. All fine and good — hey, everyone has their own preferences — until he unveiled this nugget (emphasis mine):

OCaml and F# have shown that ML’s approach to structured programming using modules, variant types and pattern matching and extensive type inference is almost always preferable to OOP. When given the choice between OOP and FP, seasoned programmers rarely choose OOP.

Zealotry isn’t anything new — you can probably find inverse statements right now in some Smalltalk newsgroups, or someone agitating about the uniform superiority of s-expressions in a Lisp or Scheme forum. The odd thing about this is that Mr. Harrop is not exactly a random troll — he seems fairly well-respected in the F#/OCaml/ML community, is a prolific writer, and looks to be writing a book on F# for Microsoft Press.

Stuff like this makes the whole facade about software development being akin to engineering even more farcical than one might initially imagine. Can we please recognize that there is a difference between spirited advocacy and demagoguery? I’ve certainly been guilty of the latter on occasion (usually much to my later regret), but it’s particularly irksome to find those that are apparently unaware of the distinction at all.