4 ms·

I'm really glad they posted this. I saw a lot of twitters at RailsConf about how great this keynote was. Now that I've seen it, I personally don't see that much

by jpcx01 17y ago

I'm really glad they posted this. I saw a lot of twitters at RailsConf about how great this keynote was. Now that I've seen it, I personally don't see that much to like about it, but at least I'm no longer left wondering

jlouis 17y ago
Me too. It is delivered with great fun, but there is no truth.
- RiderOfGiraffes 17y ago
  ... there is no truth. Interesting claim. Question: Have you actually tried programming the way he sugegsts? Have you used it "in anger"? Have you worked in a team that has ubiquitous, all-encompassing, tests? I ask because I'm interested. I've started recently, as an experiment, to run in that very, very small circle, and after an initial experience of paralysing culture shock I'm starting to run really, really fast. I'm finding it liberating.
  - jlouis 17y ago
    There is no doubt many programmers find it beneficial to use TDD. My claim is still that there is no truth, but not in the sense that you think. It is very easy to say that TDD helps, or that X killed Smalltalk, because it is almost impossible to falsify. It is the same weak argumentation that made OO prevail back in the 80'es/90'es. Usually you back up this by a "study" containing a) 1-2 "Cases" and b) no statistics with a significance test. As to your questions: "Have you tried it?": It depends. Test driven design states that you need to develop code and tests in tandem. I rarely do that. But note I also rarely program in dynamically typed languages. I develop the type in tandem with the program, and that constitutes a verifiable test as well, albeit a different one. Correctness is usually backed up by either a) machine-verifiable proof or b) Black-box test suites. "Have you used it an anger?" I can't answer this. I rarely program when I am angered. I don't become desperate when I write code. "Have you worked on a team with ubiquitous, all-encompassing, tests?" Yes. The team did not do TDD though. All tests were black-box. Here is another experiment: Read Benjamin C. Pierce: TAPL and ATTAPL. Understand them. Learn Haskell. Learn QuickCheck. You will probably find that TDD is something which is much more needed in the dynamic language setting.

by jpcx01 17y ago

jlouis 17y ago

Me too. It is delivered with great fun, but there is no truth.

RiderOfGiraffes 17y ago
... there is no truth. Interesting claim. Question: Have you actually tried programming the way he sugegsts? Have you used it "in anger"? Have you worked in a team that has ubiquitous, all-encompassing, tests? I ask because I'm interested. I've started recently, as an experiment, to run in that very, very small circle, and after an initial experience of paralysing culture shock I'm starting to run really, really fast. I'm finding it liberating.
- jlouis 17y ago
  There is no doubt many programmers find it beneficial to use TDD. My claim is still that there is no truth, but not in the sense that you think. It is very easy to say that TDD helps, or that X killed Smalltalk, because it is almost impossible to falsify. It is the same weak argumentation that made OO prevail back in the 80'es/90'es. Usually you back up this by a "study" containing a) 1-2 "Cases" and b) no statistics with a significance test. As to your questions: "Have you tried it?": It depends. Test driven design states that you need to develop code and tests in tandem. I rarely do that. But note I also rarely program in dynamically typed languages. I develop the type in tandem with the program, and that constitutes a verifiable test as well, albeit a different one. Correctness is usually backed up by either a) machine-verifiable proof or b) Black-box test suites. "Have you used it an anger?" I can't answer this. I rarely program when I am angered. I don't become desperate when I write code. "Have you worked on a team with ubiquitous, all-encompassing, tests?" Yes. The team did not do TDD though. All tests were black-box. Here is another experiment: Read Benjamin C. Pierce: TAPL and ATTAPL. Understand them. Learn Haskell. Learn QuickCheck. You will probably find that TDD is something which is much more needed in the dynamic language setting.