blog.izs.me

Software Personality

Mon, 06 Feb 2012 14:02:22 -0800

Last semester, Chase and I took a business communication class in which we dissected the PR crisis that resulted from someone trashing an Airbnb user’s home. At the time, it seemed very abstract and unlikely — crises never happen to those who prepare! Well, one just happened to us.

There’s an important lesson here. Don’t be too afraid to show a little personality in your products. Let your team’s humanity show. Keep the character in mind, and be true to it.

Think, “If this product were a person, what kind of person it be like? How would it dress? What would it feel? What would it say to you when you’re having a bad day, or when you come to it with good news that you’re excited to tell?”

In developing npm, this has always been chief in my thoughts. Very early on, I started imagining npm as a friendly helper and developer cheering-section. It just wants you to succeed so much. It loves your program like a parent, and is proud of the day when it can get all its dependencies taken care of, and leave your warm embrace to go out into the harsh world of deployment. It wants to know you’re prepared, that you’ve run all your tests. It will help you find friends and allies, try to warn you which ones to steer clear of. This can be a little smothering at times, but when your program is out there in the wild, maybe you’ll require() a little something, and there it’ll be, because of how much npm cared for it, and it’ll think warmly of the place it grew up, back in the $HOME directory on your laptop.

This mental image is what inspired the “npm loves you” meme. (It’s right in the faq.)

On the other hand, Node.js has a slightly different personality. It doesn’t shield you from harsh realities. It’ll go with you out into the wild, and handle all the incoming requests with you. It’ll be by your side through thick and thin, and follow your commands to the bitter end. It won’t go out of its way to be a jerk, but if there’s ever a choice between being fast and being nice, you know what it’s going to pick. If something needs to break between versions, well, then that’s what has to happen. It knows you’re going to be able to deal with it.

This, in my opinion, is the chief conceptual difference between a “platform” and a “tool”. Of course, to some extent, every platform is a tool for interacting with the system, but you really want a different personality from your platform than you do from a tool. A tool gets you there, and then is left behind; a platform is a part of the show from start to finish.

Bryan Cantrill has mentioned to me that every software project carries the esthetic of its creator. I think there’s a lot of truth to this. But, just as children don’t necessarily grow up into copies of their parents, software’s personality doesn’t necessarily match the personality of its creator. In many ways, Ryan is much nicer than I am, but npm is certainly more friendly than Node.

This phenomenon is uniquely challenging for companies that want to appear “grown up” and be taken seriously. The line between “grown up” and “robotic” is so subtle. Certainly, cursing at your users in a test message is a very risky way to breathe life into a product, but nevertheless, I find myself unsurprised by the reaction to the fetchnotes flub.

I really like the view from where I live.

Sat, 04 Feb 2012 23:33:55 -0800

I really like the view from where I live.

hamburglr: First, go grab some headphones. The best ones you’ve...

Thu, 05 Jan 2012 09:51:12 -0800

hamburglr:

First, go grab some headphones. The best ones you’ve got. If the best ones you’ve got are these suckers (or something similar), you should really go buy new ones, but use the best you’ve got for right now.

Take a break from whatever you’re doing for 2 minutes and listen, but just listen to the whole thing, even if you have to multi-task.

Headphones on? Ok. Good.

Now, press play.

“Upular (3D Audio Version)” - Pogo

aredridel: Or, you know, we could go own our own...

Mon, 02 Jan 2012 16:46:08 -0800

aredridel:

Or, you know, we could go own our own infrastructure. Start your own blog, folks. Find a local company who hosts sites or get your own virtual server. Get help setting it up or learn how yourself. And then there are no limits save the actual resources you’re using.

You’ll learn a lot. You’ll own your space, not just lease it for the price of your privacy to another company.

samueloser:

Remember back when Tumblr didn’t have all these restrictions? It was great! Well since then, they’ve added new limits to the things we can do.

Reblog this if you want the Ask Limit, the Post Limit, and all the other limits that Tumblr has been adding to be repealed. If this gets enough notes, hopefully we’ll be able to persuade them to repeal the limits, or at least lessen the restrictions!

Reblog and Reblog and Reblog, and get your friends to Reblog as much as possible!

Xmas Traditions

Thu, 29 Dec 2011 18:45:00 -0800

