Tim Boudreau's Blog

January 2006 Archives

NetBeans' portability matters

With NetBeans, exactly the same bits run on any platform with a 1.4 or greater JVM - there's no native code to worry about. You can take the zip distribution, just unzip it on any machine with a modern JDK and there you go.

And more importantly, working with a J2EE project requires no configuration, no additional downloads - it just works out of the box, which Charles also points out.

I thought I'd never see the day...

What a lovely thing to read over my first cup of coffee on a Tuesday (de-facto Monday - yesterday was a holiday in the U.S.) morning. It's going to be a good week :-)

Everett Hafner, a belated eulogy

In college I took Electronic Music. My TA was Everett. I had to pass an interview to enter the course. My music reading was abysmal, despite having perfect pitch - when I took piano, it was always so easy to memorize what I had to play that reading music never sunk in - I'd play it once and then study the notes when I got lost, until I didn't get lost anymore. My music teacher finally bagged me, noting that my my mistakes were always "musically correct". That left me fantastically underprepared for a grad-level music course as a freshman.

Most professors would have booted me out the door; Everett asked me to hum intervals and probed my ability to understand music and arrange - he actually was interested in my native ability, not formal training, and just took an unorthadox approach based on my mental model for music, rather than the formal model of written western music. I hummed intervals. And he let me into the class. It's rare to meet someone with the interest and the ability to intuit how someone conceives of a topic, and then measure their ability through their conception of it, instead of simply measuring their amount of formal training, which is much less work.

