REPL Driven Design

Bob Martin is myopic in his view of software, in a way that I think is harmful to teams and the industry.<p>It is my experience that good software comes from teams working together well, teams that are in some sort of harmony with each other AND the system they are building&#x2F;using. They understand it and each other. Good software is not derived from a singular technique.<p>I do like test-first approaches when I can, I like SOLID. I probably agree with Bob on a lot, actually. I think they are good techniques to employ.<p>However, it has not been uncommon in my career to find people (and myself) getting dogmatic about these things and arguing over them. There are half baked attempts to change everything to an Entity. There are flaky test suites with a lot of mocks because someone is hot on TDD, but does not have the bandwidth to maintain the suite for the whole team.<p>This blogicle is another example. As pointed out by other posters, REPL driven development can fold VERY well into a test driven workflow. However, that&#x27;s not enough, he&#x27;s actively saying it&#x27;s not as good and you need to do The One True technique.

There&#x27;s no reason for this, and it bothers me enough that I&#x27;m doing something about it.<p>A (series of) REPL commands is just a test, where acceptance and rejection is manual: we look at the output, and keep changing the code until we get what we want.<p>At which point, we should be able to say to the REPL: yes, this result is correct, this is a test, and it&#x27;s now called &quot;Thing does what I want when I give it X and Y&quot;.<p>The runtime then saves this as a test, and will run it automatically when you ask it to. If there&#x27;s a regression, it will boot back up into the interactive REPL so you can inspect it and fix it.<p>I&#x27;ve been writing a REPL. Turns out that&#x27;s a lot of work, but I&#x27;m getting to the point where I can add this feature, which is the last one I really want to add before I go public with this thing.

Just to be fair, I don&#x27;t think many practiononers of REPL-driven design would consider it a replacement for tests. It&#x27;s an alternative workflow to TDD, yes, but the idea is that you still write comprehensive tests, they&#x27;re just usually at a higher more system-y level than the ones you get from TDD.

This is a PEBKAC, not a problem with REPL-driven development. He had all the test bodies written as input in the REPL, he had all the test results printed as output in the REPL. Why didn&#x27;t he turn these into unit tests as he programmed?<p>That&#x27;s a simple lack of foresight on the programmer&#x27;s side that is then blamed on the tools that were used.

<i>Clean Code</i> was one of the first books I read professionally, and I&#x27;m glad I did. Since then, I&#x27;ve formed the opinion that &quot;Uncle Bob&quot; sometimes (as in this case) takes helpful ideas a bit too far. But I&#x27;m still open to correction.<p>Does anyone know of an open source codebase he&#x27;s written or been a major contributor to? I know he writes a lot <i>about</i> clean code, but I&#x27;ve never seen production code from him.

This feels like a straw man. Or maybe a false dichotomy. I think it&#x27;s entirely possible to ensure code is testable before writing the test. It&#x27;s also not unusual to tinker in a repl before encoding the functionality as a test. Pretty let down by this post.

This was the programming model I learned on the lisp machine and Common Lisp: define a few datastructures and some operations on them, explore them with some live data, and expand. All iteratively at the REPL.<p>A few years later a friend referred to this dismissively as “Programming by successive approximation.”<p>There is a lot of truth to this, but the distinction isn’t as sharp as it sounds: you still have to think ahead, and as you explore and expand you’ve typically always got something working, some test cases and invariants, and typically you have the benefit of working on live data.<p>Even though I do most of my work in compiled C++, my work model isn’t that different.

His argument feels like a straw man. You can and should fill in a few tests after you confirm something in the REPL. Maybe Clojure folks don&#x27;t do that, but Ruby and Elixir devs often do. I would imagine he&#x27;s familiar with that approach.

Is this just the equivalent of saying &quot;Hey, REPLs are nice when you&#x27;re trying to figure something out&quot;, but spouted off as some deep programming wisdom?<p>Like, folks... REPLs are really nice when you want to figure out how a function or module or whatever works. Then yeah... you can take that knowledge you gained and apply it to your work.<p>Like.. how is this a deep profound revelation for folks?

I think there&#x27;s a big distinction in the general developer population between:<p>a) Knowing both how to effectively write tests &amp; how to effectively use a REPL.<p>and:<p>b) Knowing only how to bang around in a REPL enough to use it as a crutch to avoid writing any tests.

