Cédric Beust

The problem is, people have been told for so long not to care about Python 3 that it's hard to imagine what could make people actually start caring about it. Practically the only people that have even tried it are Python fanatics or compiler devs.

I understand the desire to make fundamental language changes and why it's cleaner to make Python 3 backward incompatible. I don't agree that it was the smartest thing to prevent any kind of interoperability, though. The way people could begin using Python 3 is if you could still import Python 2 modules from Python 3 code. OK, there would be some tough nuts to crack to get the interpreter to switch contexts gracefully and translate objects from one side to the other. But at least people could start using Python 3 and then begin switching things over one at a time. To ask everyone to keep running 2to3 to maintain a second codebase that nobody uses is kind of silly and unrealistic, and causes this détente where too few people care enough to make a first move.

Also, gripe here. Why the heck is def method(self, actual_first_arg, ...) still all over the place in Python 3? They had a golden opportunity to kick that bizarre holdover from when Python couldn't do OO [1], and they didn't [2]. The only solid argument Guido has against it is about decorators, and it really only applies to @classmethod and @staticmethod, which arises primarily from the stodgy way Python implements these OO features and which could have been nipped in…

I'm familiar with TDD, both its strenghts and limitations (http://ravimohan.blogspot.com.ar/2007/04/learning-from-sudoku-solvers.html, http://beust.com/weblog/2014/05/11/the-pitfalls-of-test-driven-development/, etc).

I understand that this kind of testing often works (though I'm less enthused with TDD as a design technique, which is unfortunately what TDD proponents emphasize, and what you seem to be describing here). I'm saying it is too limited. "But software is written and tested this way", you can say. But buggy software is written every day, even with testing, which is why we should strive to improve our testing tools & processes.

To be clear I'm not saying "abandon TDD" (ok, maybe I'm not rooting for TDD in particular, but I'm definitely not saying "abandon unit testing"). What I am saying is "complement it with static typing and more advanced testing techniques, such as property testing."

Finally:

>> it fails to tell apart addition from the constant function 7

> It's not supposed to do that.

Well, in a way it is. Your tests must attempt to detect flawed implementations, even though they cannot prove correctness. I'm sure you can think of cases where an algorithm sometimes seems to return the correct result, but fails in some cases.

I knew CrazyBob for over 20 years. We met at JavaOne and at the time he was still a consultant living in St Louis. Bob was always the life of the party with a grin like a Cheshire cat. Eventually he got a great job at Google working on the core APIs for Android and created the very lightweight Guice dependency injection framework. We shared a distaste for both Spring and J2EE by that point. At Square he started the CashApp and created a strong engineering culture. Even though he was a college dropout he was one of the best algorithm guys I have met (e.g. https://www.beust.com/weblog/coding-challenge-wrap-up/). The closest we ever got to working together was when I was talking with Twitter about an acquisition of my startup and was getting advice from him he immediately put us into the process at Square. I think their pair programming interview style was the most fun I have had interviewing. We ultimately went with Twitter but I would have done as well going with Square.

Our families would hang out together when we lived close and I feel sick just thinking about his children right now.

This is a great post. I feel the same on many topics.

> I was never a huge TDD believer and I’m not one today.

I'll never forget this savage takedown of TDD by Cedric Beust: https://www.beust.com/weblog/the-pitfalls-of-test-driven-development/

The best rebuttal to TDD that I ever heard from a developer that I respected: "I don't care if you use TDD or whatever. When you commit code, tests need to be included." That's it. And yet, the TDD evangelicals are like the vegans of diet or calisthenicians of fitness -- always annoying, no matter what they say. (Side note: I was a vegan for many years, and I still thought the loud ones were annoying!)

> write it twice

This is what I hate so much about unit tests -- you chisel the statue once from stone, then, by writing unit tests, you essentially chisel the inverse to fit your new statue. So exhausting.

This commenter has the right answer. -> http://beust.com/weblog/2011/10/27/probability-quiz/comment-page-1/#comment-12590

The question is phrased such that most people will immediately assume the distribution from which we choose an answer is uniform over {A, B, C, D}. If, indeed, we choose each answer with equal probability 1/4, then none of the answers can be correct. This is not a paradox! It's simply a proof by contradiction that the distribution from which we select our answer "at random" cannot be uniform over all the choices.

The problem is clearly with the phrase "at random," which is ambiguous in a mathematical context, but, in popular meaning is equivalent to "uniformly at random."

It shouldn't really matter whether the units tests are written before or after.
What matters is how testable the source code is, and making sure the units tests add value.

Of course, writing the tests before the actual source code of the feature enforces the fact that it's testable, but it's mainly a side effect, there's nothing inherently better.

The microdesign flaws that stem in TDD (described in [1]) were real in my personal case, and my code is way better on the long term with the units test written afterwards, because I tend to modify my design a lot while writing code.

[1] http://beust.com/weblog/2014/05/11/the-pitfalls-of-test-driven-development/