Thanks, much appreciated! (RuboCop's author here)

Yeah, you're right. I was triaging and cleaning up the open issues prior to launching the new site.

Now that the guide has more editors I'm optimistic that we won't end up in a situation with that many non-triaged tickets down the road.

Then is also a keyword. :D

As for hash literals - I didn't like the addition of the new syntax simply because it's limited to one type of keys. We had a perfectly good universal syntax and introduced a second one just to save up on typing in one common usecase. Not to mention that in the 1.9 syntax you don't use keywords directly but labels, which are different syntactic construct (:keyword vs label:). I think I understand your perspective, but it seems you value typing less and subjective aesthetics and I value mostly simplicity (minimalistic syntax and uniformity being some of its key aspects).

Sorry, reread your comment a couple times, and I still don't understand what you mean by the 1.9 syntax being a label. The keys in `{ key: 'value' }` and `{ :key => 'value' }` are both Symbols.

You've missed my point about `&.` (probably because I didn't provide much of an explanation) - it's fine in certain cases (your example is a good one), but it's also something that can be easily abused. Very often I've seen people use `&.` even for methods that can never return `nil`, which is confusing for people who read their code. I've also seen plenty of methods which could have returned a en empty collection on an empty string that return a nil for no good reason, but it's easy to deal with nil now, so why bother to think carefully... Every feature that promotes sloppy APIs nil is a potential liability and should be used carefully.

Well, I'm sorry if it seems to you like this, but there were plenty of features I didn't like in the past as well. :D I just felt that recently things took a turn for the worse. Language design doesn't get easier with time - quite the contrary, because your options constantly shrink.

If that's your only take away I guess I've failed to communicate my points.

Yeah, that's right. Unfortunately different people put different meaning into "static analyzer". Obviously linting is also done via static analysis of the code.

RuboCop's author here. If I knew someone would ever link to the homepage I would have put some useful info in it. :-)

Thanks for the kind words!

P.S. There's a lot more info here https://github.com/bbatsov/rubocop

bozhidar also is the maintainer of CIDER [1] for Emacs + Clojure. It's the most popular way to use Clojure.

[1] https://github.com/clojure-emacs/cider

Guilty as charged. :-)

There's still debate on this (https://github.com/bbatsov/clojure-style-guide/issues/44). It's the suggested style mostly because Rich (Clojure's creator) promotes it.

There's similar advice in the Ruby Style Guide - https://github.com/bbatsov/ruby-style-guide#no-comments

Comments often go out-of-sync with the code, so I think it makes a lot of sense to prefer writing comprehensible code instead of trying to explain with comments something totally incomprehensible.

It's weird to me how people will slate low quality code, but think it's okay (or inevitable) to let comments go out of date. If your comments aren't useful, delete them. If they are, keep them up to date. It's part of behaving responsibly towards the rest of your team just as much as writing readable code is.

Not having used Android 4? As noted in the article I installed it manually on my Xperia Arc (CyanogenMod)... I've also played with Android 4.2 quite a lot - but then again that was not the point of the article.