blog.izs.me

Seldo's Tumblr: To save you time, here are Friday's tech headlines in roughly chronological order

Fri, 18 May 2012 20:47:00 -0700

Seldo's Tumblr: To save you time, here are Friday's tech headlines in roughly chronological order:

OMG Facebook IPO OMG OMG OMG
Facebook Rises 50% in First Hour of Trading
Holy Shit Mark Zuckerberg Is So Rich Now
Look at All These Other Motherfuckers Who Are Also Rich Now
Some People Who You’d Expect to Get Rich Didn’t Get Quite As Rich As You’d Think
Oh Man Facebook Employees Are So Rich Now
Some Random Dude Who Painted a Wall for Facebook in 2005 Is Like a Millionaire Now
Facebook up 100% on Opening by Lunch Time
When Will Twitter Go Public?
Is Pinterest the Next Facebook? (Update: No)
Holy Shit Those Instagram Guys Are Even Richer Now
Facebook up 200% on Opening, Bigger Market Cap Than Jesus
Eduardo Saverin Is Some Kind of Douche, Huh?
Robert Scoble - “I’m Just Happy You’re Still Paying Attention to Me”
Sean Parker Is Also Hella Rich
Is Zuckerberg the Next Steve Jobs?
Some Dude Who Bought a Domain 20 Minutes Ago Raises $200M to Make “Pinterest for Video”
Are We Perhaps in Some Kind of Bubble?
Will Facebook’s IPO Hurt Obama?
“There Is No Bubble” Says VC Who Would Lose Billions if Bubble Burst
Is Vidterest the Next Facebook?
Facebook Plunges After Initial Pop, Closes at 10% over Opening
Is Facebook Doomed?
Why Facebook Is Here to Stay
10 Reasons Facebook Is Doomed
15 Reasons Facebook Will Be Bigger Than Google
Yahoo Is Still Screwed, Does Anyone Care? (by Kara Swisher)
Vidterest Acquired by Chinese Internet Portal for $2 Billion
Are We Sure It’s Not a Bubble?
“Stop Calling It a Bubble, Dammit” - Entrepreneur Raising Series A

Here are the slides from my TacoConf talk on “Anarchism for Fun and Profit”. Click on...

Mon, 14 May 2012 11:51:00 -0700

Here are the slides from my TacoConf talk on “Anarchism for Fun and Profit”.

Click on each image to go to the next one, or just scroll down leisurely. If you prefer, you can get this as a pdf or keynote.

I’m here today to talk to you all about Anarchism for fun and profit. Usually, the way we use these words, what we really mean is:

play and work. and as I’ll hopefully convince you by the end of this, what we typically think of as play or relaxation is just a brief recovery from what we call “work” which is actually bullshit.

This is what we ought to be doing.

So, I’m gonna give you a little bit of history, mostly to put these ideas into context. Then, I want to talk about how this applies to work, and some things I’ve observed in the world of software development.

Let’s start at the beginning.

“Anarchy” what does that actually mean? It’s not just a slogan for punk bands, but it’s also a pretty broad topic. The definition is right in the word:

“An” meaning “no” or “without”

“Archy” meaning ruler.

So, anarchy is the lack of rulers, hierarchies, and so on.

So, who runs things?

Basically, we all do

Of course, there are degrees of things. But typically, anarchy implies that associations are voluntary rather than forced, and that each person has control over themselves rather than being controlled by someone else.

A lot of this goes back to a guy named Max Stirner. Well, actually named Johan Schmidt. He wrote a book called “The Ego and Its Own”.

One thing that strikes me about Stirner was how similar his lifestyle is to some of ours. They had this philosophy discussion group back in the mid-19th century in a wine bar in Berlin.

Karl Marx sat in on a few of their sessions, Bruno Bauer, Friedrich Engels, and a bunch of other names you’ve heard of if you got a liberal arts education.

I don’t think they biked around eating tacos, and they probably didn’t write JavaScript in coffee shops, but the similarities to the Oakland tech scene are nonetheless pretty striking.

In this book, he said that the individual is consumed and overwhelmed by ghosts and illusions. In order to attain Right Action, these ghosts must be left behind.

Here’s a quote that I think sums up what is so interesting about knowledge workers when they’re really working at their best.

So, in other words, he wasn’t writing because it was his job, he was writing because it’s what he does. He is a writer, and he can’t find out the end of the story unless there’s someone to tell it to.

In this passage, he’s almost half-apologizing for inflicting the truth on society, because he fully expects it will incite revolutions; at the same time saying, “Well, I need to find out the end, so… deal with it.”

Beginner Ease

Mon, 30 Apr 2012 00:27:27 -0700

Pretty much on a daily basis, in some conversation either in real life, or over the internet, someone justifies a software design decision based on something being easier or more difficult to explain to beginners. Most often, this is regarding programming language design, or language patterns.

I think the “easier to explain to beginners” argument is a fine one if you’re tasked with making a bunch of beginners productive as fast as possible.

As it happens, with respect to the JavaScript language at least, I am not a beginner, nor do I share in code creation/maintenance with very many beginners, so that argument is not so compelling to me.

In my experience, most people spend a short time being a beginner, and then a long time being experts. By the nature of the time spent in each state, there will tend to be more experts than beginners, just as there are typically more adults than children. You certainly wouldn’t suggest that cars should be illegal simply because it takes so many years for a child to learn to drive responsibly!

