I quite like AppCode, not for code formatting perse. More because it has decent refactoring support, better code analysis+quick fixes, and very keyboard friendly. I still miss the storyboard support though. I do come from a Java background, using Eclipse and IntelliJ. XCode was a bit of a disappointment coming from there.

If you are willing to switch IDEs, then AppCode can do this. (+ clean up your unused imports). There is currently a bug in formatting Kiwi specs, but is marked as fixed in upcoming build.

I don't understand his point on encapsulation of information versus implementation. If anyone can help me here, I would be grateful.

* Should the user of your object/data have to make this distinction? Does he care if age is a piece of data or the result of a calculation?

* Should the user of your object/data know where a piece of information is? Suppose I start of with having a birthdate attribute in my person hash. I later read something about CQRS and decide to build my person as an event store. My birthdate is now in some event hash inside an events list in person. If I encapsulate this birthdate information, the users of my object/data don't have to change.

Encapsulating information/implementation might "complect" person, but doesn't it make it a lot more simple for the users/callers?

The point of testing/TDD for me is not (just) about preventing bugs, it is more about having quick feedback. Running a test is faster than waiting until it is deployed and manually clicking around in an application. It is kind of comparable to using a REPL.

Honestly, I hope there isn't immortality in heaven beyond the grave. Forever is a really long time. The first 1000 years in heaven might be interesting. The billion years after that? meh

Heaven does seems rather boring. However if we allow ourselves more creativity than scripture, we don't need to assume that eternal life must be dull.

http://lesswrong.com/lw/xy/the_fun_theory_sequence/

I honestly thought the elisp example code looked pretty bad as well. I don't like the flag-style programming (in-for, continue, destructuring) nor do I like the meaningless names (tt, s, init, continue, js2-lb,..). That one function also has quite a lot of responsibilities (looping while you see commas, error handling, handling simple, destructured and in-for vars,..)

The idea is that using IDs reduces the reusability of your css rules.

According to that benchmark native Object.create is faster than constructor functions on Firefox 4.

That said, I wouldn't base my coding decisions on those kinds of micro benchmarks. They say nothing about the impact on actual javascript applications. Using new instead of Object.create may prove completely irrelevant in an application where you are constantly updating the DOM or are doing lots of network calls.

Object.create is a standard function in ecmascript5. I would add a check such as "if (!Object.create) {Object.create = ... }".

The dose is discussed in the article. The hypothesis is that 90 pounds of added sugars per person per year is toxic (current levels of consumption). 40 pounds per person per year is supposed to be ok.

It does not say that 40 pounds per year is OK. It says that there is no evidence that 40 pounds per year is not OK.