Tom Moertel's Blog

Dispel the magic by defining the semantics

Posted by Tom Moertel Thu, 23 Jul 2009 19:50:00 GMT

Recently there has been a lot of talk about “magic” in software. Most of the people doing the talking, however, seem to be talking past one another, primarily because they do not share a common understanding of what “magic” means. The few definitions of the term I have seen seem to miss something essential, so I will provide the definition that I think makes the most sense:

In a software system, magic is any behavior whose semantics are poorly defined and unduly expensive to figure out.

Some notes:

1. The “unduly expensive” part means that people with different background knowledge are going to find different things magical. If you use certain techniques every day, you will probably find behaviors that make use of those techniques easier to figure out and thus less magical than other programmers might.
2. One way, then, to make things less magical is to exhort programmers to get more knowledge. A more practical approach, however, appears in the next point.
3. Most “magic” can be de-magicked simply by defining its semantics.

So when I complain about magic in a software system, I am complaining about code whose behavior is not readily discernible. When I did a lot of Rails programming, for example, I always gnashed my teeth when I encountered a function in the Rails API that took a string but did not make clear what that string was supposed to represent. Was it text? Was it HTML? There was only one way to find out: trace through layers of Rails code to figure out what the framework actually did with the string. That is unduly expensive, so I considered such functions to be magic – annoying, waste-my-time magic.

I do a lot more Python programming these days, and while I encounter less magic, I am mystified by the part of Python culture that turns its back on code that is perceived as being overly clever or, to use the popular phrase, not explicit. What is wrong with cleverness, as long as the result is clearly understood? Cleverness, by itself, is not magic. For real magic, you need fuzzy semantics, too.

That is why, when I hear that code is “magical” or “too clever,” I think “poorly defined.” If you define and document the semantics of such code, you dispel its magic. And if you cannot define the semantics, then the code is magical and too clever, and probably ought to be rewritten.

Thus the test for whether something is magical is the clarity of its semantics. Code having clear semantics is not magical. Code having unfathomable semantics is.

Posted in programming
Tags clarity, cleverness, definitions, magic, programming, semantics
10 comments
no trackbacks
 

The best-kept secret in programming conferences, especially in a down economy

Posted by Tom Moertel Fri, 22 May 2009 05:59:00 GMT

I know, the economy sucks, and everything is expensive these days. It’s even worse for you, a polyglot programmer with a serious programming-language obsession. You prowl Proggit, lounge at LtU, and occasionally step on over to Stack Overflow. But it’s just not enough. You need more. You need to hang out in meatspace with other fascinating programmers, diving into modern object systems, getting mechanical with crazy VMs, hacking on code like the wild code-hacking beast that you are.

Sure, it’s a nice dream and all, but how are you going to make it happen? And even if you could in theory make it happen, how could you afford to do it now, in this down economy?

Well, my friend, let me share a secret: You can make it happen. And you can afford it. Here’s how: Just be at the 10th Anniversary Yet Another Perl Conference. It’s day upon day upon day of jam-packed programming-language goodness of all sorts, not “just” Perl – and this year it’s the one conference you can afford.

Seriously, I did a little price-checking, and YAPC is about the most underpriced programming-fest on the planet:

Wait, you’re not into Perl? No problem. The Perl community has always embraced diversity, and there’s a lot more than just Perl at YAPC. Check out the tag cloud for talks and you’ll see what I’m saying. At YAPC, the good stuff comes in enormous buckets, plenty for programming aficionados of all stripes. Here’s a taste:

• There’s the Parrot Virtual Machine Workshop. That’s right, YAPC comes front-loaded with a thunderous, 2-day, under-the-hood hackfest, all devoted to a modern VM – Parrot – that’s optimized for your favorite dynamic languages.
• You’re serious about keeping track of your code, right? Well, YAPC’s got talks about Git, too.
• Into objects? Then consider a barrel of talks about the Moose object system, which builds upon great ideas from Perl 6, CLOS (of LISP fame), Smalltalk, Java, BETA, OCaml, and Ruby – and sports roles, delegation, and a meta-object protocol.
• Are you into testing? Well, Perl culture is positively infected with testing. At YAPC|10, there are half a dozen talks about it. (Also: find out why you ought to be harnessing the power of TAP, even if you never program in Perl.)
• And, of course, there’s a little Haskell love, too: What Haskell did to my brain.

See, YAPC is for you.

Am I trying to persuade you to join us at YAPC? Yes. But I’m only doing it because I care about you. YAPC is a fascinating conference, packed with hackers from around the world, all eager to share interesting things, things many you would find delightful, if only you knew about them. So I’m letting you know about them, right now, so you don’t miss out.

Do yourself a favor. If you can figure out how to get your brain to Pittsburgh in the 4th week of June 2009 – yes, only 4 weeks away – then by all means register now for YAPC|10. It’s a great conference at a great price, and it’s something no discriminating hacker ought to be denied.

I hope to see you at YAPC|10.

Posted in perl
Tags conferences, haskell, moose, parrot, perl, pittsburgh, programming, tap, yapc
14 comments
no trackbacks
 

That looks about right

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:

• l = ls –CF
• m = less

Posted in interesting stuff
Tags life, memes, programming
1 comment
no trackbacks
 

Cost-reducing interfaces should be the focus

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
 

Closures and the professional programmer

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.

Posted in programming, functional programming, programming languages, ruby
Tags closures, programming, ruby
12 comments
1 trackback