3 ms·

Same here. I agree fully with using version control, and that reading other code is educational (although being bit hard by having to maintain unforgivably slop

Same here. I agree fully with using version control, and that reading other code is educational (although being bit hard by having to maintain unforgivably sloppy code you wrote a long time ago will teach you some of the same things, i.e., being neat will make things much easier to fix later), but advice that essentially says, "1. Test, 2. Test, 3. Test, 4. Test, ..." isn't advice, it's a sign that there's something suspicious going on. I think it's telling that the most noise is made about TDD in the Ruby (and to a lesser extent, Python* ) world, but that it hasn't gotten as strong a foothold in many other languages. TDD seems to me to be a way to take advantage of dynamically-typed languages' strengths while compensating for against their weaknesses, but then it only makes sense with certain kinds of languages / styles of programming, and its advocates seldom seem to address this. (Regression tests are more generally useful, for example.) Also, contrasting TDD against testing styles from other language-cultures may be enlightening. For example, look at QuickCheck in Haskell: Many tests that could fall under TDD are already covered by the type system in Haskell and ML, so instead it focuses on automatically finding edge cases for you and verifying that invariants hold. * Also, many testing practices, e.g. TDD, automated unit testing, etc., originated with Smalltalk, another dynamically-typed language.

edw519 18y ago
...it's a sign that there's something suspicious going on... Thank you, silentbicycle. That's what I was trying to say, but you said it much more eloquently than me. I have always looked at "tools" with a wary eye. Are they really a solution to an existing problem or are they aspirin (or a crutch) for a pain without addressing the underlying cause. I realize many people believe the former. I usually believe the latter. They don't call me a caveman coder for nothing.
- silentbicycle 18y ago
  Ruby people praising TDD is like hearing Java people blown away by Design Patterns or C people talk about techniques for avoiding buffer overflow errors: Sure, it's a good thing that they're trying to improve the quality of their software, but to some extent their methodologies are compensating for tradeoffs (and sometimes just flaws) in those languages. The trick is telling when they're genuinely useful techniques from when they're solving problems that could have been avoided entirely. I don't think that all tools are bad, though; far from it. Just, sometimes it's better to address the root causes of problems, rather than symptoms. (Almost always better, in the long term, but deadlines happen.) I'm working on a tool right now (not ready to share yet, it's a rare spare time project), working title "dehydrator" (like the DRY principle and hydras, dragons that keep growing more heads) which can scan code (or arbitrary sequences of tokens, really; it's an OCaml functor) and report on heavily duplicated patterns it finds. The motive is to help reintegrate code that has been copied-and-pasted to several places with only small changes. Obviously, the solution is Don't do that!, but the world is full of projects that already have years of cruft.

edw519 18y ago

...it's a sign that there's something suspicious going on... Thank you, silentbicycle. That's what I was trying to say, but you said it much more eloquently than me. I have always looked at "tools" with a wary eye. Are they really a solution to an existing problem or are they aspirin (or a crutch) for a pain without addressing the underlying cause. I realize many people believe the former. I usually believe the latter. They don't call me a caveman coder for nothing.

silentbicycle 18y ago
Ruby people praising TDD is like hearing Java people blown away by Design Patterns or C people talk about techniques for avoiding buffer overflow errors: Sure, it's a good thing that they're trying to improve the quality of their software, but to some extent their methodologies are compensating for tradeoffs (and sometimes just flaws) in those languages. The trick is telling when they're genuinely useful techniques from when they're solving problems that could have been avoided entirely. I don't think that all tools are bad, though; far from it. Just, sometimes it's better to address the root causes of problems, rather than symptoms. (Almost always better, in the long term, but deadlines happen.) I'm working on a tool right now (not ready to share yet, it's a rare spare time project), working title "dehydrator" (like the DRY principle and hydras, dragons that keep growing more heads) which can scan code (or arbitrary sequences of tokens, really; it's an OCaml functor) and report on heavily duplicated patterns it finds. The motive is to help reintegrate code that has been copied-and-pasted to several places with only small changes. Obviously, the solution is Don't do that!, but the world is full of projects that already have years of cruft.