Therefor, for me at least, it seems better to optimize to minimize the mistakes that experts continue to make, and use patterns that will be the most convenient for experts to maintain.

And becoming an expert is not so hard, really. It just takes a thousand hours or so of JavaScript use (assuming that the person already is a decent programmer in some other language). It’s a lot easier than becoming a competent dentist or hairdresser or lawyer, and there are plenty of dentists and hairdressers and lawyers.

As experts, we should not push for less powerful abstractions on the basis that newcomers have a hard time with them. Instead, we should push newcomers to become experts by supplying them with mentorship, support, and the truth.

That’s not to say that the language should be so difficult or abstract as to be completely impenetrable. We do need a nice smooth incline to the learning curve, so that newcomers will not be turned away abruptly. But in general, if you expect people to be somewhat smart and capable, they will be.

Re: @brixen’s "Is Node Better"

Mon, 09 Apr 2012 10:27:00 -0700

Update: The talk is online at http://blip.tv/jsconf/jsconf2012-brian-ford-6091521. If you weren’t there, you should go watch it before reading this.

As usual, this year’s JSConf did not fail to deliver. The parties, the location, the talks, the food, it was incredible. Chris Williams (and the rest of the JSConf family) really put together an incredible event.

By far, the most controversial talk was Brian Ford’s “Is Node.js Better”. I must admit, I walked in skeptical. Brian Ford seems like a bright and reasonable guy, but is clearly not a noder.

I’m not going to transcribe what he said. If you want that, read his slides and watch the video when it comes out. This is my reaction and response, and says more about me than it does about Brian.

This is based mostly on my meat-brain memory, and some notes that I scribbled. It’s quite possible that I may get some of the particulars wrong. However, rather than wait for the video to come out, I’d like to write this now, since the errors in perception are themselves useful information. If you notice any such error, please let me know.

Of course, there are limits to how deep a speaker can go into a topic in a 30 minute talk, and those limits are much shallower than how deep I can go in this blog post. So, I’d like to frame this response not so much as me-vs-Brian, but rather as just another public part of a longer multi-format conversation. My goal is not to produce more controversy than is useful, but to perhaps produce enough to keep things interesting.

Fair warning, this is a much longer post than most things I write. If you’re reading it, you’re probably interested mostly in the specific node stuff at the end. I’ve opted not to shorten it too drastically, because the topics are in my opinion best served by a thorough exploration.

[citation needed]

A lot of what I’m talking about is discussed in much more rigor elsewhere. This blog post is a synthesis, not a research paper. In addition to Thinking Fast and Slow which Brian mentioned, these are about the most approachable and informative discussions of the subjects that I’ve found:

The Right

Brian started his talk with a very insightful exploration of the nature of controversy. He talked about our fast brain and slow brain, and guaranteed that reading Thinking Fast and Slow would change your life for the better, or he’d refund the cost of the book.

In discussing the title of the talk, he made the point that every value judgement implies a comparison, and invites controversy. If presented with a choice of apples and oranges, and you remark that “oranges are healthy”, then the implication is that apples are not (or at least less) healthy. So, the question “Is Node.js Better” raises the question, “Better than what?”

Storming Brains

He went on to stress the importance of the scientific method, especially in cases where groupthink can grab ahold of a popular intuition. A powerful example of this is the idea of brainstorming, which has come under criticism in recent studies.

Of course, another fascinating point worth mentioning (which was not covered in Brian’s talk) is that the primary source of the criticism is a survey of the results of 22 different studies with different methodologies, done in different environments, on different subjects.

I’m wondering what the differences are between the 4 where brainstorming worked, and the 18 where it didn’t. It’s especially worth noting that 18 instances of brainstorming’s failure vs 4 instances where it was successful, does not imply that brainstorming is “usually” less effective: only that it’s usually less effective in the studies surveyed. If you check the weather in Wisconsin 18 times in the summer, and 4 times in the winter, you might conclude it’s usually tropical.

This survey was reported several times in the Journal of Personality and Social Psychology. More recently, these journal articles were summarized in the New Yorker and other popular magazines. To me, this smacks of “turns out”-ism. It might be that the popular intuition about brainstorming is wrong. It might also be that it’s just incomplete.

Organization

Brian discussed the concept that organizations tend to perpetuate the problems that they were designed to solve. To my mind, this implies that we ought not to try to solve our problems with organizations, but rather, to solve them with chaos and disruption instead, wherever possible. Since it is often not possible, and because “disruption” becomes just another buzzword meaning a specific sort of organization, we should make it our goal not to “solve problems”, but rather to find the problems that are hidden by our current assumptions.

“Solving” a problem, then, becomes more an exploration than a “fix this thing” exercise. An exploratory expedition stops exploring when it returns with an answer. Similarly, organizations that are designed to solve a specific problem (as opposed to organizations that are designed to, say, throw parties or make buttons) should have their own destruction built into their core constitution.

This principle of minimum institution has guided the choices we’ve made in npm and in Node.js, technologically as well as socially. It has shaped the community in subtle ways that are difficult to recognize from the outside. It’s a principle that is close to my heart, and it’s why Node and I have gotten along so well.

Behavioral Science

“Programming is a behavioral science.” Couldn’t agree more. However, the transition from “behavioral science” to concurrency as a way to deal with scarcity of compute resources felt a bit forced to me. From that point of view, everything is behavioral science, because everything we do is done out of some human need (or else we wouldn’t do it.)

