> Folks, why are you upvoting this?

Mostly, because it's funny. What's even funnier is how people take this sort of stuff personally.

I use Node, I know its limitations. I also use PHP. And Ruby. And Python. I use everything. I like having a full toolbox.

These languages are just that. Tools. If you went up to a carpenter and made fun of his hammer, do you really think he'll be pissed? He knows what his hammer is capable of and doesn't need anyone else to tell him.

A better question would be why this sort of commentary starts flame wars?

This is not directed at your comment individually, nor is it anything about your content in particular... but IF I HAVE TO HEAR THE TOOL/TOOLSET ANALOGY ONE MORE TIME to describe programming languages, I think I will... be disappointed in your lack of creativity. Really, don't you guys have any other analogies in your "toolbox"?

It's not even that great an analogy. If I use a particular hammer to build a table then I could throw it away at the end because it is no longer important as long as the nails are in the right place. I could even use a different hammer to drive every single nail if I wanted to and it wouldn't matter.

Languages , libraries , frameworks and runtimes on the other hand literally become a part of the end product. In many (maybe most) programs the total LOC count for the project is dominated by third party code vs original work.

So in this case they are not the tools, they are the nails.

Some analogies are more robust than others. But all analogies snap when stretched too far. I think this is one of those cases where you unfairly stretched it too far.

hammer : painting :: tool : finished_product

Though cliche, it's not like the analogy is misleading. Nails might not be "tools" since they can't normally be used on the next project, like a hammer can. But nails are still a means to an end, e.g. "hang painting on wall". If we really wanted to, we could stretch the analogy ad infinitum. "What's the nail represent? What's the room represent? Who bought the painting? etc." But the purpose of an analogy isn't to draw parallels between the objects' irrelevant particulars. Its purpose is to abstract from the objects an equivalency of relationship (i.e. means/end). In this case, I think the equivalency is preserved even after we extended our analogy in ways it was never intended to be.

It depends on the point that you are using the analogy to support. The tool analogy often gets trotted out to make an argument about something like language or framework choice not being important to the success of a project, but I think that the analogy becomes very brittle here for the reasons stated.

Deciding to switch something like a hammer (or text editor) mid project is likely not a big deal but switching to another language or framework can be an ordeal that requires planning. Since software projects are almost never "done" until they are obsolete the choice of language can have significant implications down the road that you wouldn't have if it was simply a "tool".

I think I understand what you're saying now. My mistake was reading "the tool analogy is undeservingly cliche/popular because it's rarely accurate" vs "the tool analogy is doesn't apply in this instance (to programming languages) because hammers don't have lasting side effects".

At some point in any rational discourse, all analogies become tortured analogies. The trick is in not focusing on how the analogy is wrong, but in what can be improved about the underlying idea. By all means, cast the analogy aside, for it is worthless on its own. It is only a means to relate to or understand the underlying idea.

Any time you feel inclined to dig-in and tear apart an analogy, it's wise to consider whether you're contributing to the refinement of the underlying idea, or just bikeshedding.

Yes! I have the car analogy in my toolbox as well!

It's not really an analogy though.. Languages, technologies and frameworks are just tools to build stuff. Said differently, to build stuff, you need tools. Programming languages are programmers' tools..

It is though, because they're usually referring to woodworking tools or car fixing tools - not the generalized term "tools".

> because they're usually referring to woodworking tools

Says the guy with the wooden name!

I use node, .net, java, php, python, ruby, different horses for different courses. Sounds like this guy just loves to argue, bet he's fun to work with....

It’s Ted Dziuba, a minor network celebrity and generally annoying dude with sensible technology competence and otherwise usual libertarian blabbing tendencies, including „get a life” style comments as evidenced in the post (if you tell people to get a life, you should get a life, and no, I don’t have a life). And this post actually got deleted, which is why you’re getting it from Google Cache. Consider that an art statement on the condition of Hacker News existence.

I dunno...

"I know there's a closed form solution. Shouldn't you be in front of a mirror somewhere, figuring out how to introduce yourself to her?"

is pretty great.

If you’re a teenager then yes. Otherwise, it’s an ad persona towards an expected legitimate complaint: „hey, maybe a lot of work actually isn’t CPU-bound?” Seriously, if you can’t discern between solution for CPU-bound and IO-bound problems, you should consider a different career.

I think the author didn't spell out the issue with that useless bit of trivia because the issue is obvious. Whether the implementation of the function is inefficient or not is immaterial to the argument. Most things arn't CPU bound, some things are. So the complaint stands.

Calling me a teenager, and then accusing the article of ad hominem six words later. Superb.

It's also two years old. I don't get it.