The first thing to remember is that the main difference between what we did to Hiroshima and Nagasaki and what we did to Tokyo, or what Japan did to China (see “The Rape of Nanking”) or the Philippines, or what we did to Dresden, or what Germany did to Coventry or Leningrad or Moscow, or what Russia did to Berlin, etc., etc. was how cheap it was. One plane. One bomb. Prior to that time it tooks thousands of men to utterly destroy a city and kill all or most of inhabitants. Dresden, for example, took 1,300 heavy bombers, many of whom didn’t make it back. But despite the cost, Tokoyo and Dresden and Nanking and Coventry and Leningrad and all the rest happened anyways. It was a time of horrors.

And maybe Japan would have seen reason, had we nuked a mountaintop instead, say, or an atoll (as PZ Meyer suggested). Or, perhaps not. We can look back now, with out comfortable seat here in the 21st century, and say with perfect hindsight that Japan should have immediately realized the consequences and implications of nuclear weapons. My experience is that people don’t learn that fast. A miscalculation on the Japanese response to a demonstration means either we end up vaporizing more cities or we invade Japan- which would millions of American dead, who knows how many Japanese dead.

Yes, there is blood on America’s hands. Hiroshima and Nagasaki were great crimes. But this is the first thing we forget- that is what war is. A great crime. Innocents get killed, generally in even greater numbers than the guilty are killed. Blood is spilled. It is not noble. It is not heroic. The only times it is remotely justifiable is when the greater crime is to not fight the war. At it’s best, at it’s most righteous, most clean cut, most honorable, it is the decision whether or not to kill hundreds of thousands of people to avoid the possibility of having to kill millions. There is no good here, only varying degrees of bad and worse.

Part of the problem is scale- one person dead is a tragedy, a million dead is a statistic. So narrow the focus down, from the statistic down to the personal again. This is what it means to go to war: There is an eight year old girl. Picture her. Big eyes, dark hair, she loves her doll, her comfy blanket, and sweets. And oh yeah, Mommy and Daddy. She thinks boys are icky, and isn’t sure about school (she’s somewhat shy). War means she’s going to have her guts blown blown out. She’s going to die in excruciating agony, her dying gurgle chocked off by blood. And her father is going to get to hold the bloody hamburger that was his daughter, in the burnt out ruins that were their home.

That is war. Fix that image in your mind. That girl, she lived in Hiroshima. And Tokyo, and Dresden, and London, and Berlin, and Leningrad, and Moscow. And Korea and Viet Nam and Afghanistan and Iraq. In every war humans have ever fought, back to the dawn of time, little innocent eight year old girls died. And boys, and women, and old people, and innocents of every stripe. This is the cost of war, and it’s true nature.

So, on this date, the anniversary of an act of war only significant because of a technological advance, I hear the war drums starting again. When you tell me “we must go war”, this is what you are advocating- you are saying “we must kill that innocent eight year old girl.” This time it is Iran, last time it was Iraq. The only thing changing is which eight year old is killed. I must ask- is the goal we seek worth the cost? Is there no other way to achieve that goal other than ending an eight year old girl’s life in a paroxysm of blood and pain? Sometimes the answer is yes (I think Hiroshima was one of those times). But most of the time, all most all of the time, I find the answer is a definitive no.

“Never again”- I like the sound of that. But “never again” will only become a possibility once we start to remember the true nature of war. By singling out Hiroshima as something exceptional and noteworthy, as opposed to normal for war, he is (unintentionally, I’m sure) encouraging the very amnesia which allows for the crime to be replicated. All we have to do, according to this logic, is not nuke Tehran, and going to war isn’t that big of a crime. No, Mr. Meyers, it is. That eight year old girl, and her father holding her bloody remains, do not care if the bomb was nuclear or conventional. The technology does not matter.

So, by all means let us take this day, August 6th, to remember the true cost of war. And also Feburary 13th (Dresden), and December 13th (Nanking), and…

Comments

• August 8, 2010, Robert Fischer wrote: The basis of integrative power (nee principled nonviolence) is bringing the truth of the situation—most especially, the truth of violence—to the fore. Astoundingly, confronting people with the truth of the situation works to stop violence. This is why you have groups like Nonviolent Peaceforce who do third-party nonviolent intervention: it works quite well, and it is more lasting and cheaper than the violent alternatives. Part of the proof about how well integrative power works is the secrecy which war requires. War, at least in a democracy, requires the civilians to not be able to see the consequences. We can't see broken soldiers in our streets. We can't see coffins coming home. We can't see military plans or military actions. We can't see the people we are attacking. We can't even talk to them. Because if we did, the illusion of the abstract war would collapse, and it would be all over. The question that bothers me is why, since we have seen this proven out integrative power in conflicts big and small, we are still left in the dichotomy of doing nothing or going to violent war. Why are the only choices presented to us lose and lose?

(Digital Fingerprint: bcecb67d74ab248f06f068724220e340 (74.125.156.81) )

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.

Comments