I think it’s more precise to say that software development is behavioral science, because every interface is a human interface, and humans are even more unreasonable in their behavior than hard disk platters.

The Wrong

There were a few points where I believe that Brian simply was either incorrect, misinformed, or perpetuating and reacting to the very groupthink that he is ostensibly setting out to move past.

Justifications for Using Node.js

There were a few justifications for using Node that Brian listed:

same language on the client and server
there are many JavaScript programmers
Node.js is more fun

These are all interesting justifications, though really, the first two are rationalizations for the third. For a talk that started out by diving into the science of hedonics and decision theory (albeit a somewhat Gladwell-esque popularization of it), I was a bit disappointed to see that he didn’t go into more depth on this point.

He said that users call themselves polyglots, so he rejects the claim that a single language is actually relevant. This is a highly specious rebuttal. I can stand, but I still often find it pleasant to sit. It doesn’t have to be necessary in order to be valid in this case, it only needs to be comfortable. If you’ve never worked in a single-language stack, I highly recommend it. Even though you can’t share a lot of code in most situations, it does reduce the cognitive load switching between different parts of the application. This is the same reason that I’ve suggested using semicolons in JavaScript programs that include other non-ASI languages: reducing switching cost is reducing cost.

Brian claimed that the “many JavaScript programmers” argument is invalid, or at least, not very compelling. We ought to figure out the ideal platform, he said, and then provide advocacy, education, and resources to help people adopt it. This also strikes me as a bit weird. I’m not claiming that one should make all their technical decisions based solely on popularity, of course, but it certainly is not irrelevant. There’s something to be said for pragmatism.

People don’t use Node.js because it’s the same language on the client and server. They use Node.js because that language is JavaScript, and JavaScript is fun.

There aren’t more JavaScript programmers because of a lack of education or advocacy in other languages. JavaScript is fun (and unavoidable), and so all programmers use it.

“Node.js is more fun.” This reminds Brian of Ruby a few years ago. It’s important to remember, in the context of hedonics especially, that “fun” is a highly subtle term worthy of study on its own.

The problem with “Justifications for doing X” is that we do things primarily because of our emotions. Even the action of “being rational” is a thing that we choose to do because of a positive feeling attached to our self-image as a “rational person who does smart things”, and the assumption that we’ll get some pleasantly winful reward that feels good. When we really want to do something irrational, we usually have no problem reconciling the conflict with our preferred self-image as a rational individual.

Emotions are not just part of motivation, they are motivation. If you want to know why a person does something, don’t ask them to explain why they do it; try instead to figure out how they feel. It’s a much more challenging question, but it leads to much more interesting information.

About the word “hype”

When we have a good feeling about something (or even, when we just make any choice at all, and don’t quite understand why), our brain begins inventing rationalizations right away. The first one to pattern-match against “X because Y” is likely accepted as the “reason” we’re doing something, regardless of how much the truth of “Y” actually affects the likelihood of “X”.

Try asking a compulsive gambler why he goes to the casino. He might tell you about his “strategy” for roulette. Of course, this is bullshit. Roulette is a deterministically losing game; the more you play, the more you lose. Same with craps, slots, and (unless you’re the best at the table) poker. It’s the feeling of winning that he’s chasing, and the feeling of the chase. If he was truly motivated by the desire for money, there are obviously much better ways of getting it.

When a person shares their justifications for doing something, one of two things typically happens, in the “fast-brain”:

You feel the same way about the thing. The justification pattern-matches against “I should X-that-I-do because Y”, and so you accept the justification as rational, wise, and well-informed. After all, you already do it, so you must agree.
You feel differently about the thing. Or, at least, it’s not a thing you do, and so you have invented some justifications for not doing it. Your brain pattern-matches against “I should X-that-is-stupid because of Y”, and so you reject the justification as irrational, foolish, and ignorant. After all, it’s stupid, so any justification must be misguided.

If you have some vegan friends, and some friends on the paleo diet, and feel like watching some fireworks, ask them in each others company why they eat the way that they do. No matter how polite they try to be, each will subconsiously perceive the statements of the other as an attack, and feel the need to defend their position. If they are wise enough to retreat from needing to convince the other, they’ll most likely at least make a big show about “agreeing to disagree”. (Of course, if they’ve been on this diet for a while, they may have enough practice at these sorts of situations to handle them quite gracefully.)

If X is not just “do this action”, but rather “feel this way”, and you do not already feel that way, and the justification is not enough to incite this feeling (as justifications almost never are), then we label it “hype”, and it raises the bar that we now require to take the thing seriously next time.

Like so many cognitive shortcuts, this is a really good move much of the time. After all, people’s justifications are usually self-delusions as often as well-informed and rational reasons for doing or thinking anything. It makes perfect sense to be extra skeptical when we are at the risk of being influenced by it. If we have to be extra skeptical over and over again, we start to pattern match “X is good” into the hype category. Suddenly, it’s not just that veganism or paleo is not for me, it’s that the diet is a mark of a foolish person.

The net result is that anyone saying anything positive is likely to be labelled a “fanboi”, and their statement called “hype”, no matter what they say. This is a dangerous feedback loop that leads technology communities to stagnation, bitterness, and chest-beating.

Yo Dawg! I heard you like cognitive distortions, so I distorted your cognition so you can distort while you cognit!

The mind is such a wonderful thing! Mistakes in the mistake detection lead to potentially valid statements being discounted because they are presented along with invalid justifications, or presented by a low-status speaker, or are in conflict with already-held beliefs, especially when those already-held beliefs are a part of our Tribal Story.

