Hacker News Reader

  > Regarding the actual program, I don't write shell
  > utilities in JavaScript so I can't say whether it's a
  > good or a bad implementation. It's just not my space.

According to some other posts here, the quoted mockers are Ruby programmers. I believe the Twitter posts are about the concept of writing sed in Node-Javascript, not necessarily the implementation. As I understand it there's something of a rivalry between the Ruby and Node communities, and the Ruby community is known to be tolerant of boorish behavior.

So there is some truth to the stereotype of the angry asshole Rubyist?

I thought the community had moved on since those days. I've been tossing up whether to learn Ruby or Clojure next, and this kind of crap is a real turn-off for Ruby.

Do Clojure. Ruby suffers from a number of serious basic errors in its design. I'm in the middle of the long task of writing a clear, substantive criticism of them, but why they were bad choices is quite subtle, though it has large implications. That and Ruby has a culture of little or no documentation, even of the standard library, no attempt at consistency in APIs, even for something as basic as different kinds of network socket, and a community with rather more noise and rather less experience than makes me comfortable.

As much as the "truth" of the stereotype of the jock PHP developer or smelly, fat, bearded C developer. That is to say, those people surely exist within each world but it's a shame when others lack the peripheral vision to see the true, bigger picture without falling into stereotyping.

I'm not a regular user of either, but I've much more enjoyed my time playing with Clojure and lurking in the community. For the most part they seem like solid people.

That's what you're taking from this? Really?

As someone remarked elsewhere in these comments:

    > There is no "open source hivemind" so please don't 
    > disparage the millions of open source coders who 
    > will never make the frontpage of HN by lumping the 
    > entire conglomerate into one community.

Having tried Ruby for a year, I have experimented this myself. With a strong OOP background, I can assert that it's not even an elite that enjoys ridiculing noobs.

It reminded me of this: https://www.youtube.com/watch?v=YX3iRjKj7C0

Also, just look at the top comment in that video. The irony.

Oh is that what it is? The tweets weren't specific enough. Basically a point and laugh response but I didn't get it. I looked at the code briefly and it certainly seemed odd that node/javascript was being used as a command line tool to do something that can already be done with other tools, but this person created this to make their life easier.

Created. Had a problem and wrote working code to solve their problem. Then shared it. Not really something to point at in mockery.

Hum. It reminds me of performance art, to be honest.

It does, any art really. If the software were the brushes, no piece of software is right for every artist.

Should we trash people for making 'yet another social network' or 'yet another online map database'? This is even a smaller scale project and barely worth the effort to complain about.

Programming can be a much more creative exercise, and sometimes people forget that. I don't always do things to be useful, I do them to be fun and educational.

It's disappointing that someone like you who is trying to share information and learn together would be attacked like that. People are awful.

I have a new policy of not responding to any comment that includes any form of ad hominem argumentation or any continued argument that is full of logical fallacies. It's just not worth the time to be arguing with people on Reddit or HN.

I have to agree. You need to look at the quality of the people who like you vs hate you.

There's plenty of haters on the Internet. As jrockway said (just a couple comments up): "If you do something, chances are someone hates you. Why? They are jealous that you are getting attention instead of them."

I heard a metaphor once: You've got a bucket full of crabs. If one crab tries to crawl up and out of the bucket, the other crabs drag him back down.

Try your best to ignore the haters.

I looked at the actual code and, although I'm no expert with Node, it looks pretty reasonable. The only things I can find to criticize was the word "replacize", which makes me cringe much like "performancing" or "optimizely", and the use of == instead of ===. But I think reasonable people could disagree about those things. Someone who isn't me might think "replacize" is sufficiently humorous to retain, for example.

The nesting goes a little deeper than I would like: https://github.com/harthur/replace/blob/master/replace.js#L9... is 7 indents deep, for example, where I think something like 4 indents is a place where I should stop and start questioning what I'm doing. But three of those indents are a tradeoff forced by the node.js async API: anything that has to wait on the result of an asynchronous operation must necessarily be in another function, and you can choose whether to nest that function deeper or to move it somewhere unrelated and give it a name; and you have to use error codes instead of exceptions for error handling from those operations.

The program actually includes a synchronous version of the same code, where the line corresponding to line 90 above is https://github.com/harthur/replace/blob/master/replace.js#L1..., the blank line following "var text = fs.readFileSync(file, "utf-8");". If that fails, it throws an exception, so the "if" block isn't needed, and the code that follows doesn't need to be nested.

This is the agony and the ecstasy of Node: everything is (normally) asynchronous, giving you unwanted levels of nesting, but on the other hand, everything is asynchronous, so you can process the files in the order that the filesystem finds it most convenient to return them to you in. I wouldn't be surprised if it turned out that Heather's code was typically much, much faster than find | xargs -P sed, simply because it was able to productively manage many more outstanding I/O requests at once.

Line 90 also points to a pitfall that often befalls us with parallelism: at some point parallelism stops being productive, so you have to limit it. In this case, Heather's code throws the ball back to the user and suggests that they rerun their command in synchronous mode — albeit having partially completed the replacement task, which might be a bad failure mode, depending on whether your replacement is idempotent.