As an american, especially one descended from european catholics, there is no annual event as steeped in tradition and ritual as Christmas. It seems at times that failing to maintain our traditions would be an affront to our ancestry, and a crime to our descendents.

Tradition is a funny thing. It’s a social fiction. It’s something that we as humans decide we’re going to do. On the one hand, traditions can give comfort and stability in the midst of a shifting world. On the other hand, “because we’ve always done it this way” is hardly an optimal heuristic for social behavior (or even good evidence for having in fact always done it that way).

Back when our software was being written, when our world changed less quickly, and tribal unity was a life or death issue, it probably made a lot of sense to value stability over most other aspects of life. However, in the modern world, the absurdity of this pattern seems so painfully clear sometimes.

Christmas just a few generations ago would have been unrecognizable to us today. The “Santa Claus” character as we know him today, with the reindeer and flying and chimneys and north pole, was invented less than 200 years ago, and only became an overweight bearded red-clad man in the 1920s. Our “classic” christmas songs were almost all written in the 1940s and 1950s.

A lot of our “time-honored” christmas traditions were invented while my parents were kids.

The christmas traditions that I remember were waking up early, opening presents, and then spending the day in pyjamas playing with new toys. No travelling, no extended family, no huge dinner. We didn’t have any xmas eve celebration (probably because my parents did a lot of their shopping and preparation the night before.) The “christmas dinner” was usually delivery chinese. Normal Rockwell would’ve been scandalized.

The extravagance of our christmas presents varied quite a lot. My dad ran his own business, and along with that came a lot of ups and downs. When we didn’t have a lot of money, my parents put a lot of creativity into it.

One year, our gifts consisted mainly of coupons to be redeemed for outings or favors at some later date. We were young enough to be excited about that. Those coupons were made at home, printed to look official and then decorated with magic marker (our printer at the time was a black and white dot-matrix.)

The most awesome part of our xmas tradition came out of a creative solution to a last-minute problem. It was a good year, and my parents had bought me and my sister new bicycles. But, they didn’t see any way to bring them into the living room and wrap them in such a way that we wouldn’t know right away what they were.

They had the innovative idea to put the bikes outside in the shed, but rather than just tell us to go out and get them, my mom designed a treasure hunt that my sister and I would have to work together to solve. The first clue was on a card buried in the middle of the tree. That led to another clue, which led to another, and so on. Each one was a little puzzle that had to be solved, and it was all allegedly from “Santa”. So, when we asked my mom for help, she just threw up her hands, and said, “Hey, I didn’t help him make this thing. Call up the north pole if you can’t figure it out.” (We were old enough at the time to know she was putting us on, but she can be very stubborn. Her sense of humor is so dry, you never really know if she’s joking, or has had some break with reality and believes what she’s saying.)

Every year, whatever big present we got, it was at the end of a similar treasure hunt. It kept us out of our parents hair, that’s for sure. A chemistry set in the trunk of the car. A Nintendo and a few games (that year, my parents were eager for us to finish so that they could “help” play with it.) A “treasure box” filled with about $25 in quarters and dollar bills and some plastic pirate toys (not one of the fat years, but still fun.) One year in highschool we had to drive across town to pick up one of the clues. Once one of them was hidden in a file on a computer. (And, just to throw us off, another clue that year was in a piece of paper literally inside a different computer, so we had the thing mostly taken apart to individual pieces before reading the clue more carefully.)

Looking back, I attribute a lot of my relationship with my sister to the fact that my mother put so much time and thought into getting us to work together and experience joy and frustration together.

It wasn’t until recently that I learned that all this was a huge departure from the traditions in the Schlueter family, which previously had involved trekking back to my dad’s home town (in South Dakota of all bloody places!) Christmas eve gift exchange, followed by midnight mass, sleep, followed by another church service Christmas morning, and then a huge elaborate dinner. More Jesus than Santa.

We did that one year. I remember it sucking, and wishing that we could just do a “normal” christmas instead of all this work and church stuff, and driving across the country. The food was ok, but I didn’t see why I had to put on dress pants and uncomfortable shoes to eat with my cousins.

When I heard about other kids doing other things, visiting family and such, I thought, “Oh, that’s kind of weird, I’m glad I don’t have to do that.” I didn’t feel uncomfortably different for our “easy” traditions; they were great. Low-stress, low-expectation, high-fun.