Bob Martin, who is quite opinionated, has been brutally wrong about some things. For example, there was a TDD attempt to solve Sudoku that failed. Uncle Bob was following this, and said of the failure &quot;At least he had the courage to post his failure&quot;.<p>More interesting would be a correct solution, which was posted by Peter Norvig. The approach he uses is drastically different that anything TDD is likely to get for you.<p>TDD isn&#x27;t going to find solutions to hard problems beyond bowling.<p>There is a stark contrast between agile development and actual software engineering. Agile works where the customer and the developer don&#x27;t really know what is being developed.<p>And as much as he has lectured about software development, I don&#x27;t get the feeling that he has actually developed a substantial quantity of serious software.<p>In one of his clean coder books, he argues that Java is not object oriented. Unclear if that is a widely-held opinion. If you look for serious high-quality software, they are not agile. Such as the software for the space shuttle, or qmail, or other formally-verified software.<p>I have a friend who worked with him and it was sort of Uncle Bob&#x27;s way or the highway.

This is sort of like how I develop using Jupyter notebooks. Write code in the notebook until I get a function &#x2F; component correct. Copy it into a module. Restart the kernel and import the module. Rinse and repeat.

That&#x27;s the similar to the issue I have with coding in (Jupyter) Notebooks. It <i>feels</i> productive, but it discourages modularity.

I rarely use REPL driven development, however in my limited experience using it, it only makes integration testing faster, not unit testing.<p>I used this methodology with a Slack bot, because doing integration testing with Slack is annoying when I&#x27;m not directly testing the Slack communication portion.<p>For example: <a href="https:&#x2F;&#x2F;github.com&#x2F;cjsaylor&#x2F;chessbot&#x2F;blob&#x2F;master&#x2F;cmd&#x2F;repl&#x2F;main.go" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cjsaylor&#x2F;chessbot&#x2F;blob&#x2F;master&#x2F;cmd&#x2F;repl&#x2F;ma...</a><p>Edit: It seems like there are a lot of comments surrounding him &quot;abandoning&quot; TDD. Not only did he not do that, he literally says in the conclusion of the article that he would not recommend doing it.

Some people really can&#x27;t stop making up new terms.

You still write tests in any non-trivial Clojure codebase, and you still probably do REPL-based development for some parts of that project.<p>And if you&#x27;re doing both of those things above, then you almost certainly run some or all of your tests WHILE doing REPL-based development from your always-on REPL. In fact, that&#x27;s one of the best ways since you don&#x27;t suffer the JVM startup cost.

Im not sure I agree with the conclusion.<p>Why not compose with the repl, then write tests at the end?<p>The common fear hear is that “you be motivated to write the test, or the test will be less good”<p>For motivation I never found it to be a big issue, and for the quality of the test, writing it after often produces better results. You get more time to think about _what and how_ you want to test

Using a REPL has been critical for me to develop any meaningful software (more than tests and more than types). I always wanted to be able to take a portion of my REPL history and transform it into a test, instead of basically rewriting it (lazy, I know).

&gt; So I’ve learned my lesson. REPL driven development feels easier and faster than TDD; but it is not. Next time, it’s back to TDD for me.<p><i>In the long run</i> it&#x27;s not faster. However, the feature he was using REPL driven development for did ship faster. That&#x27;s a valid tradeoff to make, as long as you&#x27;re doing it consciously.

What&#x27;s the difference? And why does executing commands (even if you&#x27;re actively developing the code they execute) in a terminal need a new name?<p>Isn&#x27;t this just...<i>using</i> a computer?<p>I don&#x27;t know; maybe I missed something.

I always have a REPL open when I am hacking. iPython is a great replacement for the vanilla Python one, and Pry is great for Ruby.<p>Being able to poke and prod at a system is priceless for debugging and introspection.

Literally an anti-hacker. Not sure why his writings get upvotes here

Do both? Lot of manual and automated testings?

It&#x27;s not REPL-driven design, it&#x27;s REPL-driven development. You don&#x27;t design by driving a REPL, that would be stupid. It seems Bob has lots of misconception and is blaming his poor design on the REPL. Haven&#x27;t read such a hollow article in a while.