2 ms·

It's true, but it's more a treatment then addressing the root cause. Rich Hickey, creator of Clojure has a fun quote that goes something like: "You thought you

It's true, but it's more a treatment then addressing the root cause. Rich Hickey, creator of Clojure has a fun quote that goes something like: "You thought you wanted TDD, but really you wanted an interactive REPL." My gripe with TDD, is that it gets tedious in its own way. Always needing to eventually mock some aspects of the code, and always working in the small, you start feeling distant from the medium and large picture of the code.

ece 9y ago
It's a pretty good treatment. I think the solving the root cause would be something like a constant time compiler, which I don't think is going to happen. You don't need to mock at all if you do DI and modularity well in Guice or Spring or something else (it can be the rare exception for a few libraries that use say private constructors). You can also write 3-5 line tests that will absolutely test everything in your program, and be able to debug it line by line in a debugger. So, I'm not sure I would agree with Rich Hickey on this. REPLs are no substitute for a good IDE and debugger running a series of declarative tests.
- didibus 9y ago
  Not all REPLs, just like you had to preface debugger with good, you need to preface REPL with good. You really need to give a good REPL a fair try to know what I mean. Most people also thought tests wouldn't add much worth, and took a long time to bother giving tests a fair chance. Good interactive REPLs are the same. Try it out, not one day of it, spend a week, then decide. It helps if you know someone that can show you. At my work, a lot of devs try Clojure and don't like it. Then I sit down with them and show them how you're supposed to use the REPL. They always turn around after that, and acknowledge how awesome the REPL is. That's why I emphasize on fair chance. Its easy to try it and miss the point, not use it how it is meant to be used. Also, the language must embrace it, if its tacked on, it rarely works. It has to be first class. Ya, I agree, tests are a good treatment, the best for most languages. A good interactive REPL is often better though. Clojure has tests, good IDEs and debuggers. Yet people don't care about them as much, because the REPL solves most problems. In return, it means the IDEs and debuggers aren't as good as Java, because people care less and so also invest less in them, and sometimes I'd want a better IDE or debugger to complement the great REPL experience, but I wouldn't trade the great interactive REPL for them.
msangi 9y ago
A REPL is better when prototyping but tests have a lot of value afterwards. They're repeatable and they can be used to spot regressions. I think that the a good workflow is to do initial experiments on a REPL followed, once I get an idea of the code will look, by writing tests and the actual code that will run in production.
- didibus 9y ago
  Yea, you still want regression tests no doubt, but those are very different from TDD. You only need write them after you're code complete on a feature.

ece 9y ago

It's a pretty good treatment. I think the solving the root cause would be something like a constant time compiler, which I don't think is going to happen. You don't need to mock at all if you do DI and modularity well in Guice or Spring or something else (it can be the rare exception for a few libraries that use say private constructors). You can also write 3-5 line tests that will absolutely test everything in your program, and be able to debug it line by line in a debugger. So, I'm not sure I would agree with Rich Hickey on this. REPLs are no substitute for a good IDE and debugger running a series of declarative tests.

didibus 9y ago
Not all REPLs, just like you had to preface debugger with good, you need to preface REPL with good. You really need to give a good REPL a fair try to know what I mean. Most people also thought tests wouldn't add much worth, and took a long time to bother giving tests a fair chance. Good interactive REPLs are the same. Try it out, not one day of it, spend a week, then decide. It helps if you know someone that can show you. At my work, a lot of devs try Clojure and don't like it. Then I sit down with them and show them how you're supposed to use the REPL. They always turn around after that, and acknowledge how awesome the REPL is. That's why I emphasize on fair chance. Its easy to try it and miss the point, not use it how it is meant to be used. Also, the language must embrace it, if its tacked on, it rarely works. It has to be first class. Ya, I agree, tests are a good treatment, the best for most languages. A good interactive REPL is often better though. Clojure has tests, good IDEs and debuggers. Yet people don't care about them as much, because the REPL solves most problems. In return, it means the IDEs and debuggers aren't as good as Java, because people care less and so also invest less in them, and sometimes I'd want a better IDE or debugger to complement the great REPL experience, but I wouldn't trade the great interactive REPL for them.

msangi 9y ago

A REPL is better when prototyping but tests have a lot of value afterwards. They're repeatable and they can be used to spot regressions. I think that the a good workflow is to do initial experiments on a REPL followed, once I get an idea of the code will look, by writing tests and the actual code that will run in production.

didibus 9y ago
Yea, you still want regression tests no doubt, but those are very different from TDD. You only need write them after you're code complete on a feature.