I remember sensing at the time that my mom didn’t have as much fun with it as I did, and figured it was because she had to do a bunch of work. I didn’t realize at the time, it wasn’t just the work, it was the sense of obligation she felt that made the work seem so awful sometimes. She’d grown up disliking christmas, and felt a tremendous pressure to make it magical for her kids. She succeeded—impressively—but probably went well beyond the realm of diminishing returns. She could have done a bit less, been just as successful in making a great experience for her kids, and enjoyed the process more.

I’m not a father today, but I am an adult. And I find myself with a family that’s quite a lot bigger and more spread out than just the 4 of us. It’s easier to appreciate what my parents were giving up by staying home, and how hard that decision probably was. I feel that pressure, to do this and that, to be here and go there, and get this for these, and that for those, to drive around from town to town visiting everyone and being at every party.

It’s fun, sometimes. There are people that I love, and don’t see often enough, and this is a great excuse to make that happen. There’s also a lot of stress and headaches involved, and that can make everyone grumpy and annoyed. We feel an obligation to this thing called “Tradition” that feels so real and solid, and sometimes end up spending our time doing things no one likes for reasons no one understands, often for the alleged benefit of “passing on” traditions to children who will accept it for whatever it is, no matter what we end up doing.

The moral of the story is this: you don’t owe the past shit. If you want your kids to enjoy christmas, and have happy memories, then do what makes you happy, and focus on having fun with them today, in the here and now. The universe will forgive you if you give people presents in January or November, or if your bonding event is movies and chinese takeout in pj’s rather than church and ham in slacks.

Tradition is a story you can rewrite at any time, so write one you can enjoy.

Browser : Operating System

Tue, 29 Nov 2011 09:46:00 -0800

Fairly early in my career as a programmer, I switched from the C and C++ path over to front-end web development. It was fun, in-demand, and provided a way to scratch my artistic and programming itches at the same time.

I spent a lot of that time wrestling with web browsers.

These days, I write most of my JavaScript for node, and run my programs on servers. I’ve found that wrestling with operating system differences is very similar to web browsers.

(Disclaimer: this is a joke. Please don’t email me.)

IE : Windows

Full of Microsoftisms. Most things mostly work, except that sometimes they don’t, and when they do, it’s usually in a completely foreign and strange way. So different that many people either don’t support it, or don’t support anything else.

Firefox : Linux

Mostly works, but always awkward. A perpetually broken mish-mash of components that often weren’t really intended to be used together. No two are alike, and nothing ever looks exactly right.

Shrouded in a religious belief that it is fixing the worlds problems. Any criticism is viewed as heresy (unless it comes with a patch).

WebKit/Safari/Chrome : Darwin/BSD

Very nice, very polished. Would probably die if not for the fact that a huge corporation decided to back it (since we already have a public option with Linux/Firefox). Mostly open source, but if you have to actually do things, you’ll inevitably be forced into the “blessed” APIs, which are not standard.

Opera : SunOS

All 12 of its users loudly agree it is superior in every way, and they have graphs to prove it.

badlipreading: “HERMAN CAIN” — A BLR Soundbite Only slightly...

Thu, 17 Nov 2011 23:29:38 -0800

badlipreading:

“HERMAN CAIN” — A BLR Soundbite

Only slightly more crazy than the actual Herman Cain.

Experts, Idiots, and Taste

Thu, 10 Nov 2011 10:15:00 -0800

My nerd rage on the topic of Fibers, co-routines, and compiled-to-js languages in node.js comes from seeing a non-problem solved in a way that makes it worse.

There are two really dangerous rationalizations in software design:

“We need to make it easier for newcomers.”
“Only experts will use this, anyway.”

Tower of Babel of Cards

They’re dangerous because each seems to imply that the other can be disregarded. The worst approach is to vacillate between them: “We need to make (async IO, object cleanup, database queries, whatever) easier for new users, so we’ll add this magic that experts will use to make intuitive APIs.”

It’s a vicious spiral. You can justify adding complexity, because “this is for experts only”, and also exposing the functionality in an obscured way in the name of making it “intuitive” for newcomers. The result is inevitably a towering house of cards. On a somewhat visceral level, I get this gut reaction to a “handing down from the mountain” mentality that is only harmful in the long run for everyone.