Everett was a physicist, and had been one of the designers and founders of Hampshire College in the 60's, and was dean of sciences until his retirement, already in his 70's I believe. At which time he decided to get his PhD. in music at UMass and learn to fly planes. That alone I admired - and hadn't encountered before. Here's a man in his seventies getting his pilots license and a PhD. in a discipline completely unrelated to his former career (though he had been a pioneer in electronic music in the 60's). Seeing him changed what I could imagine for myself as I get older.

He was eccentric - I don't know if he owned a car, but he often needed a ride home to Williamsburg after class, and so we got to talk for the forty minute ride - I lived in Northampton, Mass., so it was only a little out of the way. Once he asked me if I wanted to "go up" in the plane, but I declined - somehow I thought I'd be imposing. Despite what would later happen, I wish I'd said yes. A few times he invited me in, and we would talk about music theory, or unrelated things - and always in the middle of a conversation, he would simply say "Well, run along now..." - I was dismissed. He had this giant light bulb, manufactured in 1919 and still working, mounted with a giant transformer in the electronic music studio. A former colleague of his, and father of a boyhood friend, once told me "Everett has ten ideas a minute, and half of them are bad."

Some stories I remember:

• Someone commented on something political in class, and he responded "You cannot be in a situation you don not choose to be in." Arguments of all sorts of horrible things were brought up as suggestions for situations you can't possibly choose. He just stuck to his guns and repeated the statement with infectiously complete assuredness. I'll never know what precisely he meant by it, but that moment and phrase has been rattling around in my brain in the decade and a half plus since, and it is the most empowering way to bring yourself to understand that you can bring yourself out of adversity. I wish I had asked what exactly he meant.
• He was the man behind setting up the science labs at Hampshire College at the time it began, with no walls or divisions - all disciplines should work in the same building or room, so people communicate and synergize, rather than being isolated specialists. And, as he told it to me, one of the big rules was that there would be no locks on the equipment lockers. He claimed that the whole time he was dean, there had never been a theft. And that one of the first things that happened after he retired was, they put locks on the lockers. And the very next day had their first theft. I will always remember that as a lesson in the communication value of things like locks and fences - that they are as much an invitation as an impasse.^*

  ^*(It was that story and the thinking behind it that inflenced me to argue strenuously against segregating NetBeans CVS permissions by project, but instead to continue our original practice of giving all committers permissions to write to the entire repository. I lost that battle.)

• We spent one entire electronic music class (in which, oddly, there were six students, four of whom were named Tim) discussing his theory that intelligent life had to evolve on Venus before it evolved on earth (it centered around some synchronicity between the earth's and venus's moons' orbits)

What I admired most was his open mind and ability to think way out of the box. And that in his seventies, he was more alive than many people I knew in their twenties, engaged with the world and interested in new things. I pray I am so lucky.

In the fall of '99, when I was working in Prague, I googled his name - hoping to find an email and reconnect. And found his obituary. He'd died in a plane crash, flying his Cessna. I cry rarely, probably too rarely, but I did at my desk that day. He was such an ageless presence that it was impossible to imagine him gone - it is to this day. And it was also for him. He died doing something that he loved. Having seen family members go slowly and painfully, I hope that I die doing something I love.

So I write this today, because I find after all these years, I still mourn Everett Hafner. And googling, I was surprised to find out how many others had similar things to say and fond memories. I'm sure some of the fifteen year old memories I've written here are off in the details, but not in the essence.

For the subtle influence he had on the course of my life and my thinking, I can only say a, far too late, thank you.

Of saxophones, westerns and the sense of beauty in programming

Today I read a Swing tips entry which had some spectacularly bad advice in it - replacing the AWT EventQueue as a way to do something trivial you can do without altering the guts of the entire windowing toolkit. I posted a rather strenuous reply saying "You really, really, really don't want to do that."

After I wrote it, I had some shopping to do. As I drove, I found myself thinking - there was a time when I would have been on the opposite side of that argument. That got me thinking about how one’s sense of the good, the bad and the beautiful in programming evolves over time. I can't say my experience is the same as anyone else’s - but I wonder what parts of it are common to many people who have spent some years coding. So I'll try to capture how I've experienced this - the observer and observed being one and the same - in whatever language loosely feels right. If it resembles your experience, let me know.

Whenever I'm coding anything, there is a sense of, for lack of a better term, beauty that's very clear in my mind. It's usually involved with the goal of the project, but it can be indirectly related. It's the thing that I make Important-with-a-capital-I for myself. On less than inspiring projects I was hired to do in my contracting days, it was the whip I used to motivate myself - I'm going to write the most gorgeously designed emulation of a DOS app in cross-browser-compatible javascript that's humanly possible, dammit (I'm not kidding, that was a real project - the motivation worked, but finishing it after five months of occasional 100 hour weeks, I said "never again" and moved to another country!). It's a good skill if sometimes you do have to work on something that would otherwise be suicidally gosh-awful - to learn to find something to love in any project - and it's equally a good skill when you're working on something you love from the get-go.

The thing that I find beauty in is different from project to project. When I put together the Wizard API it was going after the cleanest, lowest profile possible API for a known problem; when I rewrote the output window in NetBeans, it was how to optimally use NIO and the text API to have a component that could wrap and scale to hundreds of megabytes of text without a hiccup, be blazingly fast and do as little bookkeeping as possible. It doesn't have to be inside the code either - I've written things where the challenge I set for myself was to create the most intuitive user interface possible. I've got a cute little framework for managing actions for Swing apps, which arose from my earnest desire never to write or read another anonymous inner Action or ActionListener class. The thing that is beautiful is the thing that challenges me - the place where I'm pushing against the limits - the limits of what will be different every time.

Pushing against limits is the key. That determines what I’m going to be proud of in the result. And limits are key. Why is a saxophone almost always more expressive than a synthesizer, when the synthesizer can produce an potentially unlimited range of sounds? Because the limitations of the saxophone force the player to work within tight constraints, and be expressive anyway. The saxophonist has to work hard. It's easy to write free verse that communicates whatever idea you want. Saying the same thing in a sonnet and not having it sound ridiculous or forced - that's hard. Greatness is when the work escapes the boundaries of the form. The reason the movie Unforgiven is a masterpiece, IMO: it takes every trope of the "western" and stands each one on its head – it is the definitive anti-western – yet it is also still a western.

I find that starting a project involves a sort of mental bearings-taking - exploring the conceptual space of the problem, finding where the limits are - finding the thing that needs to be beautiful, the thing that will engage my passion. It's settling into the problem space, getting to know where the where the walls are, getting comfortable in the furniture, getting an idea of what kind of construction this space wants to contain. By the time that's done, most of the code is going to write itself - now the joy is in discovering the subtleties. Coding for me is very visual, in an abstract way - I can't quite describe what the for loop that's calling the method I'm editing looks like, but I can quite definitely see it chugging away, and so on back to what all the parts of the application I know of are doing.

When I was a teenager, one of my favorite coding tricks was to see just how much logic I could condense into a single line of code. The ongoing challenge was to see just how much I could do in how little space. A particular favorite was resolving booleans to 1 and -1 and then doing various math tricks with the result. I think I was 19 before, when fixing a bug, after spending two hours trying to decipher what one inscrutably complex line of my own code did, that I decided I'd better get my coding thrills some other way (if you've ever coded like this, you'll enjoy the story of Mel).

It involves ego. Whether it's the gratification of creating something I use the word "beautiful" to describe (and it may only be beautiful to me), or the gratification of being clever and pleased with myself, or the gratification of knowing someone else will enjoy using what I have written, or the gratification of creating a UI that users will find intuitive and love. It might all come from a desire to be loved or appreciated, or just to do something meaningful, to have certain knowledge that I have made a difference. Ego is not a bad thing - we would be poor creatures without it.

The study of inspired error should not engender a homily about the sin of pride; it should lead us to a recognition that the capacity for great insight and great error are opposite sides of the same coin - and that the currency of both is brilliance - Stephen Jay Gould

One era in my sense of beauty was the hack phase - where the beauty was in getting a piece of software to do something its designer never thought of. It can manifest in brilliant hacks, uncovering that some library or utility has a whole new vista of possible applications. It can manifest in evil hacks, where I'm doing the equivalent of wrapping a toaster in tin foil and using it to make coffee, because a coffee pot is a thing that makes things hot, and so is a toaster. There is a real sense of mastery that is very gratifying when they work. And there is even a place for them - its a kind of resourcefulness that's very useful in "get this working again or be shot at sunrise" situations. And I think that was the sense of beauty that led to the terrible advice I read in a programming tip this morning.

API design is a whole parallel world to straight programming, which has its own aesthetics and rules - it's the meta-space around any problem space where what you write has to interact with other things. I know my sense of what's right and wrong, good and bad, has evolved enormously in recent years, and continues to. If you ever get a chance to work on a large codebase with a long history and lots of APIs, take it. It will make your outlook grow in unexpected ways. The beauty in API design is how to design it so users will enjoy using it, and at the same time leaving the API clean and small, with room to grow and evolve without breaking anything. It's an excercise in practicing kindness and decency both to the people who will use it, and to yourself, for you'll have to maintain it; and at the same time designing an API that's complementary to what the computer will phsyically need to do to accomplish whatever the task is (the Responder pattern in Cocoa is a lovely example of doing all three of these things).

I have found a different thing to be that-which-is-beautiful in every project I've ever done. I don't know that the same thing can be beautiful to me in the same way twice. But each solved problem becomes a piece of mental tooling I can use with confidence in the future. Today's brilliance is tomorrow's boilerplate, and I wouldn't have it any other way. What would be tragic is to become stuck, to stop evolving – if the code I write two years from now looks just like what I would do today, something will be wrong.

I think if you work as a programmer, and you master your sense of beauty, so that you can find the thing that is there yearning to be born in any project, you’ll never have to "work" another day in your life.

This work is licensed under a Creative Commons License.