Dumpster diving been good lately

I.

Jill and I have not really been known to back a van up to a dumpster on purpose, but yesterday her (extremely nice) mom called up with a neat find: two perfectly good leather chairs waiting for the trashman behind the neighbor's house. And it's true, they were a little scuffed, but perfectly good! The neighbor came out and gave us the story; apparently they couldn't find a spot for them, so they've just been sitting in a garage for two years. Soon we'll give them a little polish, and they'll be looking distinguished in our new place =)

II.

Two off-white keyboards were jutting out of the trash can at work today, both missing left Ctrl. Now one is missing both, the other is complete (and getting healthy under a sheet of Lysol in the bathroom) and I got me a keyboard for more comfortable coding on the Eee.

Ten days left! / Lua tricks / Learning Clojure

Ten days left.

Freaky stuff, no? Can't wait to see everyone in Chicago. =)


Lua's rather easy on the eyes

Ever encounter this particular kind of coding friction?

Rect* r = new_rectangle(25, 20, 30, oh argh what order were all these in again

Window* win = make_window(this, that, NULL, the_other, NULL, NULL, 42, false, 0); // wait what are any of these?

Imagine trying to read that code--you're wearin' out your Alt+Tab switching between your editor and the reference. What are any of those arguments? Fortunately, Lua gives you a neat way to avoid this syndrome, and make your function calls all self-documenting and explicit:

-- Let's say we've got rectangles...
rectangle = {}

-- Here's a constructor. We need coordinates, and a width and height...
setmetatable(rectangle, {__call =
function (self, args)
local r = {}
r.x = args.x or 0 -- default values if you want 'em
r.y = args.y or 0
r.w = args.w or 50
r.h = args.h or 50
return r
end})

Here's the trick: in Lua, if you list function call arguments like foo{...} instead of foo(...), Lua packages it all up as a table and passes it to the function as the only argument. Sweet, sweet syntax sugar. Also, here we hook our constructing function up to rectangle's __call metamethod, so we can just call rectangle itself as our constructor.

Now we can make rectangles like this:

r = rectangle{x=10, y=10, h=20, w=30}

Ahh...beautifully readable. And rearrangeable--since it's a table, not a parameter list, the arguments don't have to be in any particular order!


Clojure is a foreboding wood.

I have been playing with a new language called Clojure, which is a Lisp dialect on the Java Virtual Machine. ("Get it? 'Closure' with a J! Haw!") Clojure's got all kinds of cool functional language goodness, backed by the immense cavalry of the JDK, but trying to learn it has been like wandering lost through a dense wood.

The problem? The reference on the Clojure site isn't organized too well. It's not presented in a helpful order for learning, plus it throws too much info at you at once. Plus there seems to be no particular blessed tutorial. Plus Clojure is complicated. So as I decipher it, I'm thinking about blogging what I figure out, and hopefully leaving a nice field guide as I go...

One immediate stumbling block is the bizarre evaluation rules. Here's what I wish they would have said right at the start: You got symbols, vars, and values. Symbols are just names. Vars are named by symbols, and can have values. Vars are the intermediary between a symbol and a value, like a box or a reference kind of.

(def symbol value) does what you'd expect, creating a var with that value and that name, but you can also say (def symbol) just to create and name an unbound var. Sorta like saying #define SOMETHING in C without giving it a value.

A symbol, by itself, evaluates to whatever value its var has got. If a symbol's bound to a var, you can get that var by saying (var symbol), or equivalently, #'symbol.

(Note: This could be wrong or misleading. Just think of it as a mental snapshot of a fool.)