A better goal is to make an API such that when an expert uses it expertly, a newcomer can still understand it thoroughly. It requires an API (and more importantly, a culture) that limits experts, and educates newcomers. I don’t know the best way to approach problems to get there, but I’ve found pretty good results from thinking, “I’m probably going to mess this up the next time I touch it, so I’d better make it really obvious.” I usually fail at it, and end up cursing myself later when I rewrite the damn thing yet again.

Passing around a function that gets called later is not that hard. We’ve been doing that in JavaScript forever. Yes, newcomers to the language, especially if they come from a language without closures and first-class functions, have a little bit of a learning curve to get used to this phenomenon. In my opinion, you do them a disservice by trying to shield them from that.

(Passing around function pointers in C is actually a little bit better in some ways, because you can’t define your functions inline, and all the captured data must be passed around explicitly. This is a bit like using named functions instead of nested closures, which is a common low-complexity approach to the alleged callback problem.)

I’ve been writing JavaScript for a while now, and other languages for a few years before I got into JavaScript. I’m not the most expert at it, but I certainly don’t consider myself a newcomer. In that time, I’ve learned something:

We’re All Idiots

All of us, whether experts or newcomers. Well-meaning idiots, perhaps, but idiots. We all write bugs, all the time. That is the normal state of software. There is no abstraction so perfect that a human won’t fuck it up at the first opportunity. But we can try to be better, simpler, to make it easier for our future idiotic selves to figure out what we were thinking in our cleverly idiotic brains, and chop the problems into smaller pieces so that our future selves can have some clues to find the maddeningly idiotic bugs we stuffed in there.

If your code uses step or async or slide or Q, I can read it, and I see a function getting called and passed some arguments. I can look at how you got that function from a require() statement, pull up that module, and look at its definition. These are lightweight abstractions that are highly penetrable. I’ve suggested in the past that everyone should write their own flow control lib, because it’s the best way to really understand how they work, and it’s not that hard. Once you grasp the basic concepts, reading someone else’s flow control utility is pretty easy.

If your code uses a compiled fibers library, or something that transforms the code, then it’s much harder for me to figure out what the heck is going on. The introspection is gone. The languages change. Stuff happens that isn’t present in the code I’m looking at. This is fundamentally different from a library that just passes functions around.

That means: I won’t use your library if there’s any alternative (including writing the exact same functionality myself). It’s nothing personal. I just would rather spend my time solving necessary problems rather than manufactured ones. I simply don’t believe that you’ve put the same level of thinking into your coro util that TC-39 and the v8 team has put into JavaScript, or that Bert and Ryan and Ben and Igor have put into libuv.

Not everyone is the same, and that’s great!! If you find that Fibers solve a problem for you, and they make the code that you write easier for you to manage and design, then that’s awesome. Use them. Understand them. Drop the illusory dichotomy of “experts” and “newcomers”, and realize that they are both idiots, and both you.

Every choice that isn’t completely boring will alienate someone. Pleasing everyone is a recipe for blandness. That’s why we keep the node-core standard lib super small, and encourage variation and repetition and iteration in userland modules.

Absolutes

If your goal is to please me (and other stodgy “javascript is fine, callbacks aren’t hard” types) with a compiled coroutine library that adds magic to the language, you should realize how horribly unlikely that is. I do actually think that this approach is fundamentally flawed. I’ve played with Marcel’s fibers lib a bit, and it’s about the nicest I’ve seen, but it still adds an unacceptable (for me!) amount of magic to programs.

Programmers tend to think in absolutes, perhaps because computers are such absolute things, or maybe just because absolutes are easier and we’re all idiots. I’ve done it in this post, because I’m as lazy as anyone. Maybe you’re the exception, and you actually are smart enough to use Fibers or Streamline wisely and still know what’s going on when you read the code a year later. If the benefit is greater than the cost, then go for it. It’s your house, you decide whether to wear pants or not.

When we are discussing things like this, it’s important to realize that we’re artists discussing matters of taste. If everyone agreed, then it would mean it wasn’t interesting. Maybe we should be less interested in convincing people of stuff, and more interested in just writing programs that do interesting things.

Mud Rooms, Red Letters, and Real Priorities

Thu, 03 Nov 2011 09:46:28 -0700

Mud Rooms, Red Letters, and Real Priorities:

You can’t “prioritize” a list of 20 tasks any more than you can “uniqueify” 20 objects by “uniqueness,” or “pregnantitze” 20 women by “pregnantness.” Each of those words means something.