• July 28, 2010, David Clark wrote: So if you are writing Java code, are you also going to unilaterally disallow reflection (since it can access private stuff)? If not you are still going to have to go through the code to look for reflection based access of your code. You are also going to have to disallow groovy from ever touching your Java code because that can also access private stuff. There's probably at least 6 other ways of doing this. Private is nothing more than an comment which says, "Don't use me unless you are going to take full responsibility for what happens now and in the future." And that's Steve's point, we're adults and we can figure that out for ourselves based on our own particular use cases and ability levels.
• July 28, 2010, Robert Fischer wrote: Note that removing the @Deprecated tags, which Yegge makes fun of, is super crappy. If you want to use a deprecated API, then you should be happy for @Deprecated---those @Deprecated tags exist so that the library STILL WORKS FOR YOUR CODE. If it weren't for deprecated tags, the API would be broke sooner and you wouldn't have been able to upgrade to the newer version of the library without going through all your code and fixing the ways the calls work. How about a little gratitude for the work saved by API stability? As for "private" methods: if you want to call that open source "private" method so badly, go copy-paste it into your own code somewhere. It's open source, so nothing is stopping you. Yes, copy-paste has a bad rep, but guess what: when the library goes and changes its implementation or API, you'll still have a version of the call that works. And they will be changing their implementation or API, because that is why it is private in the first place.
• July 28, 2010, Robert Fischer wrote: Are you saying that "private" is bad, and everything should just be "public"? If so, how would you figure out what's subject to change and what isn't without some kind of marker?
• July 28, 2010, Rob wrote: I'm making a guess here, but I think that Yegge's post was meant to be a joke.
• July 29, 2010, Bill Mill wrote: > And to think, I used to have respect for the man. Then he goes and posts this pile of fetid dingo kidneys. 1. When you've respected a writer for a while, then you read something he writes that seems totally wrong, perhaps you should wonder if you missed the point. > Consider a software project that is large enough that {blah blah blah reason for why "private" exists} 2. Do you truly think that Yegge couldn't write out the case for private in this manner if he wanted to? Do you think you're introducing new information into this debate? > 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. 3. 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? Your tone of arrogance is out of the ordinary. (My response's tone of arrogance is a response, for which I apologize but will not change) > Steve Yegge doesn’t believe in (software) condoms- he doesn’t use them, and thinks you shouldn’t either. You have mistaken the part for the whole; Yegge's disbelief in one particular type of "software condom", as you so delicately put it, does not mean that he believes there should be no contract enforcement by programming languages.
• July 29, 2010, Martin Jambon wrote: I don't care much about what the author thinks or whether I approve his life choices, but I like the idea of keeping things simple by default. 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.
• July 29, 2010, Richard Vowles wrote: @BillMill - Steve compares software to a house - he deserves all the slapping he gets everywhere around the web and more. I suppose when Steve says design by contract is a bad idea you are going to say "hooray" to that as well. Try not to drink the koolaid - I generally find Robert gets a bit too antsy in his postings but he is right on the money here. Yegge deserves a good kicking.
• July 29, 2010, Reg Braithwaite wrote: Speaking as someone who respects your POV as well as Steve's, I feel that the tone of this particular point doesn't mesh well with the tone of Steve's post. Steve's post is humour. It takes an extremist stance, but most humour has to do that to make you laugh, and then think. Does Steve not wear condoms? I dunno, it could be that he doesn't sleep around. It could be that he uses other techniques to create encapsulation. It could be that he uses private members and simply wants the reader to appreciate the fact that private is not "free" and the benefits should be weighed against the costs for the generations of maintainers to follow. :-)
• July 29, 2010, Robert Fischer wrote: To everyone who is saying, "Hey, it's just a joke!" — yes, it is. But it's a joke which argues for a particular position and satirizes its detractors. Jokes can be arguments, too. I mean, this certainly was a joke and pretty much in the same way, but people (rightly) saw the argument within it.
• July 29, 2010, Robert Fischer wrote: For the record, this is Brian's post, not mine. Although we both are basically coming from the same place in this point.
• July 29, 2010, Robert Fischer wrote: There's a joke in here somewhere about software condoms and taking all the fun out of it...
• July 29, 2010, Aaron Davis wrote: Did you actually read the article? It reads like an Onion article. The content is completely absurd. Everything you say about `private` and `@Deprecated` is correct, but this article is the definition of attacking a Strawman. But then, maybe you know this, and this post is meant as a joke as well.
• July 29, 2010, Philip Rhodes wrote: I took Yegge's post more as satire directed at Wikileaks, than as satire directed at "private" and "@Deprecated."
• July 29, 2010, dan wrote: Whooooosh! Wow.. did you hear that? The sound of Yegge's article going waaaay over your head! I'll spell it out for you: J. O. K. E. Yegge was poking fun at open source, at java and at people like iphone (selling you a house with doors marked "employees only").
• July 29, 2010, Joe wrote: Wow... I guess you Steve shouldn't joke... some of his readers lack a sense of humour.
• July 29, 2010, Judd wrote: No, he's saying that "private" IS the marker. You just have to see it as such and not mis-construe it as some barrier that will reliably prevent third-party code from calling it.
• July 29, 2010, Jeremy Bowers wrote: Here's the thing: Of the dozens of languages in current common use, quite a few of them do not spell out private and public and so on. All of them have been used to write large projects and indeed entire sub-ecosystems, which have most assuredly had to solve many software engineering problems just to exist. If you don't know the answer to that question, you're not in a position to be lecturing anyone on the pros and cons of this technique vs. the techniques you apparently don't even know about, so how can you possibly explain the pros and cons?
• July 29, 2010, Alex Gordon wrote:

  But it’s a joke which argues for a particular position and satirizes its detractors.

  That is pretty much the definition of satire. I'm pretty sure Steve Yegge knows why access modifiers exist in Java. All this article proves is that he's really good at satire.
• July 29, 2010, Patrick wrote: While I will decline to comment on Yegge, I believe you are muddying the issue by mapping public vs. private onto contracted vs. uncontracted. You're mapping a desired result onto an existing keyword with little regard to the intent of the keyword. There are more reasons to make a method public than to make it contractual. For instance, you may simply have another object in your code that needs to call it. I suppose one could argue that this is an inter-object contract, but you seem to be talking more about API level contracts which is usually where things break down when code breaks between programmers. Perhaps we need an annotation that means contracted? But then what does that really mean? It comes down to documentation. I know of at least one project that did this. They had a published "public" API that they contracted would not change and then another "private" API which was use-at-your-own-risk. They did this independent of object level visibility. In fact, their documentation generating tool hooked into their annotations and only published the public API to users.
• July 29, 2010, Jeremy wrote: :) Thank you for writing. I don't like your first example.

  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.

  Ok I am envisioning this project. I am also envisioning it has - Project Design Docs - Logical Layout - Diagrams and Models - At least Class level Documentation - Revision Control - Testing - Automated Builds

  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.

  Oops!

  Who’s fault is it?

  It depends, but it's not about blame. Person A's Fault - If He changed his public interface. Ya know, the one that was documented and spec'd out. - If he ran the test suite, saw failures, and still checked in his code. Person B's Fault - If he used undocumented features ( this includes playing with the private vars ). - If he made ASSumptions that were not in Person A's documentation... like the order of the returned data. - If he wrote bad tests, or heaven forbid didn't write any tests.

  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.

  I never want to work with a team where the blame game is acceptable.
• July 29, 2010, steven wrote: i thought the removal of private markers was a joke? your telling me he was serious?!
• July 30, 2010, James wrote: Yes, Steve's article was written in a jocular fashion. But you people berating Robert for not getting the "joke" post are missing the implication of what Steve wrote: That hiding too much implementation in private state or behavior is something he considers harmful. And Robert is disagreeing with that. Reading comprehension. Hard, I know.
• July 30, 2010, Donal wrote: The title of your article does you no favours. Does the guy really deserve to be called an idiot just because he wrote one (obviously tongue-in-cheek) article that you disagree with. Considering his entire body of work, do you really think Yegge is an idiot. I don't, and I don't think you do either. If you want to troll, try 4chan.
• July 30, 2010, Christian Romney wrote: > Who’s fault is it? The one who didn't write good tests. > The contract is what determines, in the above example, who fixes their code- person A, or person B. I don't like developing software in your world. On my planet, we believe in collective code ownership. Oh, yeah, and we *talk*. > As a side note, this is the reason I disbelieve that you don’t need comments. The distinction between function fetch_sorted_names() vs. function fetch_names() seems pretty clear to me, without comments. > Even unit testing doesn’t help here. Actually, it does. If the strings are supposed to be sorted I sure hope you have a test that expresses that. Otherwise, you're right - you're relying on happy chance. > If I change how it behaves or even want to remove it later, I have to carefully check all of Yegge’s code. No, the broken tests do that for you. > Because, dammit, if I didn’t want him calling the function I shouldn’t have written it. Exactly. So, you're advocating that two functions in the same class shouldn't reuse internal methods of that class when they both need its exact output? It this anti-refactoring?
• July 30, 2010, Scott wrote: Arguing that using "private"- a built in language feature- is heavy-handed and instead code should simply be documented and tested to the ninth degree paradoxically implies that coders too whiny to use "private" will document and test code to the ninth degree.
• July 30, 2010, Michael wrote: "So if you are writing Java code, are you also going to unilaterally disallow reflection." y-e-s. And there is also the middle ground where you don't allow _unsafe_ reflection.
• July 30, 2010, Derrick wrote: With that said... I can't stand it when people use private when they really should not, just because they were taught they always should! When you're writing high performance apps, such as games, which need to access x and y coordinates a LOT, you are DEFINITELY better off leaving them public. If you have

    private Integer x;
    private Integer y;
  

  with public getters/setter which do nothing but set the value:

  public Integer getX(){ return x; }
  
  public void setX(Integer x){
     this.x = x;
  }
  

  You're doing absolutely nothing but adding a LOT of overhead. In a minute of gameplay, at 60 FPS, you've just added 7200 function calls worth of overhead. I see people do this same stupid thing in AS3/Flash based games. There's a BIG difference between an API, and a contract, and a simple sprite with an x,y. Generalizing, and saying that everything should be "private" is also just as silly.
• July 30, 2010, Mike Jennings wrote: "If I buy you a house and put the title in your name, but I mark some of the doors 'Employees Only', then you're not allowed to open those doors, even though it's your house. Because it's really my house, even though I gave it to you to live in." Actually, no. It's more like, if I build a house and then give it to you, and if I built the house well, you won't have 220V wires sticking out of the walls. Nor will the ABS pipes that transfer the shit from the toilet be visible from your breakfast table (nor will they be transparent). I am well aware that there is a black, 3" ABS pipe shuttling turds 3 feet from my breakfast table, I put it there. But I like the ABSTRACTION of "I shit upstairs and the shit goes somewhere". Yes, I could have a clear pipe visible from my breakfast table - it would show me if there are any blockages, it might even give me a hint if someone in the house has serious medical difficulties or if someone has flushed a kitten down the bog. Further, it would allow me to easily hook up a "Y" from that pipe if need be, cuz everything's accessible, but someone with a slightly more refined aesthetic sense, like my wife, might object. Abstraction is a game of make-believe; I might have some code that takes an InputStream but all I ever pass to it is a FileInputStream, so why fuck around with InputStream? You know that it's a FileInputStream, so why not call a spade a spade? The reason is this, most programmers don't have very much discipline. If you change your code to accept a FileInputStream, there will be an almost irresistible temptation to use stuff that only a FileInputStream has. Now you can never use that code on an URLInputStream or a ServletInputStream or any other InputStream; you've broken the abstraction, when you didn't need to. Although Steve is probably joking about not understanding the need for access modifiers, that's my own opinion on the matter.
• August 2, 2010, Chau wrote: Wow. Just, wow. First, I didn't see anywhere in there where Yegge said he was against all such forms of communication. In fact, he pointed out how Python has a convention for indicating this *without adding any syntax for it*. It works *really* well. Second, if programming is like sex, then trying to get the compiler to enforce everything is like preaching abstinence: it sounds like it should yield perfect results, but in practice it ends up being far worse than giving people good tools and teaching them to be responsible for what they do. The static-typing people love to think the compiler can catch anything. (Including bugs, often! Ha!) In a dynamically typed language, when's the last time I had an interface change such that it compiled but didn't work? I write code in dynamic languages every day and I can't remember the last time this happened to me. When's the last time I wanted to get around a "private" declaration? I also write in statically-typed languages, and the answer is: a couple times this morning, already. I've even had (a week or two ago) a library change implementation without changing interface, thus causing statically compiled code to stop working. Of all the things that can go wrong when 2 pieces of code meet, things the compiler can catch (having the method names and types line up, and only using methods marked "public") are responsible for *way less* than 1% of problems. When you grab the new version of that library, you still have to test, and you still have to read the docs -- and if you're doing that, then what good does it do that the compiler tells you something is marked "private"? "But why on earth would you not use the features of the language you do have to check the contracts you can check?" Because they cost more than 1% of my coding time, and the payback is way less than 1%. It's the same reason you don't spend all day writing your own *extra* lint-like tools to find potential errors (and I have written such tools, and found bugs with them): again, they take more time to write than just testing the damn program normally, or getting your coworker to give it a 2-minute code review. Inefficiency. It says far more about you than it does about Yegge that the only response to this you can think of involves calling him "childish" and "immature".
• August 2, 2010, Robert Fischer wrote: Uh, again, it's not my post. It's Brian's. I need to start putting the author's name in H1 tags or something...
• August 2, 2010, Robert Fischer wrote: Not sure if you're responding to my comment or Brian's original post, but here are my thoughts. A lot of languages use other kinds of markers (e.g. _foo). They have long-established conventions. And if you want to have a language with such a convention, that's fine: in that case, you're in buyer-beware territory if you reach into the code marked by those conventions. And that's okay, I suppose. Simply ripping private out of Java code is a problem, though, because you're dealing with a language without a convention for communicating that information. And ragging on @Deprecated seems somewhat bizarre. As a further comment, in languages like you have described, I have encountered substantial and annoying difficulties in upgrading libraries with surprising changes to the API—or even not even being clear what is or isn't part of the API. perl (and by that, I mean CPAN) deals with this by having a culture of obsessive documentation. Ruby's been a source of some frustration for me on this point. This is also true of some Grails plugins, and I've had people raise that issue about my own plugins.
• August 2, 2010, Robert Fischer wrote: Oh, sure. If the security of your system depends on not calling private methods, you're toast.
• August 2, 2010, Robert Fischer wrote: Yeah, there's a lot Java needs to do to make code cleaner. Why it doesn't have a C#-style (or even a Groovy style) properties syntax is beyond me.
• August 2, 2010, Robert Fischer wrote: Sure. So it's not unreasonable to respond to the target of satire, in that it is arguing for a particular position. Brian's original post may be a bit more harsh than I'd probably go for it—and certainly Brian's got a stronger take on the compiler's role in enforcing code contracts—but responding to the implicit argument of the satire seems very reasonable. Even if it is a joke.
• August 2, 2010, Robert Fischer wrote: Have you actually tried those out on the JVM? I bet if you're doing 7200 calls, the HotSpot compiler has optimized them to within an inch of their life, and so the actual cost is probably minimal. That said, Java desperately needs a saner way to deal with properties. It's just so much ceremony for so little reward. Tuples would also be sweet.
• August 2, 2010, Robert Fischer wrote: Okay, most of your points are good, but the dig on static typing was lame. The elimination of null pointer exceptions alone means that static typing can catch at least some bugs. Details over at 7 Actually Useful Things You Didn’t Know Static Typing Could Do: An Introduction for the Dynamic Language Enthusiast.
• August 4, 2010, Robert Fischer wrote: Like.
• August 5, 2010, Derrick wrote: Actually, Yes. Mapping 65,000 objects from a JDBC call takes 447 milliseconds using getters/setters, and 440 milliseconds without them. Granted, it's not a lot in the scheme of things, but the overall operation (including the jdbc call) took 978 ms. That was just a sample that I had access to tinker with.
• August 6, 2010, Robert Fischer wrote: Yeah, I'd call 7ms, or 0.7% the cost of the call, pretty minimal. I suppose it is a speed-up of 1.6%, which sounds like something. What we're really looking for is tuples. Although I suppose a final class with public fields is basically a Java coder's tuple. Except, y'know, that's evil and against corporate coding policy and stuff.
• August 6, 2010, Robert Fischer wrote: To everyone who thinks you don't need comments: how am I to know what this method does and what it returns?
• August 6, 2010, Blaisorblade wrote: The problem with having a public attribute is that you lose the freedom to change it later. As already explained, those calls are inlined during JIT-compilation. I agree that C# properties are much better though - Java is a son of C++, which is scarily complicated, so simplifying the language has been an (excessive) concern. If you don't agree about C++, try solving http://www.gotw.ca/gotw/056.htm, especially question no. 3.
• August 6, 2010, Robert Fischer wrote: Setting aside run-time code generation (which conflates compile-time and run-time), the side effects of JIT compilation don't impact compile-time decisions about how things are organized. It does make life difficult for Java people compiling against my code if I decide it really should be a getter-/setter-driven property later: they then have to change all their foo.x to foo.getX() to get their code to compile. So the issue is one of backwards compatibility. However, if the class is a simple enough data container (think "tuple"), is backwards compatibility really that much of a concern? To put it slightly more bluntly, what percentage of getX() and setX(x) are ever converted from simple attribute wrappers to a more complicated implementation? If that percentage is small (and it is, in my experience), then there's just a lot of noise in the code for little benefit, and the syntax should favor the common case.
• August 6, 2010, Christian Romney wrote: I have to confess I don't get you shit/pipe analogy at all, but I think I agree with your point about layered abstractions. In fact, I'd go so far as to say the abstractions don't always end at the public/private boundary. That's precisely why I disagree with the author when he says private methods should never be invoked. I think what he might have meant to say was client code should respect the private boundary, but he went a bit astray implying that private means private to the programmer, not private to the class. Of course, all of this is very abstract. There's a lot of public code I'd hate to call (let alone private), after having seen it. But if we assume a well-written, non-trivial piece of library code, I can see (have seen) someone wanting to use a lower-level function from a higher level function for something the author didn't give me the ability to do. And here, private sucks. A good analogy (albeit a program, not a library) is Git's porcelain vs. plumbing. Porcelain is at a higher level of abstraction, but I can use the plumbing to create more porcelain. The great thing about this analogy: it's all "public" because they're all available for the end user.
• August 7, 2010, Rob wrote: How many times did you run it? That 7ms might not actually be statistically significant.
• August 10, 2010, Robert Fischer wrote: Notably, I encountered this bug earlier today which is precisely a typing error. Even Java's lame type system would have caught it.
• August 11, 2010, Rusty wrote: If you think NullPointerException has been eliminated, I have some swamp land and a bridge you will be very interested in. Java programmers have a deservedly bad rep for being API monkeys because they NEED the compiler to rewrite their inefficient code and they need it to tell them when they made an error. Problem is, properly written code is easier for a runtime environment to optimize. Programmers that depend on the compiler to catch bugs need to be banned from the field for all eternity. Java encourages code bloat and allows under-qualified people to write code. The kingdom of nouns is an ugly ghetto.
• August 17, 2010, Robert Fischer wrote: Wow. You totally epitomize the mistaken viewpoint that I'm trying to correct in that blog post.

(Digital Fingerprint: bcecb67d74ab248f06f068724220e340 (74.125.156.81) )

But then, some time in 2009, something changed. The deficit “hawks”, who had spent eight years silent, suddenly awoke to the massive danger the debt posed, and took up their abandoned positions yet again. Now, all of a sudden, we’re treated to daily broadsides on the danger of the debt, and the need to eliminate the deficit immediately. Which leads me to ask: why now?

A word on Occam’s razor, as it will come up- Occam’s razor only applies between two theories that explain (“fit”) all the data. If a theory doesn’t explain all the facts, the fact that it’s simpler is irrelevant. So the plaintive cry that we can’t keep deficit spending doesn’t explain why you (and everyone else) were silent during the Bush years (if you were not silent, please post links- and the following comments don’t apply to you).

The one theory I’ve come up with that fits all the facts is that it’s not the deficit that matters- but what the deficit is spent on. Spend the deficit on wars and tax cuts, and that’s OK- but spending the deficit helping the poor, the sick, the unemployed, the hungry- what the heck do you think this is, a Christian nation? The ruling ideology around these parts is Darwinism- Social Darwinism, to be precise.

This theory is especially accurate in predicting the deficit “hawks” response to current budgetary items. Even if you accept that now the deficit is a problem in a way it wasn’t eighteen months ago, doesn’t it make sense now to allow the Bush tax cuts to expire, and to end the wars in Afghanistan and Iraq sooner rather than later, on the grounds that we can’t afford them? And wouldn’t it make sense, as a deficit hawk, to support legislation that saves more money than it costs? Take, for example, health care reform- which yes, costs $900 billion over the next 10 years, but saves $1.1 trillion (for a net savings of $200 billion), as the health care bill did. Granted, that’s a small savings, but as a deficit hawk, doesn’t every little bit help?

This theory also explains why, according the Republicans, extensions to the unemployment benefits must be fully paid for- but extending Bush’s tax cuts don’t. The alternative theory I have- that deficits are OK if a Republican is President, but not OK if a Democrat is President, doesn’t explain the deficit “hawk” stands on these current issues.

Note that it can make perfect sense to have opposed the Bush deficits at the time, and support the Obama deficits now, and not be just a Democratic partisan (“deficits are OK if a Democrat is President”). The theory here is to save for a rainy day, but that if it’s raining, now is the time to spend the money you have been saving. And it’s economically raining cats and dogs right now- the highest unemployment rate since the great depression is predicted to continue to be high for years, and we’re up against the zero bound (the Fed can’t lower interest rates below 0%), so conventional monetary policy (lower interest rates to stimulate the economy) doesn’t work. So now is a really good time for some Kenynesian stimulus spending, with the understanding that when the good times return, we pay off/down the the debt.

A school administrator once explained to me, when I asked why I was being punished for being attacked, that it wasn’t a fight until I hit back. By this definition, what the deficit “hawks” are doing is not class warfare. After all, it’s not a class war until the other side fights back. But this does explain why my reaction to these so-called deficit hawks is the same as my reaction that administrator, years ago.

Bite me.

Comments

• July 26, 2010, Shawn Hartsock wrote: When you are rich and powerful and want to justify holding your social position using Darwinism it's called "Social Darwinism", when you want to use Theism it's called "Divine Right", and when you want to use Christianity it's called "Prosperity Doctrine". No matter what the basic belief system is, underneath it all the fundamental motivation is still basically a form of tribalism that is trying to justify why when "we" want something it is "right and good" but when "they" want the exact same thing it is "wrong and evil." The truth is (in this case at least) there is no us and them there is only "we the people."
• July 26, 2010, Dianne Fischer wrote: When we look to deficits you need to look back, beyond the past administration that has been demonized even by it's own party. Bush senior inherited some messy finances. he was in the process of turning things around when he left office. All Clinton had to do was not screw it up. Being a very bright man he chose to screw things other than the economy. W came on the scene and here came the good ole boys to protect their interests. (A very dark time to be a Republican) Probably would have worked if the country hadn't been attacked and a war broke out. Wars have always caused huge deficits. Be careful quoting the health care package as paying for itself. It too is a case of cronyism (sp?) and the insurance companies will be huge winners. Government guarantee to increase their customer base and 5 years to rev up their prices to cover it. And , oh, by the way even the GAO admits it doesn't attribute all the costs to the health care bill. it omitted payments to doctors. Most likely a tidy sum that will increase as there are no cost cutting measures in this bill. And it didn't include all the ongoing costs of the many, many new government agencies being created in this bill. Did you know the one place in the nation not suffering from the recession is Washington DC? So why all the current interest in the deficit? Purely political fluff. A play to the 24/7 talking heads that dominate what we call the news today. Also, the ultra conservative Republicans are losing their moderate base and now are turning their attention to fiscal matter and trying to push away from the social reforms they have pushed in the last decade. all this in hopes of not being tossed out on their greedy little ears. Of course, if you want to pay your part of the deficit all you have to do is cough up over $45,000 for every man, woman and child in the US. At some point, whether its current hype or not, that has to get paid.
• July 26, 2010, Robert Fischer wrote: It's unfair to say that nobody except Krugman and the liberal blogs got into this. The overspending by Bush was criticized quite a bit by fiscal conservatives and it was one of the things that made space for Ron Paul's run. Here's some cites: CATO and Washington Times (see the paragraph beginning "With a Republican-controlled Congress offering little resistance"). If a blogger posts in a conservative blog and Brian isn't there to hear it, it's still posted. The fact that the Republican party is suddenly talking about budget controls is the same reason the Democrats aren't talking civil liberties anymore: political game-playing. And remember when Democrats talked about reigning in spending and fiscal control when slamming Bush? Where'd that talk go?
• July 26, 2010, Robert Fischer wrote: I'm not sure we have to talk outright tribalism to explain this. It's much more simple, I think: when you start with the conclusion, then the only arguments that are valid are those arguments supporting your conclusion. As a politician, you check your polls and your party, and you say, "X is popular/a party plank/my cash cow. Therefore, I am for X. If Y is an argument for X, then Y is what I believe." Note that consistency has no basis in this calculation, because nobody cares to remember.
• July 26, 2010, Tanner Lovelace wrote: Back in 2001 I advocated paying down our debt rather than giving people tax cuts. It would have made sense to save during years with budget surpluses so that we wouldn't have any problems borrowing during lean/crisis years. It looks like Asia figured this out: http://krugman.blogs.nytimes.com/2010/07/24/keynes-in-asia/ So, why can't we?
• July 26, 2010, Robert Fischer wrote: Paul Snively on Twitter notes that PorkBusters.org was also very active during the Bush admin.

