I'm often asked about my surname. More often, I'm not asked, but I can sense the confusion it creates.
Some people -- always women, interestingly -- commend me for it. Other folks are apparently less sure, or even incredulous, insisting on calling me by my "maiden name" ("bachelor name"?) even if they've known me only since The Switch.
I'll admit, I sometimes don't quite believe it myself. More than once these seven years, I've accidentally called myself "Mark Van Haren." I suspect it's that I, just like the curious people I meet, never expected my name to change. Most (American) girls assume -- or used to? -- that they'll one day change their name. But for me, Van Haren was never my "maiden name", just my name.
Of course, that thinking changed. Having only my wife change her name didn't feel gender-equitable to us. And as a hua-qiao, my wife didn't want to lose the Chinese-ness of her surname. What to do?
Option 1: Both remain unchanged. But we'd lack a common family name. Would it even feel like we're married? What name would the kids take?
Option 2: Both adopt some brand new name. But what? And that probably doesn't solve the Chinese-ness issue. We'd probably both feel we'd lost something.
In the end, hyphenation seemed the only viable road. In theory, I was good with this. In practice, "Wong-VanHaren" has always been a little difficult to get excited about. "Wong" breaks up the (original) flow of my name, like a middle name I suddenly insisted on always using. And the new moniker got off to a rocky start when, at our wedding, we were pronounced "the new Mr. and Mrs. Wong-VanHaren", and our unwitting assembly of dear friends and family... wait for it... they laughed. Ouch.
Maybe what's weird(est) about it for most people is that the two names are so different. It ain't Smith-Jones or Chang-Wong. I'm a haole guy with a merely hapa-haole name, and I suppose it just looks funny on me, like a kente cloth on an Inuit.
Anyway, just deal with it. :-) I do. Oh, and please try to get it right. It's "Wong-VanHaren," with three -- count 'em, 3 -- uppercase letters and not a single space in the mix.
Thursday, February 15, 2007
Wednesday, February 14, 2007
DMD Tremens
Sometimes, working toward deadlines is pretty rough. I guess that's why I hate deadlines, because I take them seriously, no matter how ill-considered they may be.
After 11 days of reduced sleep -- started at 5 hours/night; ended at 2 -- and anomalously high caffeine consumption, I kinda broke. About a dozen hours after my last Diet Mtn Dew, my autonomic systems went haywire.
First, I got the shakes. Wow. I mean, what? It was weird. Terrible headache, shaking, weakness, fever, muscle soreness, copious sweating, the works. Did I mention terrible headaches? and shaking? and copious sweating?
At the time, I figured it was simple fatigue combined with mild illness (flu?). And maybe it was. But, my wife suggested it may have been a mental disorder. Really. She meant caffeine withdrawal.
There are a couple of serious lessons to be learned from this. First, better-considered deadlines; no matter how much urgency we may feel, I'm baking more time into each milestone, just to be sure. Second, sufficient sleep is mandatory. Third, caffeine is a drug.
After 11 days of reduced sleep -- started at 5 hours/night; ended at 2 -- and anomalously high caffeine consumption, I kinda broke. About a dozen hours after my last Diet Mtn Dew, my autonomic systems went haywire.
First, I got the shakes. Wow. I mean, what? It was weird. Terrible headache, shaking, weakness, fever, muscle soreness, copious sweating, the works. Did I mention terrible headaches? and shaking? and copious sweating?
At the time, I figured it was simple fatigue combined with mild illness (flu?). And maybe it was. But, my wife suggested it may have been a mental disorder. Really. She meant caffeine withdrawal.
There are a couple of serious lessons to be learned from this. First, better-considered deadlines; no matter how much urgency we may feel, I'm baking more time into each milestone, just to be sure. Second, sufficient sleep is mandatory. Third, caffeine is a drug.
Monday, February 12, 2007
Prototipo, Rubí
My English is native. My Spanish isn't, and is limited to certain usage situs. So no surprise, I express myself better in English.
As a programmer, Ruby is my English, JavaScript my Spanish. No surprise: I like to write JavaScript in a Rubyish way. It matches better how I want to think and makes things just flow better. Prototype.js makes this possible.
There are three particular Rubyisms that prototype.js gives me access to in JavaScript: [1] class-based OO, [2] modules as mixins, and in particular [3] the mixin Enumerable, which helps me to think functionally.
JavaScript is really prototype-based OO -- clone an existing object and extend it to create a new type. With protoype.js's Class.create(), I can pretend I'm just defining a class, whose #initialize method gets called upon instantiation.
Since I now have (something functionally equivalent to) classes, I can use Object.extend() to mix in modules.
Now, sadly, JavaScript doesn't encourage functional programming like Ruby does -- with its implicit returns and its blocks as method arguments. Nothing we can do about JavaScript's lack there -- we have to return explicitly, and we have to pass full-on methods, which if on some object, must be #bind-ed so the closure has the proper value for "this".
However, prototype.js still makes functional-style programming fun, giving us an Enumerable mixin rivaling that of Ruby's.
So prototype.js may not take us all the way there, but by making JavaScript a lot more Rubyish, it allows me to continue to program in the same style -- and think in the same way --, regardless of the syntax.
As a programmer, Ruby is my English, JavaScript my Spanish. No surprise: I like to write JavaScript in a Rubyish way. It matches better how I want to think and makes things just flow better. Prototype.js makes this possible.
There are three particular Rubyisms that prototype.js gives me access to in JavaScript: [1] class-based OO, [2] modules as mixins, and in particular [3] the mixin Enumerable, which helps me to think functionally.
JavaScript is really prototype-based OO -- clone an existing object and extend it to create a new type. With protoype.js's Class.create(), I can pretend I'm just defining a class, whose #initialize method gets called upon instantiation.
Since I now have (something functionally equivalent to) classes, I can use Object.extend() to mix in modules.
Now, sadly, JavaScript doesn't encourage functional programming like Ruby does -- with its implicit returns and its blocks as method arguments. Nothing we can do about JavaScript's lack there -- we have to return explicitly, and we have to pass full-on methods, which if on some object, must be #bind-ed so the closure has the proper value for "this".
However, prototype.js still makes functional-style programming fun, giving us an Enumerable mixin rivaling that of Ruby's.
So prototype.js may not take us all the way there, but by making JavaScript a lot more Rubyish, it allows me to continue to program in the same style -- and think in the same way --, regardless of the syntax.
Many Happy Returns
Ruby has implicit returns -- every method responds with something, whether you need it to or not.
For those unaccustomed to this, it may feel wrong. "If the result is meaningful, have the code tell me it is!" ...I disagree. If you're thinking this way, you're thinking procedurally.
Instead, think functionally. Always make your methods return something useful. If you can think of nothing more meaningful to return, return self. Method chaining is your friend.
For those unaccustomed to this, it may feel wrong. "If the result is meaningful, have the code tell me it is!" ...I disagree. If you're thinking this way, you're thinking procedurally.
Instead, think functionally. Always make your methods return something useful. If you can think of nothing more meaningful to return, return self. Method chaining is your friend.
Making Ruby Functional
I'm no expert at functional programming. I did a bit of LISP in college. Like you, I thought it was ugly. But I like FP anyway.
FP is supposed to be important because of higher-order functions and lazy evaluation, as they encourage modularity. And hell, who can argue with modularity?
But in Ruby, our most important tool for modularity is, um, modules (classes, objects). We're not fully FP. At a high level, we modularize using objects, and FP comes in at a tighter granularity, where its benefits are more limited -- but still important.
In Ruby's mixed environment, we can make our code simpler by using the higher order functional abstractions provided us (by Enumerable). There are as many "map"s in my code as "if"s. Make your own higher-order functions, even curried ones, if you like (though I rarely find the need).
We also make our code more expressive of intent. In FP, functions lack side effects. In other words, by asking a question, you want just the answer, not to change the state of the world in the process. Well, if what I want is an answer and not to be changing the state of the world, then expressing my intention using an FP style looks right. I'm declaring what I want. I see my code a week later and I know what I was doing. It's just laid out right: here's the goal, here's the starting point, and here are the steps that take me from the latter to the former.
Ruby makes this easy.
FP is supposed to be important because of higher-order functions and lazy evaluation, as they encourage modularity. And hell, who can argue with modularity?
But in Ruby, our most important tool for modularity is, um, modules (classes, objects). We're not fully FP. At a high level, we modularize using objects, and FP comes in at a tighter granularity, where its benefits are more limited -- but still important.
In Ruby's mixed environment, we can make our code simpler by using the higher order functional abstractions provided us (by Enumerable). There are as many "map"s in my code as "if"s. Make your own higher-order functions, even curried ones, if you like (though I rarely find the need).
We also make our code more expressive of intent. In FP, functions lack side effects. In other words, by asking a question, you want just the answer, not to change the state of the world in the process. Well, if what I want is an answer and not to be changing the state of the world, then expressing my intention using an FP style looks right. I'm declaring what I want. I see my code a week later and I know what I was doing. It's just laid out right: here's the goal, here's the starting point, and here are the steps that take me from the latter to the former.
%> my_result =
starting_point.munged_once.and_again
Ruby makes this easy.
Subscribe to:
Posts (Atom)