Even worse, you have situations where we see a few “X is good because Y” justifications, deem them false, and then subconsciously internalize the fact that we gain status in our tribe by applying the “hype” label and discounting it, resulting in spiraling down into the toilet. Politicians and marketers have made a science of getting us to elevate arbitrary ideas into this Tribal Story, blinding us to any disagreement.

Birds fly. Fish swim. Humans make mistakes. It is our Super Power. We all do this.

We almost never change our minds. We are influenced in ways we are incapable of detecting (and will deny!) We are motivated by the behavior of people who look like us superficially, and believe (at least temporarily) literally everything we hear.

There is virtually no limit to the ability of the human mind to find new and creative ways to get out of touch with reality. I don’t want to give the impression that I (or anyone) could delineate all the many subtleties of human cognitive error. Every one is so rich and complicated. Even this discussion of pattern-matching “X-because-Y” is a serious oversimplification.

In the ancestral environment of adaptation, disagreement was often fatal. We’ve gotten a bit better at intelligent disagreement, but we still try unconsciously to come to an all-or-nothing agreement within our own heads, annihilating any “bad” idea entirely, and shrowding any “good” idea in a halo.

Whenever tempted to call something “hype” (or, even, “anti-hype”), I try to remember to ask the following questions:

Is the provided justification evidence, data, or an expression of a feeling? What is the speaker’s experience of the thing being discussed? If it’s evidence, is it reproducible? If it’s data, is it relevant?
How do I feel about the subject? How did I feel about it yesterday? What are my justifications?
Am I tempted to dismiss this? Is it because of bad evidence, a speaker who holds low status in my tribe, or because I disagree with the feeling? If it’s a lack of evidence, what evidence would make me feel the same way? If it’s a feeling I don’t share, what other things do I feel that way about? If it’s a low-status speaker, how would I feel if <person I respect> was saying it?
Am I tempted to accept this? Is it because it agrees with something I already think? What new information does it actually contain?

This is part of the reason why I try to criticise Node.js and npm as harshly and often and publicly as I can. I do think that they’re tremendously useful tools… but how can you believe me if I tell you that they’re perfect, when I clearly know better? And if you can’t believe me when I talk about Node.js, then what good am I?

Better justifications to use Node.js

The IO paradigm is a good fit for your problem, and V8 is fast enough. This is the case for a lot of web software, but definitely not every program. Node.js really does make it pretty easy to write things like IRC bots and crawlers and websites, and is probably not ideal for many compute-intensive applications.
It’s fun to write programs in this fashion. There are time-honored traditions of thinking of data as streams of bytes, and JavaScript is a relatively simple and expressive language for doing this in creative ways.
It’s fun to be a part of making a popular platform better. The community is active and still pretty friendly, and that feels good to be a part of. Newcomers turn into regulars and then celebrities very swiftly. All it takes is a bit of persistence and enthusiasm.
You prefer the simpler approach to asynchronous programming, using a callback/observer model (or actor model for child processes), rather than something like green threads or coroutines that “look” synchronous.

If you’re not writing systems that are well served by nonblocking IO, or an event loop/observer pattern approach, or if you don’t think it’s fun to make programs this way, then you probably shouldn’t use it.

But, even that aversion is worth looking carefully at that, no matter what you decide. V8 is an extremely fast virtual machine, and these days, a lot of programs are IO-bound.

And even if it’s not, we tend to focus on “the right tool for the job”, at the exclusion of “an awesome tool for the job”. The opposite of “right” is “wrong”, but the opposite of “awesome” is “boring”, which is sometimes worse, especially if you’re trying to maximize creativity.

I’m not sure how much research Brian did when he went out looking for justifications for using Node.js, but I don’t think he really got at what actually is driving so many people interested in this thing.

Controversy

So far, I felt like the setup was nice, but the criticism itself was kind of lackluster. We’ve heard it before. Node is hyped. The single-language stack isn’t all it’s cracked up to be. Etc. I was eager for the meat.

No sooner had I thought this, than the next slide said:

Node.js rejects reality

Aha! There it is. That primal “under attack” feeling, the visceral tension in my lower abdomen, the warmth on my face.

When I was younger (and still today when I’m not at my best, I must admit) the temptation was to hit back, or dismiss the message. Fight or flight. I think Brian probably lost a bunch of the audience with this slide. It sure did get my attention.

These days, when I feel that reaction, I try to leverage the added awareness that comes with the adrenaline, to be on the lookout for whatever comes next, because it is full of valuable information, especially if it is highly disagreeable. Beware of the moments when rationality tries to slip away: those are the times you most need it.

As I am somewhat dogmatic about endeavoring to reject reality less, I was very excited to hear what we might be missing.

Sadly, the justification for the “ignores reality” claim was not as pointed as I would have liked. It amounted to:

JavaScript is a garbage collected language. Garbage collection pretends that you have infinite memory, and you don’t.
IO always “actually” blocks somewhere, so the comparison between events and blocking is not valid, since it has to block somewhere.

For sure, garbage collection is tricky, and the interaction between Node.js and the V8 garbage collector could probably be improved. But to call it a lie is a bit silly. Garbage collection doesn’t pretend that you have infinite memory; that’s virtual memory. Garbage collection pretends that you don’t have to free memory in order for it to be re-used.

