begging the question, language composition and orthogonality

Not too long ago, one of my friends used the phrase "begs the question" in the colloquial sense of "what we're talking about suggests that this other issue should be addressed".

And I've come to the point in my life where this doesn't bother me anymore, despite the fact that I know the technical rhetorical sense of "begging the question" -- an argument presupposing what it's trying to prove, often implicitly. I prove that unicorns exist thus: all those magical one-horned horses out there are unicorns. I prove that there's an objectively extant material world by kicking a rock and hurting my foot.

This post, of course, begs the question: will I be secure enough as an armchair philosopher to start using the phrase in the vernacular sense? I'm torn: there are few things I like less in the world than prescriptive grammar, but few things I like quite as much as precise, expressive expression.

gmaps and quicksilver

So I've started work on the gmaps mashup for runners I'd mentioned last time... the Google Maps API is very straightforward, easy to understand. And getting a simple example working is quick. I'm not surprised, but it turns out to be very pleasant. Everything you wanted to know about gmaps is right there, have at!

Also: my ATLhack compatriot Erik introduced me to this really nice interface tweak for Mac OS X -- quicksilver. It lets you do a lot less mousing on the Mac, which is a pretty welcome change -- a quick key-tap, and it pops up a window where you type the first few letters of something, say an application or a folder or whatever, and it searches out what you probably mean! It seems like it's more efficient than reaching for the mouse, and for right now I've taken everything off my Dock to see if quicksilver is a viable replacement. Thanks, Erik!

Run and jump on that gmaps bandwagon!

All the cool kids are doing Google Maps mashups, and it just occurred to me, while chatting with Graham: we could do one that picks a meeting place for runners to meet. Say given starting points for n runners, it finds some convenient corner for everybody to get together. For the case of two people (say, me and Graham), it might be just the midpoint on the best path between our houses -- but what about a big running club? And what if some runners are stronger than other? Clearly, some weighting and scaling is in order. And you could put in how fast you expect to run and when you want to get there, and it could tell you when you should leave, adjusted for traffic!

Maybe not as immediately useful as Gmaps Pedometer, but it'd be fun to put together. The API looks kinda neat, and I should learn this newfangled Web 2.0-AJAX-web-services schlock one of these days...

Mapping and reducing is like popping and locking for programmers

If you don't read Lambda the Ultimate, that's quite alright. But fairly often over there, you find a link to Why Functional Programming Matters, by John Hughes. Recently, I decided to sit down and actually read it. It's mind-expanding!

Previously, I'd thought about mapping functions onto lists as an operational thing, a set of steps to complete, but that's not the cleanest way to think about it. Mapping is actually a special case of "reduce", an operation where you just go through and replace the all the "cons" functions in a list expression with something else, then evaluate the expression again. "map" functions have a cons in the function they're reducing with, so the end result is another list.

For example: you might write, in lisp: "(mapcar #'(lambda(x) (* x 2)) '(1 2 3 4))", yielding (2 4 6 8).. and you might think of that procedurally... but a map is just a reduce where "cons composed with the mapped function" replaces every "cons". Append can be written similarly; it's all essentially just replacement, function composition and evaluation. The paper also goes into beautiful issues like lazy evaluation (the author says that if he wrote the paper now, the examples would be in Haskell!) and continues to do some lovely examples, some numerical and one very close to our heart: a bot that plays tic-tac-toe, optimally, with pruned game trees.

Years ago, Kurt Eiselt told me that the future of computing was going to be functional languages on very-parallel hardware; functional languages, at least in principle, make synchronization easier by limiting or removing-altogether side effects. (although reconciling this idea with stateful, event-driven end-user applications is another issue!) To an extent, it looks like he was right, and the future is here! MapReduce is the method Google is using to crunch super-giant datasets with enormously parallel clusters. It's not just for functional languages, of course, but the idea is there.

Possibly interesting, but almost definitely not useful!

- My aunt, years ago, had a Newton eMate 300, and I recently found a Newton PDA while cleaning out the space behind an A/C unit -- in any case, I've had this weird fascination with Newtons for years. Now, you can relive the Newton Magic that you probably never experienced in the first place, under emulation! The Einstein Platform is a Newton emulator that works pretty well -- and you can find Newton ROM images here. It's kinda interesting. (Although I got stuck in fullscreen mode once, careful!)

- Self. It's been ported to Linux. It's one of those languages that one feels like one should learn more about. It has interesting family relationships with SmallTalk and Dylan and JavaScript...

- Thinking Meat celebrates the holidays. I just found this blog, but over at the Thinking Meat Project, she has a lovely article about taking part in the culture around the holidays and coming to terms with the cognitive dissonance from enjoying good Bach choral music while feeling like one shouldn't be participating in religious rites, for consistency's sake. It can hard to balance these things, particularly soon after giving up a faith.