Kevin's Weblog

I’m now on Twitter. I’d been sort of contemplating it for a while, but Selena finally talked me into it while we were out #drunkgeeking last week. So far only 25% of my tweets are about what I’m eating.

I took the shotgun approach to this year’s OSCON call-for-proposals and submitted 3 talks. My biggest fear was actually that all three might get accepted. But, it worked out as I hoped and they picked just one. I’ll be talking about “Beautiful Concurrency with Erlang”. The talk will be an improved and expanded version of my presentation to PDXfunc last month, demonstrating how easy it is to convert sequential programs in Erlang into concurrent / distributed programs taking advantage of your multi-core machine, or a cluster of machine.

I’m slightly nervous, because I’ll freely admit that I was likely selected to give this talk more because I’m good at writing proposals, than because I’m the most qualified person out there to discuss Erlang. That said, I’ll make an effort to draw on the expertise of others to help make the talk as good as possible and as effective as possible at drawing new people into the community.

As a minor aside, I’m currently scheduled for Wednesday morning, which is ideal as far as I’m concerned. I get to give my talk, then relax and enjoy the remaining 2 days of the conference.

Paul Graham’s latest essay, You Weren’t Meant to Have a Boss, has caused quite a stir. Although I thought the discussion of the pathologies of large organizations was interesting, the assertion that only startup founders are living life the way they are meant to (lions on the savannah, rather than caged animals) really rubbed me the wrong way. The Cliff Notes version attempts to smooth things over, but in a way also basically says that employees are choosing to live in cages.

Graham starts his essay with an anecdote about a recent experience that he feels demonstrates his point. After spending some time thinking about why I felt his point was wrong, I realized that I also have an anecdote with relevance to share.

I happen to have a friend(1) who is in this YCombinator round. Last week I was in the Bay Area for a couple days, so I dropped him a line to see if he had time to meet up for dinner. He replied that my timing was good, because I was there the day after “demo day”, so they had a day off(2). We met up in downtown Mountain View and went looking for a place to eat that fit his budget: $10 entrees would be okay, but $15, as was common at most of the restaurants, was too much. At dinner, I kvetched about Yahoo, and he kvetched about YCombinator. I talked about my jaunt up to San Francisco the previous evening to meet up with friends for excellent cocktails (on another trip it might have been a great restaurant, or an art museum, or hiking on the beach or Mt. Tam). It turns out he’s been in Silicon Valley since December but has yet to make it into SF. He also only gets to eat out once or twice a month.

Unlike Graham’s conclusions drawn from a couple minutes of observing strangers, I’ve know this person for over 10 years. I’ve seen him go through good times and bad times. I want to be fair; he’s far from the least happy I’ve seen him. But I also definitely wouldn’t say that he’s the most alive I’ve known him to be either. I definitely didn’t feel like a caged animal in comparison.

Even in the case of these founders that Graham describes who are passionately consumed by their work, I still question the assertion that they are living life as they were meant to. How much time do they spend with friends and family? Do they get to enjoy the amazing city they live just outside of? Can they go out to dinner without having to count their pennies?

By some argument, perhaps this is how we were “meant” to live, in an evolutionary sense. Historically humans spent almost all their time hunting and gathering and performing other essential survival tasks (i.e., working). The modern concept of leisure is, perhaps, evolutionarily unnatural. But regardless, the fact is that productivity has risen to the point where most people can work 40 or so hours a week and produce enough to cover their needs (and a reasonable amount of their wants). We can accept being less than fully self-actualized at work in exchange for the ability to pursue a variety of other activities during the remaining 60 hours of wakefulness we have each week.

Furthermore, Graham seems to assume that all people share the ambition to produce exceptional results at work. I assure you, they do not. I know plenty of people who wouldn’t complain too much about the “team-building” exercise he scorned because, hey, they’re getting paid to run around Palo Alto on a silly scavenger hunt, rather than having to sit at their desk. While coworkers who accept average results may sometimes be frustrating to those of us who aspire to greatness, I still have to admit that I sometimes envy the folks who can manage to just not be bothered by whatever is going on at work, and who can just go home at 5 and put it out of their mind until 9 the next morning.

Are there people working big company jobs that deaden their souls? No doubt. Are there startup founders who are fully alive, in all parts of their life? Probably. But in both environments, there’s a more diverse set of experiences than Graham is admitting to. Furthermore, there’s also a diverse set of goals — people don’t universally agree about what living life fully means. Failing to acknowledge that, and putting down people with different values as a result, is the fundamental flaw in Graham’s essay, in my opinion.

(1) For a couple reasons, I’ve chosen to keep my friend anonymous, unless, of course, he chooses to reveal his identity.

(2) Does it strike you as odd that the startup founders at YCombinator apparently get told when they can take a day off? Me too. My friend informs me that what he meant was that he had granted himself a day off. My apologies for misrepresenting the comment.

Yesterday, I finally made it to one of the Calagator code sprints. I’ve been interested in this project since I first heard about it a few weeks ago, but the timing just hadn’t worked out until now.

The code sprint format was a lot of fun. Often I struggle with focus and motivation to work on my side projects, and getting a small group together all hacking on the same thing seems like a great idea. Also, because they are using pair programming I felt like I could contribute right away, even though my Ruby and Rails knowledge is minimal. I know just enough to be able to read other people’s code and usually understand the gist of it, although on my own I would spend 99% of my time looking up stuff in the docs. But, with someone else doing the typing while we talked through a new feature, I could help distill the algorithm without getting bogged down in the syntax.