One of the biggest pain points of non-managed languages is having to explicitly free memory. The biggest pain point in managed languages is having to deal with a garbage collector. There may be some sort of approach to memory management that isn’t collected or manual, but better than either. If so, I don’t know of it, and it doesn’t matter anyway, because that is a language design problem, and Node.js is not about designing a language. If you have a beef with garbage collection, take it up with V8 and TC-39.

As for node being single-threaded, and IO always blocking, that’s kind of confusing to me. Of course, you don’t actually have application-level processing of IO in parallel, since there’s only a single JavaScript thread, but IO definitely is performed in parallel to the degree that the machine can provide, and “nonblocking” is the technical term for the type of IO that node does on sockets. (Nonblocking IO on files is simulated using threads.)

I’d really like more details about what exactly Brian was referring to on this point about IO “always blocking somewhere” and in what way Node.js rejects that reality.

entire ecosystem of tools and libraries must be built

This was a valid concern in 2010. I said at the time that it would not be an issue in a few years. It’s not an issue today.

To an extent, this was by design. A large part of Ryan’s reason for choosing JavaScript was that it is the only popular interpreted language with a suitably powerful VM and no existing IO paradigm. Additionally, to the extent that JavaScript does have a tradition of IO, it’s XHR and the DOM, which are event-based and asynchronous.

Since the birth of Node.js, a lot of libraries have been built. There are 8500 modules on npm. There are bindings to every popular database, sophisticated test frameworks, template libraries, HTTP routers, and so on. It’s easy and fun to write modules, and so people have written modules. This approach is remarkably valuable.

That being said, module discovery and visibility leaves a lot to be desired. npm has grown much faster than Rubyforge or PyPI, much earlier in the life of Node, and so we have hit these problems earlier.

Regarding tools, things are coming along quite nicely.

Post-mortem debugging with MDB just landed in the master branch, and will be in node 0.7.8. (Node v0.6 has had this for a while already.) Mad props to Dave Pacheco for that. Seriously, if you’ve never seen it in action, it’s amazing. In all my years using PHP, I can’t even count the number of times I’d desparately wanted this sort of thing. The zend IDE had some pretty good debugging capabilities, but Dap’s jsstack stuff is truly magical. Call me a fanboi, I don’t care: believe the hype. It’s fantastic. The only sad point is that it’s only available in SmartOS, but it’s not exactly surprising that the OS made by Joyent has some special love for Node.js ;)

The DTrace support in Node is also impressive. Again, not surprising, given the fact that so many DTrace heavyweights work at Joyent, but the go-to DTrace library for node is not written by a Joyent employee. It’s Chris Andrews’ node-dtrace-provider module. Anarchy > curation, yet again.

The depth and breadth of information that can be provided by DTrace, and the great work by Brendan Gregg and others at Joyent to actually massage that data into a format that humans can easily consume, is absolutely phenomenal.

Similar work on run-time analytics and post-mortem debugging is underway at Microsoft, I’m told. Windows users: stay tuned.

As a long-time text-editor-and-shell guy (moved from TextMate to vim a while ago), I don’t really follow the IDE stuff too closely. But, Microsoft, Cloud9, and many others are iterating furiously in this space. Many of them are leveraging their existing work on other JavaScript tooling, so it’s moving quite fast.

The built-in node debugger client is more my style, but node-inspector hooks into the Chrome debug tools, which imo blow away most visual debuggers available. (They even have heap analysis tools!) There are also plugins for Eclipse to provide stepwise debugging and analysis, and a lot of existing Eclipse users are more at home there.

So, it’s not so much that the ecosystem of tools “must be built”, as much as that it is being built, and leverages the existing JavaScript, V8, and system tools that already existed before Node showed up. In many ways, Node.js provides one of the first server-side systems that can fully take advantage of these things in a mostly cross-platform fashion.

Node.js will reproduce the last 15 years of ruby mistakes

Bold claim. One that I was excited to see ample justification for. What are the last 15 years of Ruby mistakes? How can we avoid making those same mistakes? How did ruby fix them? What can we learn from ruby’s experience?

Brian’s main justification of this point was that the cluster module is a repeat of Phusion Passenger.

It’s not entirely clear whether he was referring to TJ’s “cluster” package, or the built-in “cluster” module in v0.6, or the much improved “cluster” module in node v0.7. None of them are a particularly close reproduction of passenger, though I suppose that TJ’s is probably the closest. But it’s not as if any of these are an Apache plugin, or tied to a specific web framework. The analogy is a stretch, to say the least.

What’s even less clear is how Phusion Passenger, a program written in 2009, and widely recognized as the most effective and popular way to deploy the most effective and popular Ruby application framework, can possibly represent a “mistake”, let alone 15 years of mistakes.

I can only conclude that I do not understand what he was trying to say, because otherwise, I cannot make sense of it. Maybe there was something else called “passenger” in the Ruby world once upon a time, which did kernel load balancing, IPC, and not much else. Perhaps this “passenger” was deemed a mistake, and is now gone.

Show me a ruby mistake we’re reproducing, and I’ll make sure it gets fixed.

process concurrency is doomed

Brian declared that process concurrency will never be able to scale adequately. I cannot accept this without data. Instead of data, he gave some hand-wavey assertions about garbage collection getting out of control.

I’ll assume that he was running low on time, and perhaps had to cut out the histograms and demonstrations. So let’s leave that question open.

Of course, spawning one process per request, or one process per IO or timer, is completely unreasonable. That’s why CGI was not adequate, and no one runs a real web platform on bash. However, running a single process per core, and having multiple HTTP servers share the open socket, and then using an event loop for IO and timers, is remarkably effective.

