Steve Yegge is an idiot July 28, 2010 | 06:42 pm

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.

  • rusty shackleford

    You are trying to correct the viewpoint that it is alright to have compilers make up for crappy programmers?

    That is quite the Java attitude you got there.

  • Robert Fischer

    No, but I like it when the compiler tells me that I did something stupid, instead of having that stupidity make it out into production. Unit tests can serve a similar purpose, but they’ve got the added burden of 1) taking me time to write; and 2) requiring me to recognize the potential stupidity in order to catch it. Ubiquitous and automatic stupidity-catching is much more useful. (And for the record, I’m very aware that there are other purposes to unit tests, too.)

    Consider this from On the Meaning of “Coding Horror”:

    YOU are the Coding Horror.

    The minute you realize that, you’ve crossed the threshold from being an amateur software developer into the realm of the professionals. Half of being a good, competent software developer is realizing that you’re going to make tons of mistakes. You will be your own worst enemy almost all the time. It’s a lifestyle. You’re living it right now. You, me, all of us. The problems start with us. We’re all coding horrors.

  • Robert Fischer

    And the point I missed was…?

  • Robert Fischer

    Compilers don’t “make up for crappy programmers”. They can, however, perform useful checks for common errors that all programmers make, crappy and otherwise.

    To out-of-hand reject a tool that can catch the errors you will make is just stupid: it’s sheer and utter denial about your fallibility as a programmer.

    To argue that compilers do more harm than good, that they require verbose coding, etc., etc., are all reasonable positions. To argue that you don’t need a compiler because you write perfect code? That’s just nonsense.

  • rusty shackleford


    You misunderstand simple points and reach for strawmen.

    Typical for amateur Java “programmers” that HAVE to rely on the compiler to save them.

    The Java compiler can not save you from NullPointerException or ClassCastException. It doesn’t relieve you from lessening the number of unit tests you need to write.

    It is a security blanket for crappy programmers who exclaim: “Why did my program crash? It compiled without complaint!”

  • Marcel Kincaid

    I’m making a guess here, but I think you’re an idiot. Of course Yegge’s post was humorous, but that doesn’t mean that it doesn’t reflect his views. It’s striking that there are people posting in Yegge’s comments section, and you posting here, complaining that this response took him seriously, when nearly every comment on Yegge’s post takes him seriously, stating how much they agree with him, or how they agree with him with reservations. The fact is that Yegge’s posts are not merely humorous, nor are they, as they are often mischaracterized, satirical: rather, his form of humor is mockery. His article makes fun of Java and its private and deprecated annotations. On the surface, his article is idiotic, as it fails to appreciate the value of static typing and other compile-time guards. He may know better, but those who say they agree with him do not.

  • Marcel Kincaid

    “Have you considered that perhaps Yegge knows this, and thinks it’s a better idea not to have “this method is private” contracts enforced by the compiler? ”

    It’s apparent that he does think that, which is what makes him an idiot.

  • Marcel Kincaid

    “The author was specifically targeting Java, which consists in forcing the programmer to declare properties that are superfluous 95% of the time and just clutter up the source code.”

    Java forces you to declare private and deprecated attributes? Really? And you think that’s what Yegge was complaining about?

  • Marcel Kincaid

    Yegge’s post is mockery that ridicules something quite reasonable by selectively attacking its misuse — and numerous people in his comments section have said, with little or no qualification, that they agree with him. It’s idiotic through and through and deserves to be called out as such.

  • Marcel Kincaid

    Yegge’s article was mockery not satire. Apparently, Alex, you’re too dense to grasp that Yegge’s post reflects his views, rather than being an inversion of them.

  • Marcel Kincaid

    Yes, it’s absurd, but it’s what Yegge really believes, and many of his commenters stated that they agree with him — thus, Brian Hurt’s article did not attack a strawman.

  • Marcel Kincaid

    That’s even dimmer than most of the other comments about it.

  • Robert Fischer

    Better type systems can save you from NullPointerException and ClassCastException. One of the things that annoys me about Java is how it’s got a ton of ceremony without actually helping you out too much. That said, your point stands in that there are problems the compiler can’t solve, and I agree that there is a lot of space in computer programming where good programmers have to step in. All the same, I’ll take the help protecting against simple issues if I can find it, since I am my own coding horror.

  • Marcel Kincaid

    Only the most stupid people think that “it was a joke” is an answer to the criticism of the piece.

  • Marcel Kincaid

    “Wow… I guess you Steve shouldn’t joke… some of his readers lack a sense of humour.”

    LOL! You seem to be a stupid git, yuk yuk yuk! This is just a joke (mocking you, you silly moron!!), so if you have a sense humor you should just laugh it off! Ha ha ha!

  • Marcel Kincaid

    “I never want to work with a team where the blame game is acceptable.”

    Which is why competent teams have the compiler prevent misuse with static typing, protection annotations, and so on, silly.

  • Marcel Kincaid

    I’ve been in this field since before you were born and I wouldn’t hire a fool like you, Russ.

  • Marcel Kincaid

    “That post was satire.”

    No, it was mockery, which is quite the opposite.

  • Sebastian


    Not sure if you read Umberto Eco’s Foucault’s Pendulum ? Eco has received hundreds of letters giving him tips and offering further support to the theories in the book. However, the book is a satire and depending on the viewpoint a mockery of these theories, but a really good one that can easily pass for the real thing – what you would call good written satire. Is Eco an idiot? I hope your answer is not yes ..

  • Pingback: Google Engineer disses Google+ | ZDNet

  • Pingback: Google Engineer disses Google+ |

  • Eco

    No, really, dude, you are one total idiot. That post is pure humor.

  • Jukka Hämäläinen

    Very humorous. And when after 5 years of living in your house you notice that there are not enough power outlets and decide to construct more of them, you can’t do this because the existing 220V wires are coated with adamantium and impossible to reuse. And of course the original builders of the house cannot do it, because they can’t be sure how other households would react to the change. 

    Moreover you would like to add more powerful flushing possibility to your toilet because you literally shit bricks, but as you contact the plumber he says the original contractor designed the toilet to be flushed by its current velocity and it cannot be changed because the pipes are also coated with adamantium and the water pump is buried under ten feet of concrete so you won’t hurt yourself… and moreover you are always nagging about this and that and anyways demanding too much, so why can’t you just be happy with the API the contractor designed? And you know you could be in real big trouble if you would start tampering with the pipes and wires, no matter how much education or experience you have! After all technology isn’t here to enable us to make things but to prevent us from doing things, don’t you agree? 

    So you decide to build another house next to your fully functioning old house just because you wanted your shit gone and some more electric appliances. But at least the contract stays intact, because it’s really for your best and because you fool don’t really know what you are doing!

    If you still don’t get it, Yegge isn’t implying everything should be straightly visible from the API (that is, he does not want the shit visible in his breakfast table). He is implying that Java is designed poorly because there is no way to use private methods, even if you are aware of the risks. These are two totally different beasts. Hiding things from the API is good thing as it keeps the API clean and clear, restricting the end user artificially is bad (I say artificially, because you can always copy-paste the hell out of the private methods as Yegge puts it).

    Private methods should not be visible in the API, but they should let you get around the restriction if you decide it is worth the risk to use them! The risk is yours as the end user, not the original author of the code! Moreover, the original author should not have a say in how you use the code, because, as said, it is not his risk, it is yours!

    The “private contract” should not be protecting you as the end user, it should be protecting the original author of the code by saying, “you carry the responsibility if you use this code”. Only now, for Java, it is saying “I decided you shall not use or need this code”. In the end it isn’t contract, because the original author is dictating the use case to the end user and end user can’t but to agree to this. It’s dictatorship, not contract.

  • Bill

     If NullPointerException has been eliminated why is it still in the API?

    I will answer it for you: because the crappy java static type system can not make any guarantees that the pointer(*cough ‘reference’) can not be null.

  • Billy

     Ruby always returns the last expression evaluated in a method. Easy peasy.