Posted by Tom Moertel Fri, 11 Apr 2008 15:58:00 GMT
Via Chris:
$ history | awk '{print $2}' | sort | uniq -c | sort -rn | head
196 git
110 l
102 cd
70 make
34 darcs
30 pushd
23 ssh
23 m
23 ls
20 rm
The l and m commands are aliases:
Posted in interesting stuff
Tags life, memes, programming
1 comment
no trackbacks
Posted by Tom Moertel Thu, 08 Dec 2005 22:35:00 GMT
I have been following with interest the debate about “humane” vs. “minimal” interfaces, sparked recently by Elliotte Rusty Harold’s response to Martin Fowler’s HumaneInterface post.
Harold writes:
Martin Fowler’s a really smart guy, and he’s pretty reliably right; but today he manages to get it 180° wrong. A 78 method List class is about three times as bad as a 25 method List class, not three times as good. A 12 method List class would be about twice as good. Simplicity is a virtue for both users and implementers. There’s simply no reason for 78 methods in a basic List class.
The problem with Harold’s argument is that he is using the wrong goodness metric. His metric is interface complexity when it ought to be overall cost.
Cost is what counts. If adding methods (or making any change, for that matter) reduces the overall cost of getting legitimate work done, it’s the right thing to do. That’s all there is to it.
Yes, adding methods to a library increases complexity and thus increases the cost of understanding and using the library. Adding methods to a library means asking users to make a small investment of their time and mental capacity in exchange for the promise of a later return – clarity and code savings. The duty of a library designer, then, is to make sure that this return is worthwhile, that the additions are useful enough and used frequently enough to pay for themselves.
In a later post, Harold implicitly acknowledges the does-it-pay-for-itself test when he lists some methods from Ruby’s Array class that he thinks are unjustified. He writes:
Do you really need any of [these methods] getting in your way? Possibly you need one or two of these methods; but how often, and how many?
The thing is, I use many of the methods he lists. Further, the ones I don’t use don’t seem to get in my way. In sum, those methods have paid me back far more than I have invested in them. Given this, why shouldn’t they be in the Array class?
I’m not saying that “humane” interfaces are better. Rather, I’m saying that focusing on “humane” vs. “minimal” is missing the forest for the trees.
Cost is what matters, so why shouldn’t it be the focus? Who cares if that focus leads us to a “humane” interface one time and a “minimal” interface another? With cost as our guide, we’ll always arrive at a good interface.
Posted in programming
Tags cost, humane, interfaces, minimal, programming
4 comments
no trackbacks
Posted by Tom Moertel Tue, 30 Aug 2005 18:56:00 GMT
I came across Tim Bray’s thoughts on Ruby via the ever-delightful Lambda the Ultimate and found the following bit fascinating:
I’ve had access to languages with closures and continuations and suchlike constructs for years and years, and I’ve never ever written one. While I’m impressed by how natural this stuff is in Ruby, I’m still unconvinced that these are a necessary part of the professional programmer’s arsenal. [Emphasis mine.]
While Tim Bray may be unconvinced, I am a true believer.
Read more...Posted in programming, functional programming, programming languages, ruby
Tags closures, programming, ruby
12 comments
1 trackback
readers
