Cédric Beust

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.

What a tragedy. I remember Bob’s code that generate certain numbers: https://www.beust.com/weblog/coding-challenge/. Bob’s code is in Java, yet uses clever backtracing techniques to achieve the best performance among many solutions in all kinds of languanges.

Type erasure was the best of these options, and it's one of the main reasons why Java became even more successful than it already was, and also the main reason why there are so many languages created on top of the JVM (as opposed to .net, which supports reified generics, which complicates enormously writing languages on it, especially for interop reasons). More details: https://www.beust.com/weblog/erasure-vs-reification/

I've never got into cubing for speed, but I've long thought that http://beust.com/rubik/ is one of the best ways to start building a feeling for solves. Last layer is only 4 short algorithms (though you may need to hit them a couple of times).

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.

Came across this on Google after being inspired by https://www.beust.com/weblog/coding-challenge-wrap-up/

Kobalt build tool uses a Kotlin DSL (typed language) and lets you establish dependencies between files in a straightforward way. It currently only supports java and kotlin jvm projects but it meets your criteria. https://beust.com/kobalt/home/index.html

It doesn't, but it eases a lot of frustration in other areas, which makes fragments slightly more bearable. The standard library[0] functions `apply` and `run` are really nice with builders. When I converted Red Moon[1] from Java to Kotlin (no functionality changes), the code base shrunk by around 1/6. [0]: http://beust.com/weblog/2015/10/30/exploring-the-kotlin-standard-libra… [1]: https://github.com/raatmarien/red-moon

Take a look at the Kobalt build system http://beust.com/kobalt/home/index.html

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-develop…

there is a kotlin build system http://beust.com/kobalt/home/index.html

According to Cedric Beust, it's still a language that "pretty much hardly anyone uses". http://beust.com/weblog/2014/05/11/more-about-language-popularity/#com…

It's interesting to see how 15+ years later, general attitudes among the masses haven't changed much in this regard (according to the most popularly used languages [0][1]). Feels bad, man. [0] http://beust.com/weblog/2014/05/03/language-popularity-on-github/ [1] https://www.google.com/search?q=language+popularity

This might help: http://beust.com/weblog/2011/07/29/erasure-vs-reification/

The link indicated in the comments is how I learned how to solve the Rubik's cube: http://beust.com/rubik

To read another side of the coin, someone who made the move from Ember to Angular : http://beust.com/weblog/2012/12/29/migrating-from-ember-js-to-angularj…

My mistake, he actually has left Google: http://beust.com/weblog/2010/05/13/leaving-google/

The advantage of statically typed languages has a lot less to do with tests and everything to do with tools. IDE's can do very little when no type information is available, and most automatic refactorings require human supervision when performed on dynamically typed languages (read this for details: http://beust.com/weblog/2006/10/01/dynamic-language-refactoring-ide-pi… ).

> I think git is not easy to use, and the proof of that is that at least once a month there is a "how to use git" tutorial on the front-page of HN. The command line is hard to learn, and there is no real way to learn it besides... well, learning it by heart, quirks and all. A bit like learning a foreign language. After a while, you don't notice it any more and you realize how powerful and pleasant git really is. Here is an article that captures these thoughts fairly well: http://beust.com/weblog/2010/04/06/git-for-the-nervous-developer/

This commenter has the right answer. -> http://beust.com/weblog/2011/10/27/probability-quiz/comment-page-1/#co… 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."

I remember reading this anecdote to explain the anthropic principle: http://beust.com/weblog/2010/08/17/fun-with-the-anthropic-principle/

There's also JCommander - such is the myriad of random Java frameworks for achieving the same thing. http://beust.com/weblog/2010/07/13/announcing-jcommander-1-0/ It's annotation based though and looks to be a bit easier to use Commons CLI - which is what I currently use on projects.

Reminds me of ruby's builder (this blog has a simple, quick example: http://beust.com/weblog/archives/000025.html Implementation of the xml builder. http://snippets.dzone.com/posts/show/2528 This is supposedly quicker than http://builder.rubyforge.org/ I imagine there is a python equivalient.

Consultants need to make a living somehow, just waiting for the next fad to come along. The most sane approach to TDD is by Cedric Beust (author of TestNG: http://beust.com/weblog/).

Right, 'cause Arrington definitely knows security theory better than Google engineers do. In short: there are far more than 10000 possible patterns (the max for a 4-digit numeric unlock code) available with the Android login screen. I haven't looked deeply enough to insure that there isn't some minor error, but the analysis here looks fairly convincing: http://beust.com/weblog/archives/000497.html So, we get a 40-fold increase in the key space, plus an easy spatial mnemonic? Sounds like an improvement in both security and usability to me. Sorry, Mikey, stick to business plans and rumors. Leave the security to the pros.

I'm familiar with TDD, both its strenghts and limitations (http://ravimohan.blogspot.com.ar/2007/04/learning-from-sudoku-solvers.… http://beust.com/weblog/2014/05/11/the-pitfalls-of-test-driven-develop… 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.

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…