Merlin Mann is my hero. Read this post every time you say the word “prioritize”.

Photo

Wed, 26 Oct 2011 10:37:00 -0700

Gone, but not forgotten.

Wed, 05 Oct 2011 17:16:00 -0700

JavaScript is Not Web Assembly

Wed, 14 Sep 2011 14:21:00 -0700

It’s fairly common these days to think of JavaScript as a sort of “assembly language for the web”. After all, it’s the language that is natively supported by web browsers, making it the most widely deployed runtime in history. With Node, we have a very relevant general purpose non-browser stack for doing system programming using this language, so it’s even more important as a language.

Programmers like to improve things and solve problems. This is a healthy instinct, but like so many healthy instincts, it can be subject to runaway feedback loops and lead to pathological behavior.

If you are designing a language, compiling it to JavaScript is a pretty attractive option, for much the same reason that compiling C to machine code is an attractive option: running it in more places.

However, so far, most of the times that I’ve seen someone trot out the “JS = new assembly” horse, it’s not an apt comparison. The reason we write C instead of assembly is that:

Assembly varies wildly between architectures. C is not as variable. So, the compiler can abstract away a lot of that peculiarity, and you only need to worry about it if you’re distributing precompiled binaries.
C offers an order of magnitude more expressiveness.

I’m going to pick on CoffeeScript, because it’s clearly the most popular to-JS language. Jeremy Ashkenas is a great guy, and has shown himself on repeated occasions to be remarkably sane with respect to this issue. Either he hasn’t caught the language-wank crazy, or he hides it really well.

However, either or both of these points apply to every other to-JS language, including but not limited to GWT, paren-js, sibilant, streamline, kaffiene, narrative, et al. That’s not to say that any of these systems are bad, just that the “blah is to JS as C is to Assembly” analogy is wildly wrongheaded.

CoffeeScript programs don’t vary any less across architectures than the JavaScript programs it creates. That is, you don’t compile it to target a given platform. (This is not true of GWT, which can compile different JS files for different browsers, but that’s not the norm in the to-JS world.)
CoffeeScript does not offer an order of magnitude difference in expressiveness. I’m not using “expressiveness” as some fuzzy term to mean “how happy you are expressing yourself in X language”, but the more mathy technical meaning of “how many relevant program tokens are required to do X task.” CoffeeScript may require fewer tokens, sure, but not 10 to 1 fewer.

JavaScript is not the Assembly of the Web. It’s the C of the web. The to-JS languages are lining up to become the C++ of the web.

They offer language features that make some sorts of programs a little bit easier to write, but don’t make an order of magnitude difference in expressive power.
They’re mostly backwards compatible with JavaScript.
You still need to grok the DOM, or node, or whatever other platform your program is interacting with, and that’s probably documented in JavaScript.
They break almost all of the tooling that exists for JavaScript debugging.

Clarification: CoffeeScript does try very hard to compile to JS that runs on all JS platforms. However, it does not optimize for a given platform, or have a specified target when it compiles. The resulting JS is still a high-level general-purpose program, and the pitch, at least, is that it is a better one than you would have written as easily by hand.

"In the universe where everything works the way it common-sensically ought to, everything about the..."

Mon, 05 Sep 2011 10:22:32 -0700

“In the universe where everything works the way it common-sensically ought to, everything about the study of Artificial General Intelligence is driven by the one overwhelming fact of the indescribably huge effects: initial conditions and unfolding patterns whose consequences will resound for as long as causal chains continue out of Earth, until all the stars and galaxies in the night sky have burned down to cold iron, and maybe long afterward, or forever into infinity if the true laws of physics should happen to permit that. To deliberately thrust your mortal brain onto that stage, as it plays out on ancient Earth the first root of life, is an act so far beyond “audacity” as to set the word on fire, an act which can only be excused by the terrifying knowledge that the empty skies offer no higher authority.”

- Eliezer Yudkowsky, Above-Average AI Scientists

New Recruiter Response

Wed, 31 Aug 2011 12:23:31 -0700

I have a new strategy for recruiters. First, a curt one-liner “not interested”. If they press (usually with an “I’ll ping you in 3 months” or something), then they get the longer explanation.

I just search and replace “XYZCorp” with whatever company they’re calling from, and maybe change a line or two based on their response.