During the couple hours I was there, we implemented de-duping of events and venues when a specific source is re-imported. I believe this code is now live, although it looks like there’s still some old duplicates remaining to be cleaned up. Something that was particularly nice about implementing this feature was that it was one of those satisfying cases when the codebase actually ends up cleaner and better factored when you’re finished adding as feature than it was before.

I’m definitely looking forward to participating in more of these sprints in the future. In the mean time, I’m going to spend some time trying to get familiar with the code base, and picking up my Rails reading again; and try to get to the point where I could contribute on my own. Perhaps I’ll try to squash a bug or something.

I spent most of yesterday hunting down a segfault in one of our unit tests. Here is a greatly simplified version of the code: can you see the bug?

#include <string>

void bar(size_t* len)
{
  *len = 0;
}

int main(void)
{
  std::string buf;
  int len = 255;

  bar((size_t *)&len);

  return 0;
}

Here’s a hint: maybe it doesn’t segfault for you.

Hint #2: the segfault is in basic_string::~basic_string().

(more)

Last night I talked at PDXfunc a bit about Erlang. The slides were pretty minimal, so I don’t think I’m going to post them publicly at this point. We spent more time looking at code and demonstrating features that way. I showed a very similar IRC bot as in the talk I gave to PDX.pm on POE and Erlang, although I had actually made a change that introduced a small bug (and failed to test the code before my live demo). But, this worked out to be a positive because I got to demonstrate hot code updates and fixed the bug while keeping the bot up and running. I also showed some code I’ve been working on in the last couple days, once again writing a web spider, this time in Erlang. Unfortunately, I found some problems in xmerl that required heinous workarounds, and I still had some bugs by the time of the talk, but I got to demonstrate the important bit, at least, which was that by replacing a single map with pmap, I could make my sequential program concurrent, proven by the fact that it hit one of the remaining bugs and crashed much faster :-).

At some point soon, I’ll write more about the spider code and my experiences with xmerl, but I want to work out the remaining bugs first.

Last night at the Portland Functional Programming Study Group, someone claimed that 90% of learning Haskell is figuring out monads. I replied back, “The problem is that the first 90% of learning Haskell is figuring out monads; the second 90% is figuring out arrows; the third 90% is figuring out monad transformers...”

In seriousness, we had a good discussion about the issues “practical programmers” have with using Haskell, which largely has to do with the need to learn seemingly irrelevant mathematical abstractions to get almost anything done. Sure, the difficulty of doing IO is vastly overblown. However, if you looks at my series on writing a web spider (1, 2, 3) you’ll see an example of this. HaXML failed, not because using monads is hard, but because properly separating pure and monadic tasks is hard. In particular, parsing a DTD is not a pure function! HXT required learning about arrows, then about derivatives of regular expressions. I ran into a problem with leaking file descriptors, which I assumed had something to do with laziness so I learned about strictness annotations, but in fact Paul Brown recently showed that it’s actually an error handling bug in Network.HTTP. I finally got a working program, which I then proceeded to never use because it takes too damn long to run and trying to figure out how to add concurrency just felt too overwhelming at that point, as it would undoubtedly require some new abstraction to learn, and I was just out of steam.

Recently, Reg Braithwaite wrote about Object#andand, a method for chaining computations that can fail. It’s not clear from his post if he realizes it (maybe he considers it a completely uninteresting observation), but he’s become the latest person to reinvent monads. In Haskell, his proposed &&. operator is spelled >>= (and is significantly more general, as he’s really only created the Maybe monad).

(Although I originally claimed the second half had no similar connection, after thinking about it more, I now retract that. Haskell’s >> operator chains two computations, ignoring the result of the first; in essence performing it just for the “side effects”. Object#me and returning have a similar flavor, although they permit a far wider class of side effects.)

59) Set up a backup system

Apple made this a lot easier for me:

This still isn’t ideal. I’ll be swapping cables around between machines until I get a Time Capsule, or Apple restores the ability to backup to network drives. But, it’s certainly a vast improvement over no backups at all.

It’s been about 10 years since I did anything more than dabble occasionally with C++. The last time I did any serious programming in the language, the compiler support was bad enough that you couldn’t really use most of the STL. Now I find myself actually using this stuff instead of just reading about it, and I’m realizing something. The reputation that functional languages have for incomprehensible error messages is completely undeserved. An exhibit for your consideration:

info_header.c:425: error: no match for ternary 'operator?:' in '__gnu_cxx::operator== [with _Iterator = dr_hash*, _Container = std::vector<dr_hash, std::allocator<dr_hash> >](((const __gnu_cxx::__normal_iterator<dr_hash*, std::vector<dr_hash, std::allocator<dr_hash> > >&)((const __gnu_cxx::__normal_iterator<dr_hash*, std::vector<dr_hash, std::allocator<dr_hash> > >*)(&pos))), ((const __gnu_cxx::__normal_iterator<dr_hash*, std::vector<dr_hash, std::allocator<dr_hash> > >&)((const __gnu_cxx::__normal_iterator<dr_hash*, std::vector<dr_hash, std::allocator<dr_hash> > >*)(&(&ads)->std::vector<_Tp, _Alloc>::end [with _Tp = dr_hash, _Alloc = std::allocator<dr_hash>]())))) ? 0l : (&pos)->__gnu_cxx::__normal_iterator<_Iterator, _Container>::operator* [with _Iterator = dr_hash*, _Container = std::vector<dr_hash, std::allocator<dr_hash> >]()'

What happened was that I was trying to return a structure, rather than a pointer to the structure, from a function. Now, GHC would have given me a nice message that said that: expected type *Foo, inferred type Foo, etc. But, g++ barfs this ridiculous monstrosity. I don’t think anyone can reasonably argue that this is clearer.