Node.js is Cancer (2011)(pages.citebite.com)
pages.citebite.com
Node.js is Cancer (2011)
http://pages.citebite.com/b2x0j8q1megb
18 comments
> 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?
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.
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.
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".
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.
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!
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.
"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.
I clicked the link and wondered why the author appears to have deleted the original post.
"I kinda remember this guy," I thought to myself. "Let me read what else he has to say."
Then I found this: http://teddziuba.com/post/24585610978/starting-over
Maybe he just didn't want to import his old posts into Tumblr somehow. Or maybe something else.
I dunno. Just thinking.
"I kinda remember this guy," I thought to myself. "Let me read what else he has to say."
Then I found this: http://teddziuba.com/post/24585610978/starting-over
Maybe he just didn't want to import his old posts into Tumblr somehow. Or maybe something else.
I dunno. Just thinking.
It's like how a super-villain goes evil, but not at all. I miss his brother...
I'm more disturbed by these comments that are pro trolling. I personally like to have thought out technical discussions without hyperbolic yelling, but I guess that's just me.
I've never worked with Node and probably never will, but it's pretty dishonest to conflate the sense of "blocking" as in "postponed execution" with "blocking" as in "executing an intensive CPU-bound job" to make a point that shouldn't be surprising to anyone who's paying attention.
This article does not do justice to Node and it is not even an accurate criticism of Node.
I can provide similar arguments about PHP, Ruby, Python as well as JAVA and say they are cancer too but they are not. Every technology has its limitations but there is no doubt that NodeJS has opened up many new possibilities when it comes to doing thing on web. It will never be able to do everything that say JAVA does but it will always do a few things lot better than say Java or Ruby.
A good developer will always pick the best tool for the job without being "emotionally attached" to any one tool.
I will also not criticize those who are doing crazy things like writing a JVM using javascript. These people are pushing the limits, faster we reach those limits it is better for the rest of the community.
I can provide similar arguments about PHP, Ruby, Python as well as JAVA and say they are cancer too but they are not. Every technology has its limitations but there is no doubt that NodeJS has opened up many new possibilities when it comes to doing thing on web. It will never be able to do everything that say JAVA does but it will always do a few things lot better than say Java or Ruby.
A good developer will always pick the best tool for the job without being "emotionally attached" to any one tool.
I will also not criticize those who are doing crazy things like writing a JVM using javascript. These people are pushing the limits, faster we reach those limits it is better for the rest of the community.
Every month this hits the front page of HN, and each time it's less and less relevant.
Not really anything useful in this article. To make fibonacci "non-blocking", you use process.nextTick callbacks to "interweave" the computations, just like real threads!
I think this post is certainly correct in addressing CPU issues, and certain problems with Javascript.
What it fails to recognize however is that the "how" of Node.js isn't the cool part about node. The cool part is the "what" which is bridging the gap between the client and the server. This is the reason that people tolerate writing more javascript, not because everone loves javascript.
What it fails to recognize however is that the "how" of Node.js isn't the cool part about node. The cool part is the "what" which is bridging the gap between the client and the server. This is the reason that people tolerate writing more javascript, not because everone loves javascript.
>The cool part is the "what" which is bridging the gap between the client and the server.
This is what loses me- how is that cool or good? I would much rather write a static html/css/angular frontend and have it talk to a Go webservice on my server. I want to use the best language for the client and server side, why do I care if they are the same? I want them to be basically completely independent apps where I could replace one or the other with a new implementation.
This is what loses me- how is that cool or good? I would much rather write a static html/css/angular frontend and have it talk to a Go webservice on my server. I want to use the best language for the client and server side, why do I care if they are the same? I want them to be basically completely independent apps where I could replace one or the other with a new implementation.
True, but there are cases when having the same language both sides can save some time, like validation routines for example. Not always appropriate, but can be a leg up on a project.
I'm a little confused about this. He complains about Node violating separation of responsibility, and then about putting HTTP servers in front of Node. Would anyone with more sysadmin experience mind explaining what the drawbacks of this approach are compared to a more traditional setup?
(2011)
I'm curious what Ted's view on Node.js is now that it (and he) has matured a bit.
I'm curious what Ted's view on Node.js is now that it (and he) has matured a bit.
[deleted]
My favorite sentence started with: "A long time ago, the original neckbeards decided..."
[deleted]
It's nice to see the "is cancer" meme provide some variety to the all too common "considered harmful". It's more biological.
http://www.theregister.co.uk/2001/06/02/ballmer_linux_is_a_c...
http://www.theregister.co.uk/2001/06/02/ballmer_linux_is_a_c...
Which do I dislike more?
Ridiculous font scale for chepaly repsonsive design SEO roach blog posts which gives me scroll wheel tendonitis..
Or blissfully, unapologetically unformatted content?
Or blissfully, unapologetically unformatted content?
You do realize this is an archived version of a Google cache, and all of the images/CSS referenced are all 404's as a result?
I don't agree with it; I think time is proving him wrong.
But that is hilariously written. I love a well-executed embittered screed.
But that is hilariously written. I love a well-executed embittered screed.
Hacker News jumped the shark xD
It only talks about CPU usage, Node not being Unixy enough, and Javascript being terrible.
A better critique would have included talks about callback hell, or the general philosophical issues of non-block/evented work versus synchronous programming: see the classic http://www.youtube.com/watch?v=bzkRVzciAZg .
This isn't even that great a rant.
(I appreciate my fellow Rails devs probably upvoting it out of spite, but c'mon...)