Steve Yegge is an idiot

And to think, I used to have respect for the man. Then he goes and posts this pile of fetid dingo kidneys.

I’m going to explain in detail why ditching private (and, by extension, public) is bad. Obviously this needs to be spelled out, because a lot of programmers- including Steve Yegge – don’t get it.

Consider a software project that is large enough that a) more than one person is working on it, b) code maintenance is ongoing, and c) large enough that no one has the whole program in their head all at once. Person A writes hunk of code (function/module/class/whatever) X. Then person B comes along and writes hunk of code Y that calls hunk of code X. Then person A comes back around and changes hunk of code X, breaking hunk of code Y in the process. Who’s fault is it? Person B can claim that since their code worked with the older version of X, it’s person A’s fault. But person A can claim that module Y should never have depended upon that particular behavior in the first place.

Every time you have one piece of code calling another, there is a contract between the two pieces of code. The contract may not be automatically enforced, may not be spelled out, may not even be articulated, may just arise out of convention, but it’s there all right. The contract is what determines, in the above example, who fixes their code- person A, or person B. Unless that is resolved by invective duels at thirty feet.

Renegotiating the contract is possible, but is often expensive if the called code wants to change it’s behavior or API. This is because all the code that might call the changing code has to be found, inspected, and probably fixed to support the new behavior or API.

This is where the whole private thing comes in. It’s explicitly spelling out what is, or is not, in the contract. A function marked private in Java means that there is no guarantee that the function will have the current behaviors, or current arguments, or even still exist, in future changes to the code. If you call the function from your code, your code will break. It’s a question of when, not if. And when it does break, you will get no sympathy from me.

Note that it is possible to have contracts without (computational) enforcement. It is possible to write working, maintainable code in languages without a compiler-enforced private. But this just means that the contract is expressed in other ways.

In fact, most contracts are not expressible as automatically enforced in most languages, even languages with advanced and powerful contract checkers (aka type systems) like Ocaml and Haskell. There is a subtle difference between accidents of implementations and guaranteed behaviors. Consider, for example, a function that goes out to a database and fetches a list of strings. Now, due to the nature of the data in the database, and how the database decides to execute the query, current the strings are being returned in sorted order- but is this an actual behavior guaranteed to continue to be true, or is it just an accident of this implementation, and in a different circumstance (different data, different query plan), the list of strings might be returned in a different order? I could easily see the answer being yes (how hard is it to drop an order by onto the query?) and equally see the answer being no (the extra sort phase has a significant cost and serves no purpose for most uses of the data, and how hard is it to throw a sort call around the result of the function in those cases that need it to be sorted?).

As a side note, this is the reason I disbelieve that you don’t need comments. Even unit testing doesn’t help here. All unit tests tell you is that suddenly the list of strings is coming back unsorted, and thus someone’s code is broken. It doesn’t tell you whose. The only real solution here is for the developers involved to get together and work out which it will be, and then write the decision down. If you don’t write it down, it didn’t happen (“That’s not what I remember…”). Oh, and if you’re unwilling to up arrow a couple of lines and fix the comment while you’re changing the code, what other dependencies are you not maintaining? Maybe telling other programmers that you broke their code? Or checking and fixing their code for them? But that would require editing a completely different file, and we’ve already established that you’re unwilling to fix something half a dozen lines up in the file you’re already editing.

So not all contracts can be expressed and checked automatically. But why on earth would you not use the features of the language you do have to check the contracts you can check? The answer, I think, is quite clear- Steve Yegge doesn’t believe in contracts. Or at least doesn’t want them to apply to him.

There is an attraction to coding without contracts, to just hauling off and writing or changing code, without caring about the consequences. Short term, it greatly increases (perceived) productivity. Long term, however, that productivity drops off enormously. So, I’m writing code with Steve Yegge. And, to eliminate some code duplication and make some other code easier to read, I create a function. This function really isn’t for public consumption, just something internal. But now that I’ve created it, it’s part of the API. If I change how it behaves or even want to remove it later, I have to carefully check all of Yegge’s code. Because, dammit, if I didn’t want him calling the function I shouldn’t have written it.

We have names for people who don’t care about consequences, or don’t think long (or even medium) term. We call them “immature”, even “childish”. We also have names for code bases that are hard to change because of uncontrolled dependencies between modules- we call them “brittle”, or even “unmaintainable”. The end result of an utter lack of contracts is the big ball of mud.

There are projects where this isn’t a problem. Small, short projects with limited life spans, and few developers (or just one). But then there projects, lots of projects, which aren’t this way.

I’d also like to take this moment to mention that there is nothing in this whole discussion special about open source. You are free to fork any open source project you want, and remove all the private specifications you want. But the original project maintainers don’t have to accept your changes back into their version. And they probably wont, and maybe there’s a damned good reason for this. If anything, this problem is more pronounced in the commercial, non-open world. An open source project is always free to decline an offering of code, and often does. A commercial project finds it much harder to reject code contributions from

There is an old programmers joke, which goes like this: programming is like sex. One mistake, and you’re supporting it for life. Steve Yegge doesn’t believe in (software) condoms- he doesn’t use them, and thinks you shouldn’t either. At which point, the only conclusion I can draw is don’t use Yegge’s code, and don’t let him use your code.

No related posts.