emu

The majority of comments on this post are of the form "his analysis is wrong, because it doesn't take into account factors x, y, and z". That's great --- we're having a civil discussion about the merits of his argument.

Linking to his blog post in this way is tantamount to implying that the commenters on this thread are "complainypants", which I find quite rude. If that wasn't his intention, then he certainly could have done a much better job communicating it.

(This is my last post on this topic.)

Wow. After reading this I would downvote this article if I had downvotes.

The author of the article completely ignores public transit. Commuting by train has at least two advantages: (1) it (can be) cheaper than driving, although the exact economics depend on a lot of things, and (2) you can do something else, such as work, during the commute time, so it need not be wasted time.

Also, commuting an hour to a job sure beats not having a job in the same state as your significant other (my situation). I'm looking forward to moving to the same place and commuting soon. Commuting sucks, but you're optimizing for many things when choosing where to live, not just commute time.

To echo one of the comments on the linked post --- it is because of bugs like this that I am a firm advocate of languages with strong static checks.

A few claims: * no matter how good a programmer you are, you will make stupid mistakes (such as typos, as in the case of this article) every now and then. * it is statistically inevitable that you will make many such errors in a large code base. * bugs are easier and cheaper to fix the earlier you catch them; the best time to catch a bug is before the code is paged out of a programmer's brain. * it doesn't take too many experiences of discovering a typo bug in your "production" code base before you realize there must be a better way.

My personal approach is the following: * restrict the use of untyped scripting languages to pieces of code that can fit in one screen or so; that is, just small enough that you can keep all of the moving pieces in your head at once. * as much as possible, use languages and tools that provide strong static checks for larger projects. This includes language type systems (e.g., Scala, OCaml, Haskell, etc.) and tools that help you check your code (Prefix/Prefast, Coverity, Findbugs, etc.) * testing is good, but static checks are far better.

Unfortunately these opinions don't match common practice in the web programming world.

This pattern is sometimes called an intrusive data structure. For example, see boost::intrusive in the C++ world. It saves allocation, gives better locality, and allows various optimizations such as the ability to remove an object from a doubly-linked list in constant time.

Another way to think about all the offsetof() stuff is that it's emulating multiple inheritance in C. You can think of structures as inheriting the "trait" of being a participant in a container; the "pointer-arithmetic-and-cast" idiom to move from a container entry to the corresponding object is isomorphic to downcasting from the trait to the object that contains it.

Interestingly it is not possible to express this pattern in a generic way within Java's type system.