If there is doom on the horizon, don’t hint about it. Show me the evidence.

symmetric errors, chain of evidence

Finally! Something that genuinely sucks a lot in Node.js!

Domains is on the list for v0.8. I don’t know that the first pass at domains will be the final and ultimate fix for this, but it’ll be something to iterate on. This will make errors much more symmetric, and provide a much clearer chain of evidence.

The chain of evidence is also much improved by having post-mortem debugging of production systems. If you haven’t yet, check out Bryan Cantrill’s talk And It All Went Horribly Wrong.

So, this is important to me, it’s important to Node.js users, it’s important to the various companies paying the salaries of the node core team. It’s reasonable to trust it’s high priority.

Problems I Wish He’d Mentioned

If you want to know what’s wrong with node, ask a node-core developer.

These are some of the things that are really problematic, some of them in a pretty deep way. Of course, these are the things I know about, so they’re things that we’re working on for future releases of Node.js. If there are things that you think belong on this list, let us know.

Some of them are very hard, and will require iteration. Some of them are pretty straightforward, and will be addressed soon. Some of them are not super difficult, but just lower priority, and won’t get addressed for a while.

Debugging. See above. It’s our top issue, and it’s coming along. It was mentioned, but less strongly than I would have liked to see.
It is very hard to get visibility into which pending actions are keeping the event loop running. This is a source of subtle errors. The libuv refcount behavior is in the process of being cleaned up, and v0.8 will include a mechanism for seeing exactly which handles are in an open state.
The Stream API, which is by all accounts the core use-case for node, is remarkably inconsistent and hard to extend. It’s a lot nicer in v0.4 and v0.6 than it was in v0.2 and before, but it’s got a ways to go yet. We paper over a lot of the inconsistency in the Stream.pipe() method, but it’s a source of many subtle issues. Node v0.9 will focus primarily on this issue.
It’s hard to find good node modules. Reducing the barrier to entry for node package creation has made it a lot easier for more people to take advantage of. However, when you solve a problem, you open the door for new ones that were hiding behind it. We’ve grown faster than most platforms, which means that we’re encountering the discovery issues sooner. This will be addressed in the coming months with a new npmjs.org website.
The Node.js project lacks a consistent and visible continuous integration system, so performance degradations can occur silently.
Using binary modules is overly difficult, and requires a build toolchain on the install target. Work is underway to improve this, but it’s tricky.

And of course, just the fact that Node.js is very young, and has some bugs. It’ll no doubt get more, as we continue to work on it, but the goal is to change things in ways that make these bugs easier to spot and easier to fix.

It is not sufficient for Node.js to be better than any other platform. It must be so good that it permanently raises expectations in this space. It must continue to impress and delight users. There is so much work yet to do, it’s mind boggling.

Laurels are not very comfortable to rest on.

And finally…

If you’ve gotten this far, congratulations. I try to keep blog posts much shorter than this, but there was a lot to respond to here, and touched on several issues that are very close to my interests.

Brian’s talk was fascinating. Even the mistakes were interesting. When the video comes out, I highly recommend watching it. Go get Thinking, Fast and Slow. I haven’t read it, but I’m familiar with some of Kahneman’s other work in behavioral economics, and I suspect it’s every bit as fantastic as Brian claims.

I got a chance to talk to Brian after the talk, and so hopefully a lot of these points (at least, the specific technical details of what sucks in Node.js and what we’re doing about it) doesn’t come as a surprise to him. He seems like a genuinely nice and thoughtful person.

For a talk that started off with a request that we use science and make conflict useful, I was disappointed that his criticisms of Node were lacking in scientific rigor or constructive calls to action. But as I mentioned earlier, it’s hard to fit it all into a 30 minute talk. I hope this conversation will not end here.

We’re all humans. We all think wrong. We all love, and worry, and try to do interesting things. We all fail, and feel shitty, and try to explain why we’re not a bad person for it. We all succeed, and want to brag about it. We tell ourselves stories, and sometimes those stories are true, but usually they’re only just true enough to get by.

Try to remember this, the next time you’re telling someone how awesome (or over-hyped) Node.js is, or any other thing you have feelings about, and they suggest that you may be a brainwashed idiot. They are just trying to protect something, as are you, and in the course of this protection, our instincts will cause us to fail.

Show that monkey brain who’s boss! Slow down, breathe, and try to remember that this person who disagrees with you is not some big dumb idiot, but most likely a very thoughtful person who’s trying to do their best to create truth and beauty in the world. If you don’t learn what motivates them, how can you ever join forces?

Many thanks to Mikeal Rogers, Bryan Cantrill, Marco Rogers for reading early drafts of this post and providing feedback.

Stack

Sun, 08 Apr 2012 00:04:00 -0700

A stack of things, is right now on my floor,
And the stack’s depth currently measures four.
At the bottom, a table I bought at a local thrift store,
On it a pack for computer, and more
On that, a t-shirt, my girlfriend today wore
And on that, a cat, who is a plasticovore,
Next to him, are some flowers, but they don’t rhyme.

merlin: Inspecting the World’s Most Derp-Derp Subway Map

Sun, 08 Apr 2012 00:02:52 -0700

merlin:

Inspecting the World’s Most Derp-Derp Subway Map

Sexism, Words, and Marketing

Fri, 23 Mar 2012 09:40:00 -0700