Your optimism is delightful. It pains me to step on it, but I wouldn’t feel right doing otherwise.

In 3 months, I’ll have the same answer. The future is never absolutely certain, but this is as certain as any prediction I can make. It’s a Safe Bet.

I am working on Node.js and npm. This is the technology that has already displaced Python and Ruby as the hot new high-level language platform of choice; within 5 or 10 years it’ll join the likes of .NET, Perl, PHP, Java as the go-to platform for enterprise development (ie, “serious business”) and new college grads. But there is so much more work to be done!

XYZCorp has a lot of very interesting technical challenges, I’m sure. But this is the one that I’m most passionate about, and Joyent is the place that has it. npm started out as my personal side project. Node was a dream of mine that is coming true. I’ve invested a lot of time and a lot of love in this technology and in this community.

Going to work there in 3 months, or in 3 years, would be a huge step down in terms of the effectiveness of my effort and the results that I’ll have on the technology world in general. It would be a bit like someone asking you if you’ll be done with your son or daughter in 3 months, and interested in trying out another kid.

When and if I leave Joyent, it will be to do some other work focused on npm and Node.js, probably as part of my own company. The only way that XYZCorp could ever recruit me is if they recruited me to do that.

If I come across any developers that rival or exceed my skills, I’ll almost certainly try to recruit them myself, or get them to work somewhere else on Node so that they can add to this community. As long as I’m not a XYZCorp employee, and “working at XYZCorp” doesn’t imply “working on Node”, it really does not serve my interests to send talent to XYZCorp. There is no referral bonus that XYZCorp could provide me which would change that.

Altruistically, I want what’s best for the Node community, because I feel connected to it. Selfishly, I want to be one of the names that is remembered as part of a major revolution in software development. If you can show that these two goals are better served at XYZCorp than at Joyent, then let’s talk.

"The proper response to the current impracticality of decentralized computing is not to sigh and..."

Mon, 29 Aug 2011 11:34:34 -0700

“The proper response to the current impracticality of decentralized computing is not to sigh and build centralized systems. The proper response is to build the systems to make decentralized computing practical again.”

- Kragen Sitaker (via hack-the-planet)

youranonnews: Use this image in and around BART stations to let...

Mon, 22 Aug 2011 17:10:00 -0700

youranonnews:

Use this image in and around BART stations to let people know about the protest.

It is quite nice to live in a place where even the slightest infraction against free speech is met with absurd overreaction.

Think Again: War

Thu, 18 Aug 2011 13:01:21 -0700

Think Again: War:

Very encouraging article.

If the world feels like a more violent place than it actually is, that’s because there’s more information about wars — not more wars themselves. Once-remote battles and war crimes now regularly make it onto our TV and computer screens, and in more or less real time. Cell-phone cameras have turned citizens into reporters in many war zones. Societal norms about what to make of this information have also changed. As Harvard University psychologist Steven Pinker has noted, “The decline of violent behavior has been paralleled by a decline in attitudes that tolerate or glorify violence,” so that we see today’s atrocities — though mild by historical standards — as “signs of how low our behavior can sink, not of how high our standards have risen.”

New English

Thu, 11 Aug 2011 22:38:00 -0700

shown to be far more ergonomic.
the bottom to top writing direction was
Reviled and ridiculed at first,

it became apparent this was not ideal.
on monitor screens,
Displaying text in streams

all written down from the top.
languages of the ancients were
Developed for paints in hand,

Obvious Answers to Simple Questions

Wed, 20 Jul 2011 14:18:30 -0700

People who live or work with nerds sometimes are annoyed and perplexed by what strikes them as willful, snarky, unhelpful responses to questions.

q: Do you know what time it is?
a: Yes.

q: Ok... What time is it?   (asshole)

or:

q: How are you going to the party Saturday?
a: I'm driving.
q: Yeah, but are you taking the 101 or the 280?    (asshole)

Programming is a deep and complicated field. There are very many layers of abstraction between the user’s intent and the electrons on silicon.

When working on a problem, it’s common to be so immersed in it that everything seems obvious. In fact, until this level of familiarity is achieved, it’s hard to make any progress at all.

However, other parts of the stack may still be very foreign. This is part of why software development is a social activity. There’s simply too much for any one person to hold the entire stack in their head at once.

