Hacker News Reader

Comment by craigc | Hacker News Reader

I think people here need to lighten up. I know we are all programmers, and we are sometimes portrayed as snobby and entitled, but we don't have to live up to those stereotypes.

I understand it's frustrating when a tool you use is expected to work a certain way and it doesn't. I understand it's even more frustrating when the output could change depending on the time of day. That doesn't mean it is our place to gang up on an open source tool that is designed to make our lives easier.

I think we should be allowed to have some fun every once in a while, and this "gimme gimme gimme" easter egg is awesome.

It seems the maintainers didn't realize that this easter egg was affecting a command that was designed to have a predictable output so that is the real issue here. Just a simple bug. If this was output on some help screen or something like that then no one would be complaining.

View on HN

The exit value is always 0 regardless of what's printed on stderr. If code parses stderr to determine error state instead of looking at the exit code, then it's doing unix wrong.

Yeah, but you may be parsing standard error regardless.

If evaluating stderr, the first step should be determining if a line is of a known format before treating it as an input.

I'm not sure how well that'd work due to the lack of buffering. But I wouldn't want to go anywhere near stderr in production code.

BUT IT IS 12:30 AT NIGHT, THE CLIENT WAS PROMISED DELIVERY OF THIS FEATURE TWO WEEKS AGO, AND I CAN"T FIGURE WHY TF STDERR KEEPS OUTPUTTING GIMME GIMME GIMME!

Grep source code buddy.

This is a great example of a time when you should go home, get some sleep, and everything will work in the morning :)

Sometimes your servers are set to UTC.

"we are sometimes portrayed as snobby and entitled"

Huh? That's not at all the stereotype I see associated with programmers. More like the opposite. In fact, a gag like this is much more in line with the stereotype I'm familiar with.

Exactly what I was thinking when I read the stackexchange post. This is just enforcing the stereotype that programmers can't be taken seriously ("bro culture"?).

I wouldn't accuse them of being "brogrammers" though either. This just sounds like an appreciation for obscure references, play on words, maybe a bit of mild mischief? Not at all what I picture when I hear "bro culture". I'd call it "nerd humour" maybe (being a nerd myself, I feel like I can get away with the insult)?

Maybe command line tools should have a --no-fun flag to disable all easter eggs. I'm only half kidding. It could be undocumented, but at least it gives you a way to ensure consistent output for tests if you stumble into a problem like this.

It could just check if the POSIX_ME_HARDER environment variable is defined. http://wiki.wlug.org.nz/POSIX_ME_HARDER

I just don't see a reason to modify important program functionality for the sake of a joke. There are so many other ways to show a sense of humor without doing that.

Indeed and those ways have way less chance of causing accidental issues later down the road.

Same deal with profanity, excessive vulgarity or calling out named persons, etc. in error messages.

It's just unprofessional and it can cause all sorts of unforeseen "upstream" issues.

(Even really surprising things like profane class names can cause issues because of things like reflection, etc.)

The obvious counter to this is to ask what software you've written that many of us use several times a day, every day, and that you refrained from adding any humour to.

Free software almost always has the 'this is provided as is' caveat, and offers access to the source for you to review to ensure it's fit for purpose, so the whole 'This did something I don't approve of' complaint is a bit weak.

Further, the 'important program functionality' may not apply in the case of running the program in an atypical way - that is, without parameters - at a certain time of day.

Reply on news.ycombinator.com