Go read this: Oh Hai Sexism. (Aside: I’m finding that more and more of the news stories I really like are on Storify, which I first heard about as one of the earliest Node.js adopters. Nice to see them doing well.)

Some of the confusion on the part of bystanders to this flame war was, “So, there’s a model being objectified in an underwear commercial. What’s the big deal?”

However, a very important point here, I think, is that this video was not being used solely to sell underwear, and that’s where it started going wrong.

Design Like Whoa is a clothing company. Clothing companies use models to sell clothing. Models are chosen for their looks, and they are literally objectified, as part of their job. They’re also consenting, and reasonably well paid. This method of selling clothes is used by just about every single clothing company, because it works. I don’t think there’s a single thing wrong with the video as such, qua underwear commercial, or at least, nothing that isn’t also wrong with the whole clothing industry and our irrational ape-brained methods of choosing clothing, but I don’t think DLW can be expected to change that. It’s actually relatively un-sexy, compared to other underwear commercials. Quid veritas

Add to this that Design Like Whoa markets their clothing by putting startup logos on them. Not a terrible plan, I mean, if it moves clothes, why not, right? People are passionate about the websites they use. Lots of companies put various logos on things to sell them by associating with the brand. Allegedly, Geeklist gave DLW permission to use their logo, and then DLW made the video without Geeklist’s involvement, and just happened to choose their branded apparel in the commercial. I’m willing to give them the benefit of the doubt there.

Edit: Geeklist was “involved” with the making of the video, somewhere between “It was all their idea” and “They asked for photos, and got a video.” It’s not very relevant to the points I’m trying to make here, so I’m not going to go into it any further. Gemma says this. Christian disputes (via private email) some of what she wrote, but not all. There’s definitely some room for interpretation. I’m not really interested in the finer points of how this started, as much as where it ended up. Bottom line: no one intended to offend anyone at the start, but that doesn’t actually matter in the end.

The problem, however, came about when Geeklist decided to use a women’s underwear commercial as a marketing technique for their own product, which is a social networking website for people in technology.

This was the first line crossed. I hadn’t seen that marketing, since I never use geeklist and don’t really care about their product except for the fact that it’s written in node. (That’s not intended as a slight against Geeklist. It seems like a fine enough product. I am just set in my ways. I use twitter and github and IRC, and that’s about the extent of my social networking. I don’t really use Facebook much, either.) Using a model in underwear to sell underwear is fine. Using a model in underwear to sell an inclusive social network for technologists? Sends the wrong message.

So far, in my book, no major harm done. Doing interesting things means taking risks, and taking risks means sometimes being wrong. It’s important to give people permission to make mistakes, or else nothing interesting happens. The trade-off of that permission is the trust that they’ll act appropriately when their mistakes are made known to them.

According to Heather Arthur, at least one private complaint about the video was ignored.

Heather’s email should have been taken as a red flag. Heather is exactly the sort of person that geeklist should be trying to target: She’s young, prolific, and very actively involved with several happening developer communities. She is a paradigm example of Geeklist’s money demographic. Any principles aside, if she felt put off by their marketing, then the marketing is broken, period.

Shanley Kane complained about it publicly on Twitter. Again, I can’t really think of anyone more fitting the ideal Geeklist target demographic. A product manager and marketeer at Basho (maker of Riak, one of the most relevant nosql databases), and also a Ruby coder and technical hobbyist. Someone who goes to conferences and networks with technologists as her job. Geeklist should be happy to get any feedback from her, and should take it extremely seriously if she’s put off by their marketing. Anything short of a brick through the window should have been accepted gratefully.

This was an opportunity. There is rarely a case where the right answer is so obvious. Christian could have replied, “Good point. I’m on it. We don’t own the video, I’ll talk to the person who does. No offense was intended. Thanks.” and actually walked away from this event perhaps not a hero, but certainly not a villain.

Instead, he got defensive, and took offense at Shanley’s “insult” to his “brand”. News flash: you don’t get to have a brand, or a project, or a company, or any public anything, without people insulting it. People say “fuck” sometimes. That’s just how it works.

From there, it spiraled WAY out of control. However much Shanley’s “cursing” may have offended geeklist’s brand, Reuben’s and Christian’s response to it was much worse. The veiled threats about talking to Shanley’s employer were just so far beyond what is sensible or appropriate, I am at a loss for words.

There was an apology, and the video is now gone, which I guess is good. But my two worst nopology pet peeves are in there: “We apologize if…”, and justifications for the behavior that they’re ostensibly apologizing about. Don’t tell me why I shouldn’t be offended, and then apologize if it was offensive. Tell me why I should be offended, and then apologize because it was offensive.

As Mikeal put it, “apologies that don’t contain the words “we fucked up” aren’t usually genuine.”

Put aside your immediate feelings and keep your eye on your choices and their likely results. This isn’t just part of being a grown up, it’s basically the definition of being a grown up. People won’t remember that you valiantly defended your brand from the vicious assault of an outraged feminist. They’ll remember that you insulted and intimidated the exact sort of person you’re claiming to cater to, and you’ll lose their trust.

Can we please go just a few weeks without some insecure startup founder pissing off a huge chunk of the technology community with macho antics? And, really? I don’t care if you actually are a beer-chugging juggy-hooting misogynistic bro douchebag in the privacy of your own home. Just please keep it out of twitter, the work place, conferences, and other public forums. Just temporarily, in public, pretend to be grown ups. Think about your words, and choose the ones most likely the have the effects you desire.

