Hacker News new | past | comments | ask | show | jobs | submit login

See the recent thread on HN, one writes a useful tool, gives it away, top voted comment on HN is a sniping comment about code style.

Rather than just an echo chamber of praise? It's good to see multiple points of view and criticism. There's always a place for improvement, and he's right, the codebase doesn't seem particularly ruby-ish.

I was at an academic conference recently where an researcher I respect was talking about paper reviews at a top journal much the same way. His point, if I can attempt to do it justice--was that we sometimes get so caught up in proposing ways to "polish the diamond" that sometimes we forget that it's a diamond we're polishing. Some things are good in their own right, and while yes, they are likely improvable, we as "reviewers" don't usually offer enough recognition of the submission's value, or do it only in a token way in order to excuse the criticism that follows.

The researcher used as an example a recent submission with a novel research method. The other reviewers were caught up in the minutia of the paper, and missed the forrest for the trees: the method itself was more than a worthy enough contribution to the field to be accepted, and they were arguing about significance of the results. Over the course of the next couple of review rounds, this researcher's focus shifted from reviewing the paper to defending it to the other researchers. In the end, after multiple rounds (and likely a couple of years), the vote was 2-1 to reject. At this point the Senior Editor stepped in and published the paper without further revision.

Do we do the same with submissions here?

That conversation was hit me pretty hard, and I hope it will change the way I review.

Honestly, does it matter? Do I have to always code in "ruby-ish" while coding in ruby. What should take more preference? Solving a problem or maintaining "ruby-ish", "python-ish" idioms. Besides if the author feels that he can maintain his codebase this way then I don't see any problem in it. I also do not like tone of trashing vagrant just because it's code base is 'shitty'. Vagrant has been godsend for our office synchronizing configurations across multiple machines. It may be easy for some geeks to create a development system using seven command. But there are people who aren't bothered or have less time digging very deep into every documentation on earth. They want to quickly find a base solution for their problem which they can tweak to their need. Vagrant solves problems for those people perfectly.

I don't see any mention of 'shitty', just over-engineering. For the record, I would use Vagrant if I had the need, and probably will in the future (this kind of caveat seems sadly required otherwise I would be painted as somehow opposed to a software project), that said..

Fitting in with the community style/idioms is rather important for a project, especially as it grows in size. When it's a huge codebase, used by many, in many different use-cases, people being able to look into the code to help sort out their own issues is hugely valuable. If someone who knows your programming language and knows your problem domain gets scared off by how your software is architectured/functions, that's not a particularly good sign.

But maybe the problem is huge, and all that complexity is needed, and will pay-off now they're looking to have multiple VM providers. But criticism of complexity shouldn't just be tossed aside as 'trashing'.

"Besides if the author feels that he can maintain his codebase this way then I don't see any problem in it."


If that is the only factor, it might have as well been closed source.

That doesn't follow at all. You can still fix bugs in open source programs, even if you disapprove of the coding conventions. It's only equivalent to closed source if you're irrationally attached to a particular style.

But now it's followed by an awesome reply by the author where I actually learned something!

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact