Helltime for July 20
Announcer: Now for quick hits and commentary on software development topics from around the web, the EIP web-ring brings you the stigmatized spawn of a refactory, MoffDub, and Helltime!
- I had learned about double-brace initialization in Java sometime last year. It was surprising, yes, but if you write it with proper indentation, it is perfectly clear what is going on. Someone decided to throw up a post from Refactory.org on Reddit and you can imagine what happened.
One comment, though, made me stop and think. Two classes created with double-brace initialization may not compare to be equal since they are technically not instances of the same class. I haven’t yet been bitten by this gotcha, probably because our code is not that OO.
The answer to this, then, is not using shorter names, but using some form of chaining, just not an absurd form.
- There’s an interesting post on Ryan Davis‘ tech blog on how you can slip in Lisp at work.
While nice to think about, I don’t have the luxury or authority to simply declare that I want to use language XYZ on the new project. Besides, even if I did, I’d be alone. I think people need to be proficient in their current paradigms and languages and, you know, show some independent thinking outside of going through the motions, before you can think of throwing something as archaic as Lisp at them.
The end of the post prodded me about a lingering question that I need to start researching: how do you deploy code written in interpreted languages?
- Finally, Samuel N. Hart, liberal moron, unloads with both limp-wristed barrels on test-driven development.
While good for a nice laugh, the post has serious sobering issues. First, the claim that there’s “extra, often useless, up-front development” is a straw-man because this risk applies to any project that isn’t agile, and even most projects that are agile. His complaint that TDD won’t alleviate “inevitable refactoring” is a joke too — nobody said that TDD was trying to do this. On the contrary, TDD enables this refactoring. Laughable too are the complaints that TDD can’t catch all bugs, namely those that result from integration tests. Yeah, thanks, bro; taht’s why we call them unit tests.
Next, Hart’s “biggest problem” with TDD: “often it is much easier to refactor your code to match your expected results from a test you’ve written”. It’s the exact opposite. Do you know how many times I’ve seen people, not practicing test-first, by the way, watch a unit test fail and simply change the test to match the code? What, then, is the point of the tests?
I would go further, but I’m not in the business of turning my blog over to someone who undoubtedly voted for The Messiah.
![]() |
Announcer: You’re reading the EIP web-ring. |