So, you ask someone a question. A question that seems obvious to them, but isn’t to you, because you’re not immersed in that part of the world.

And the polite and kind thing for them to do is try to answer your question as precisely and accurately as possible, even though it seems obvious to them and isn’t something they’d ever bother asking, because they realize that you don’t live in the same area that they do.

In the ancestral environment, everyone knew most of what everyone else knew. Even if there were specific details that were shared in bits, it was unlikely that someone didn’t even know the rudimentary basics of any particular subject. So, when asked a question, the polite thing for the answerer to do is skip past any details that the asker probably already knows, and try to infer the bits that they don’t.

Most of human social interaction happens in this sort of framework. You probably know I’m driving, and are really asking which specific route I’m taking, or which car, or when I’m leaving. Answering with “I’m driving” is akin to saying, “You’re an idiot who doesn’t know what a car is, but I’m going to step down off my Smart People pedestal, where we Speak Properly, and help educate you, so that you can learn to not be so dumb. Here’s where the key goes…”

It’s not (just) that nerds are fundamentally more persnickety, or detail-oriented, or hyper-literal. Those things may factor into our oddness, or into our choice of careers, but a large part of this social disconnect is that we actively learn to break this evolved habit.

Our culture and craft depend on responding to simple questions with obvious answers, out of respect for the fact that what is obvious to me may not be obvious to you, even though we’re both competent, intelligent, worldly people with nothing of the best intentions.

That’s no excuse for being a dick, of course. Rudeness—especially unintended rudeness—is not the Winful Way. But it’s hard to shift cultures, especially when our friends are also our colleagues, and social interactions often include technical conversations.

Benchmark: Array-ification of arguments

Sun, 17 Jul 2011 19:29:00 -0700

Having really hot paths in your code can be great, but it can also be a little dangerous.

When v8’s Crankshaft landed in the Node.js dev build, it immediately resulted in a significant drop in Node’s “hello world” performance benchmark.

This was alarming. Crankshaft was supposed to be faster, and here it was causing slowdowns.

The cause was tracked down Vyacheslav Egorov (known to many in the Node community as “mraleph”), and had to do with Node’s use of the arguments object in the EventEmitter.prototype.emit function.

Since this function is the hottest code in Node, even a slight decrease in performance is immediately felt. Vyacheslav discussed the commit in a google plus post.

This got me thinking about the best ways to convert the arguments object, or part of it, to a standard JavaScript Array. I pulled out the node benchmarking thing I wrote, and wrote up two tests

Disclaimers

This advice is only relevant in the latest v8. By the time you read it, it’s already out of date and incorrect. Just stop now, run your own tests, and make your own choices.

If node.js is still using v8 version 3.4.12.1, then it might be just a little valid for your node programs, but otherwise, no. Stop. Don’t even continue reading.

Results

First, if your function takes a variable number of arguments, and you don’t know how many it will be called with do not define any named parameters. It makes things more complicated, and dramatically slows down the process.

Want to just put all the arguments in an array? Do this:

function varArgsList () {
  var args = arguments.length === 1
           ? [arguments[0]] : Array.apply(null, arguments)

It’s an order of magnitude faster than Array.prototype.slice.call or [].slice.call.

Want to get all the arguments in a particular slice? (Like, say, everything after the first, or the second until the second-to-last, etc.) Well, that’s a bit more complicated. There, as with the patch from Mr. Aleph, you’ve gotta walk the list yourself.

For example, to do the equivalent of Array.prototype.slice.call(arguments, 1), pulling off every argument after the first, the fastest method seems to be this:

function manualMap () {
  var l = arguments.length
  var arr = new Array(l - 1)
  for (var i = 1; i < l; i ++) arr[i - 1] = arguments[i]

The fastest, if you know exactly which arguments are which, is to refer to them as arguments[i], and only array-ify if and when it’s absolutely necessary. So, not surprisingly, I was unable to out-perform Mr. Aleph in a v8 benchmark-off. My goal in this was simply to figure out how much of a difference it makes, and write a script to check it later, in case I find myself in a similar situation again.

Of course, [].slice.call(arguments, 1, 2) is far fewer bytes, and easier to know what’s going on. For most programs, the slight difference is not going to affect your overall program. But sometimes hot code is hot enough to slow your benchmarks down by 20% because of what seems like a trivial change.

It’s only over-optimizing if it doesn’t make a significant difference.