4 ms·

Thanks. I’ve definitely ‘read’ things like both those ‘cat’s in the past. Even the GNU one is still small enough to be understood. I agree with what you said a

by jrmg 3y ago

Thanks. I’ve definitely ‘read’ things like both those ‘cat’s in the past. Even the GNU one is still small enough to be understood. I agree with what you said about larger projects and the intent behind ‘reading’. Linus’s opinion is interesting. I wonder how it’s changed over the years. I share his disdain for operator overloading on a visceral level, but to be fair it’s not much different to method or function naming really - those can end up misleadingly similarly named in large code adds too.

mbivert 3y ago
I guess we can put things this way: the closer the codebase is to a collection of uncorrelated chunks, the more one can read it "systematically". OTOH, the more the dependencies between the various chunks, the more useful/efficient a "reverse-engineering reading" becomes. "Bad" naming, operator overloading, both add such dependencies. As a side note regarding operator (well, symbol) overloading: it's just plain awful in mathematics: e.g. a "+" signs can refer to an actual operator between scalar, between vectors, between functions, between spaces, an essentially syntactical element (portion of a name), etc. It makes simple things so hard to understand for novices.