(Digital Fingerprint: bcecb67d74ab248f06f068724220e340 (74.125.156.81) )

The tools are developed to work around short comings in the language itself. If the language didn’t have those short comings, you wouldn’t need the tools, and they wouldn’t get developed. The best language would be just fine with just notepad and a compiler. So bragging about how great the tools are for your language is bragging about how your language sucks, and needs significant amounts of help to make development in it tolerable.

Comments

• July 8, 2010, Barry Kelly wrote: With respect, that's an asinine thought. Smalltalk has had some of the best tools for the longest times, but that's because of the unity and regularity of the language and its runtime, not in spite of it. And conversely, C++ has historically had poor tools not because it's a great language - frankly, it sucks - but because its poor design made it so hard to tool.
• July 8, 2010, Barry Kelly wrote: I want to add further. Tools are developed when there's a market for them. Primarily that means that the language has adoption. Every large application, no matter what language it's written in, can benefit from certain generic kinds of tooling: code completion over modules, documentation popups in the editor for API calls, code navigation based on symbols invoked (but that isn't fooled by naming coincidences, like simple-minded - or even lexically aware - greps). These all help because large apps don't fit in every team member's head in their entirety. Tools that provide these basic functions add to any language that represents itself as text. (But graphical languages cannot be programmed without tools.) Bragging about the tools for your language indicates that (a) your language has an excellent design and is easily tooled, or (b) your language has widespread adoption and is a mature and reliable fixture in the programming landscape, or (c) both. Of course, the lack of tools doesn't necessarily mean the opposite.
• July 9, 2010, Patrick Mueller wrote: It's not just large applications that benefit from those sorts of generic tools that Barry mentions. Even small applications can benefit from these tools if you have a large library of code to deal with. Python is a good example here; I often write short little python programs, but constantly refer back to the web-based doc to figure out what functions to use. Which is, frankly, painful. I will, on the other hand, admit that I'm a reformed Smalltalker.
• July 9, 2010, jartur wrote: LISP in many of its forms and, say, Erlang have Emacs with great integration -- one of the best tools available. LISP used to have things like OpenGenera -- something modern tools can not even come close to for other languages. But dare you actually say that LISP is that awful?
• July 9, 2010, Slobodan Blazeski wrote: Not true, Lisp and Smalltalk are perfect counter examples.
• July 9, 2010, Scot wrote: I won't comment about Lisp or Smalltalk as I've never really used them, but Java and some of Java's surrounding technologies are perfect examples of this. I wouldn't want to code much in Java without an IDE, but JVM languages like Groovy are such an improvement on Java that I can happily use nothing but a text editor and a command line. I remember when Java Server Faces came out there were comments about how tooling would eventually be created that would take care of all the painful bits. After using it without the tooling I'm never going back to JSF if I can help - even if it does have tooling by now (no idea if it does or not - there are easier technologies to use). So it's not just languages that tend to suck if they need heavy tooling to be of any use, frameworks that need tooling have a tendency to suck as well. Question for the Smalltalk fans - how easy is Smalltalk to use without tooling?
• July 9, 2010, Michael O. Church wrote: Interesting thought, but I actually disagree strongly. I think that the strength of tools reflects on the size and power of a programming language's community. I don't think that tools are built to overcome shortcomings of the language so much as they are built to increase the quality and productivity of the programming experience, which can be improved dramatically no matter how great the language is. For example, Ocaml and Haskell are awesome languages, but as compiled languages, you still have nasty build-system problems (Makefiles) that emerge on large projects... and this is in no way a fault of the language itself. Hence, tools are built to deal with this. On the comment that a great language is "just fine" with an ordinary notepad, I'd agree, but Haskell is "just fine", of course, with a notepad and compiler; but the fact is that even when the language is awesome, it's not so awesome as to make better tools unnecessary. Of course, the languages that tend to have the best tools right now are those that have the largest communities, which tend also to be mediocre languages (Java, C++). That's not because of an causal link between poor language and great tools, but other factors entirely-- namely, the enormous number of mediocre programmers who are afraid to learn newer and better languages.
• July 9, 2010, Hercynium wrote: Just my $0.02... Perl is an oft-maligned language - and sure, it sucks in a lot of ways, but the thing that keeps me coming back to it over and over are the quality of the tools. With CPAN as the keystone, one can install just about any of these tools as easy as can be. examples: Devel::NYTProf, Perl::Tidy, Perl::Critic, local::lib, CPAN::Mini, perlbrew, Devel::REPL, all the Test::* stuff, and many many more... The fact that the language itself is so insanely malleable also tends to be a big plus - many of the add-ons I use give Perl some very convenient and advanced capabilities. examples: Moose, Devel::Declare, Try::Tiny, perl5i, and so on. So, one could argue that Perl sucks big time, but IMO, its tools more than make up for it, and I end up feeling deprived every time I code in other languages.
• July 9, 2010, Steven wrote: Congratulations on finding a counterexample to a generalization. You may be the first ones in all of history.
• July 9, 2010, Tom Davies wrote: You really need some examples to indicate what you are thinking. Take Java, which has great tools (e.g. Intellij IDEA's refactoring support). This tools is made possible by Java's static typing -- which I'd argue is a great language feature. Are you arguing that Java has a deficiency which makes refactoring tools necessary?
• July 12, 2010, Tom Harada wrote: I agree with the claim. But only with tools that solve problems which the language can also equally solve by being improved. There are some problems that both tools and language can solve, but with unequal levels of effectiveness. Language improvements that make up in concision what they might lack in flexibility and specific, thorough solving of the entire problem (compared to tools) are worthwhile. But yeah, I think the claim of the post is correct. Language tools and language are somewhat inversely related because they compete over the same space. But the other point (as perhaps some make) is that language tools also open up possibilities for new design, etc. So there's really two competing relationships. It's sort of like a general and a scout. Really good scouts might be signs of a weak general. I think that's Brian's point. But it is possible to have both be really good in certain circumstances. Or to have both be really bad, etc. Also, when people think about examples and counterexamples, it's maybe important to remember that 'language' is a very fluid concept. It's maybe better to think about 'language' in terms of a language hierarchy (or hierarchy of abstractions). There are little languages in syntax, in high level design, in modules, in interfaces -- everywhere there is abstraction. It's language all the way down. So if your tools (which also form a language set -- mostly for solving the higher-level problem of doing actual development logistically) are top heavy that means there's an inelegant quality to the hierarchy. You've got a tree branch which is unusually large. Sometimes this isn't bad (a huge set of libraries like CPAN, etc.) -- but arguably it prevents other parts of the tree from properly developing, etc.
• July 16, 2010, Angelo Pesce wrote: I do understand the spirit of this post (i guess) and i do think that indeed many tools are bad patches to fundamental flaws. A big example would be debuggers. I would any day prefer to use no debugger in a interactive language (live coding) than a debugger in a statically linked one (c++). But i would love even more both, an interactive langage with a graphical debugger i.e. A good langage supports tools, like c#. A bad language doens, and still neds them to be half decent, i.e. C
• July 21, 2010, ChriS wrote: A blog post with an interesting perspective on languages v.s. tools http://osteele.com/archives/2004/11/ides

(Digital Fingerprint: bcecb67d74ab248f06f068724220e340 (74.125.156.81) )

The idea goes like this: a working definition of what, say, physics is, is that it’s what physicists do. It’s not perfect, but it works, and it’s much easier to measure. So you have this site, and you can get an account if you’re a physics researcher at an accredited research institution (this is answering the question “who is a physicist” by plugging into the existing infrastructure of defining who is a physicist- accreditation). Having an account means you can do three things- upload papers, vote on papers, and comment on papers. Everyone, including the public, can see all the papers that have been uploaded, and their comments, but only accredited physicists get to upload papers (if you’re not an accredited physicist, you have to get at least one accredited physicist to upload your paper- the papers the physicists upload don’t have to be theirs- they’re just claiming that they consider the papers to be physics). And they’re time stamped so that priority is preserved.

Once the paper is uploaded, physicists can vote for them. Each physicist gets only one vote per paper, and every month the N papers with the top number of votes which haven’t already been published get published in the paper journal. And yes, the votes accumulate, so a paper that’s been slowly garnering a vote a month for the last five years (and thus has 60 votes) beats out the paper that got uploaded yesterday and has already garnered 59 votes (although that paper will likely make it next month). There might be an English major on staff to make sure everything is spelled correctly and is grammatical, but that’s optional.

I might allow down votes (allowing physicists to say “this paper isn’t physics, or isn’t worthy of being published”), but they would only count in the case of a tie (if two papers both have 100 up votes, and only one can be published, publish the one that has fewer down votes). You might also have multiple journals, and allow the physicists to vote on which journal a paper should be in (“This paper really belongs in the Journal of String Theory, not in the Journal of Loop Quantum Gravity” for example).

I would make the list of who voted, both for and against, various papers public, for two reasons. First of all, this helps discourage people from engaging in personal vendettas, or at least makes it more obvious that they do, and second, this allows the heavy weights to influence the selection process (“if both Leonard Susskind and Stephen Hawking are voting for this paper, that’s good enough for me!”).

This is a couple of weeks of work for a competent Ruby on Rails hacker. The biggest coding problem will be handling the multitude of different file formats the papers will come in (word, latex, etc) and making them look more or less uniform. The real problem will be marketing to the physics community itself. Physical Review D is an important journal to the physics community because a lot of important papers are published there, because a lot of important papers are submitted there, because it’s an important journal. Everyone buys IBM because everyone buys IBM. Except everyone doesn’t buy IBM anymore- change can happen.

Comments

• June 25, 2010, Michael Ekstrand wrote: The coding problem is easily fixed with policy - provide a template and require all submissions to be text-extractable PDFs. That's (almost) how some CS conferences work. As far as the social impact - it is interesting to consider. I don't know what it would be, or how scientific publication would be affected for better or worse. Worth pondering, though!
• June 27, 2010, Robert Fischer wrote: Requiring it to be in LaTeX works fine, too.
• July 16, 2010, Roland Kaufmann wrote: What incentive would accredited physicists have to publish papers that is not their own to the site?
• August 27, 2010, Robert Fischer wrote: Check This Out - it looks like something's already cooking that way.

(Digital Fingerprint: bcecb67d74ab248f06f068724220e340 (74.125.156.81) )