Thank you for making the case of considering REPL as an additional tool in software engineering.
I'd like to add a few thoughts. You mentioned that you would still write tests, just in a different fashion. So, it seems you still see value in automated tests per se. How do you know, however, that you didn't accidentally break something elsewhere? It a pure TDD approach, you can change any random line of code under test (including removing the line) and something will break. The code is there only because some test would pass only, if the code is present. With REPL, if I understand you correctly, you don't have that.
Most software is written by teams. Getting value to the customer fast and more frequently has led teams to adopt practices such as continuous deployment and release-on-demand. The frequency with which production systems are updated has increase. Once you have dozens, hundreds or even more people working on a system, the quality practices need to scale as well. Without automated tests, that won't work. "End-to-end" testing that looks at the entire system can become very time-consuming (= expensive) very quickly. With small sets of tests, ideally implemented using TDD you have a much higher chance of getting all team members writing tests, which in turn can be executed fast (think sub millisecond per test). If they are cheap and easy to execute it's more likely that all team members run tests fast. Therefore writing automated tests scales and allows a continuous high flow of value through the development process and the delivery pipeline.
When I start a new piece of code, I don't know yet what the implementation will look like. I don't even know what set of tests I will end up with. It's an inter-dependency between the code and it's design on one hand and the tests on the other hand. When I look at the implementation I may find a design flaw or something that will break, e.g. perhaps a missing parameter check. Then I write another test that will only pass if I change the code to the better.
Also, I wouldn't trust refactoring tools too much. At times they get it wrong as well. Merciless refactoring paired with TDD is an extremely powerful combination. Add architecture and design that includes testability from the get-go, and it is likely the resulting quality is much better than many software systems currently in use.
Don't get me wrong. I'm not against using REPL to support learning about the system, an piece of code, an API and many more. I think, however, I would not ditch TDD in favor of REPL. I think both are valuable tools. It is important to understand how each works when used properly and what each can do for you. It is equally important to understand what you loose if you ditch a technique, be that TDD, REPL or something else.
In summary I'd encourage the reader to try TDD, REPL and every other tool or technique that will help improve the quality and productivity of a software engineer. Also, I respect, even like your views even though I don't agree with what I perceive as a statement that REPL can replace a sound TDD approach. I'll tweet a link to this article as I think it's valuable to be read and considered. Thank you, again, for writing this up!