There are smart talented women going into applied science and fucking academia because of you asshats. Clean up your act. We need more good programmers, and you’re scaring off half of them.

Addendum

Just to clarify, I’ve met Christian Sanz numerous times. He seems like a really nice guy. It’s easy to get swept up in a flamewar and say stupid things, and a lot of us have done so. They clearly realized much too late that the train was headed for crazy town, and fumbled awkwardly to try to change course. I’m more disappointed than angry about all this. It’s kind of sad, really.

A person is not just one conversation, and a product is not just one person. My hope is that Geeklist (particularly Christian and Reuben) will learn from this event and let it inform their actions the next time someone criticizes their marketing decisions, rather than be so scared off from the event that they stop taking risks at all.

Watch this video. I really like a lot of what he has to say. ...

Sun, 18 Mar 2012 10:40:00 -0700

Watch this video. I really like a lot of what he has to say. Two main comments:

165 Exceptions in the standard library, is enough!? Are you fucking kidding me? JavaScript has 7, and if you ask me, that’s way too many. URIError is completely unnecessary, and EvalError is always better off being expressed as something else. The only Error types you ever need to use in your code are Error or TypeError. That being said, “Don’t create a new exception type” is 100% spot-on. Even having typed catches in the language encourages this kind of awful profusion.
The reliance on “the standard library” is, imo, a bad thing. The idea that we should not reinvent wheels is great. s/standard library/npm registry/g and you’ve got me.

Many aspects of the Node.js module system, and the npm package registry, are built with exactly these principles in mind.

module.exports allows you to export a single thing from a module. If I had the opportunity to do it again, I’d only support that, rather than an exports object. If you really want to export multiple things, you’d still be able to, but it should be an extra mental leap to do so.
The single-level namespace in the npm registry makes it a bit less likely to end up with garbage like com.initech.utils.UtilityFactory.UtilityFactoryExceptions.UtilityFactoryNotFoundException. “Namespaces are for preventing collisions, not for creating taxonomies.” I cheered when he said this.
Once upon a time, I foolishly implemented the proposed “modules” feature in package.json. Ryan gave me a lot of shit about that and refused to support it in node, no matter how easy it was to do. I realized (a bit too late) that he was absolutely right, and pissed off some folks by removing it. Today, you get one main module defined in package.json. That’s it. A package is a module. Yes, a package is also a folder, and modules are files, so you can dive into it and get at its guts. But it’ll feel off, because it’s weird, and non-standard. You’ll get funny looks. This is on purpose, because it nudges you towards a flatter namespace by default.

The social engineering in node and npm is always more carrot than stick, and we always try to nudge people in a good direction by saying “no” to a feature rather than saying “yes” to one. This hasn’t been done perfectly in the past, but I am fairly proud of the results.

It’s a shock to someone who’s used to writing giant monolithic programs, and has to re-think how they draw their boundaries. That’s good. In fairly short order, things like local installs and limited exports start to “click” in a programmers mind most of the time. I’ve seen a lot of people start out frustrated and angry, and then a month later tell me how odd it is to use other platforms that don’t have the a similar approach.

When you solve a problem that others accept as the status quo, you often end up finding new problems. You don’t have to worry about coming up with unique descriptive names for your programs when you can nest them 7 layers deep underneath a company name. You don’t need to come up with approaches for managing a deep dependency graph if conflicts are insoluble.

Addendum

It’s not that I’m against using classes. I’ve written several programs that use classes extensively. It’s the proper abstraction for a long-lived object that needs to keep state and be interacted with. The hoop-jumping required to do this sort of thing in pure functional languages, with accumulator sets and so on, is kind of silly sometimes.

That being said, the point of using classes is to make things easier. If your class is a fire-and-forget thing with a single method, then it’s really just a function, and would be easier expressed in that manner.

There’s no hard and fast rule here. You have to actually think about what would make your program easier to use, easier to debug, and easier to understand.

How I Would Do It

Tue, 13 Mar 2012 16:15:00 -0700

One of the most common shorthands for evaluating the choices of others is to internally ask ourselves if we would make those same choices in the same situation. If the choice is “Not how I would do it”, then it is deemed “Bad”, and reflects poorly on the chooser.

Like most sources of error, this shorthand is insidious precisely because it is a valuable time-saver in so many situations. A person doing foolish things is likely a fool, and by establishing this aversion early, we can save ourselves the trouble of evaluating their future actions and words in depth. If there’s something that I know how to do — whether that’s writing a JavaScript program or making meatloaf or listening to music or dating — then approaches that look off probably are. Difference smells funny, and why look deeper?

Not every change is an improvement, but every improvement is a change. We must be ever vigilant to not turn our noses up at progress simply because it is new, or at help simply because it comes in a shape somewhat different from what our own hands would make, or at a friend simply because they like different things.

Coffee, sun, and hacking. <3 (Taken with instagram)

Wed, 22 Feb 2012 16:40:51 -0800

Coffee, sun, and hacking. <3 (Taken with instagram)

Giantass ship, as seen from my desk. (Taken with instagram)

Thu, 16 Feb 2012 17:40:14 -0800

Giantass ship, as seen from my desk. (Taken with instagram)

Bikes on Bart (Taken with instagram)

Sun, 12 Feb 2012 12:56:43 -0800

Bikes on Bart (Taken with instagram)

Software Personality

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

Software Personality:

fetchnotes:

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.