
REPL Driven Design - fredrb
http://blog.cleancoder.com/uncle-bob/2020/05/27/ReplDrivenDesign.html
======
jskulski
Bob Martin is myopic in his view of software, in a way that I think is harmful
to teams and the industry.

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/using. They understand it and each other. Good software is not
derived from a singular technique.

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.

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.

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's
not enough, he's actively saying it's not as good and you need to do The One
True technique.

~~~
sktrdie
I think Bob is a very insightful person and has great intuition and probably
more experience than any of us. Sure he has certain bias towards certain
things; who doesn't really?

Saying that his posts are harmful is a bit of a stretch.

~~~
Silhouette
_I think Bob is a very insightful person and has great intuition and probably
more experience than any of us._

Why on earth would you think that?

 _Saying that his posts are harmful is a bit of a stretch._

Mentor your first few people who keep defending rookie mistakes with "But
Uncle Bob said..." and you might change your mind about that.

Bob Martin says some sensible things, but he also says some things that are at
best debatable and at worst outright contradicted by the evidence base, and he
says all of them with great conviction and presumed authority so that his
target audience can't tell the difference. That alone makes him dangerous as a
source of advice.

------
samatman
There's no reason for this, and it bothers me enough that I'm doing something
about it.

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.

At which point, we should be able to say to the REPL: yes, this result is
correct, this is a test, and it's now called "Thing does what I want when I
give it X and Y".

The runtime then saves this as a test, and will run it automatically when you
ask it to. If there's a regression, it will boot back up into the interactive
REPL so you can inspect it and fix it.

I've been writing a REPL. Turns out that's a lot of work, but I'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.

~~~
danenania
The trouble is that for the repl “test” to be reproducible, you don’t just
need to store the relevant commands and result, but the full state/history of
the repl. Since the point of a repl is to explore and experiment, it seems
like your tests would end up with a lot of noise in them... but perhaps there
are ways to get around this? I agree the concept of quickly converting repl
sessions to tests is very compelling.

~~~
samatman
yes, there's a lot to it!

I store the complete repl history, complete with results and session metadata,
in a database.

Pruning a session's history down to only what's needed is a manual process,
true, and laying the groundwork to provide that feature has been the main yak
shave.

~~~
bch
> ...manual process, true

Before I get to my _real_ comment, I guess a fair criticism of it would be
“Well, where in the [development process] hierarchy do you actually want to
live?”, which I guess is a longer discussion, but as a developer, you can’t
become battle-hardened without going to battle. So we can nod to Carl Sagan[0]
and say “I made this from scratch”, and know there’s value in that. At least
occasionally running your REPLs by hand and taking the actual trip, instead of
just wanting the destination. It may not be tenable as a full-time production
development strategy, but that doesn’t mean it’s worthless.

[0] [https://youtu.be/7s664NsLeFM](https://youtu.be/7s664NsLeFM)

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

~~~
ch4s3
Yeah I agree. It almost feels like he's making the argument in bad faith, but
maybe he's actually unaware of the way in which you can back-fill tests?

~~~
goostavos
It does come off very strangely dichotomic. As though REPL driven means no
tests and bad practices, whereas TDD means tests and good practices?

As an idea, maybe we could do... both? Explore at the REPL, and then commit to
tests and clean up once you've solidified your approach (i.e. how most
Clojurists likely operate).

~~~
sanderjd
I think TDD purists seem to see no point in unit tests that are not written
before the code. That is, if the unit tests were not used to drive the design
and implementation of the code under test, they are useless. I find a lot of
value in the test driven approach, but this purist view does not make sense to
me. I sometimes, or often, write the code first (being able to do so in a repl
in languages that support that is even better), when I find it easier to think
through the problem in terms of implementation rather than expected output.
Sometimes I will then comment out the code and begin writing tests and re-
writing the code to pass them. I think that's what he should have done here;
he could have benefited from playing around in the repl, but reduced his fear
of refactoring later on by having the tests.

------
phoe-krk
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't he turn these into unit tests as he
programmed?

That's a simple lack of foresight on the programmer's side that is then blamed
on the tools that were used.

------
ARandomerDude
_Clean Code_ was one of the first books I read professionally, and I'm glad I
did. Since then, I've formed the opinion that "Uncle Bob" sometimes (as in
this case) takes helpful ideas a bit too far. But I'm still open to
correction.

Does anyone know of an open source codebase he's written or been a major
contributor to? I know he writes a lot _about_ clean code, but I've never seen
production code from him.

~~~
nojito
Clean Code is extremely overrated and it’s hard to get justifications for the
recommendations anymore.

Pretty sure he hasn’t written prod code in over a decade.

~~~
cjfd
Yes, especially where he goes completely overboard creating extremely small
functions. Most of them are, like, 2 lines....

The general point that code should be clean is a good point to make. Writing a
whole book about it seems a bit much.

~~~
nojito
>Yes, especially where he goes completely overboard creating extremely small
functions. Most of them are, like, 2 lines....

Yup which is why we have millions of npm packages that do literally one thing.

~~~
capableweb
Two completely different things. A npm package is a module of code. A function
is... A function. Having a lot of small functions is helpful as it builds up a
vocabulary in the codebase, so instead of having to understand every single
line each time you come across it, you can extract the meaning into a name.

What the npm ecosystem is doing is a completely different thing.

~~~
inertiatic
>so instead of having to understand every single line each time you come
across it, you can extract the meaning into a name.

Until you really have to understand what is going on, like when you need to
fix a bug or refactor. Then suddenly you to deal with the overhead of holding
the branches of 20 levels of indirection in your working memory.

Also, this assumes the people you're working with are _great_ at naming
things. Which, from my experience, is almost no one.

~~~
capableweb
In general, we have higher-level programming languages so we can do just this,
hide the complexity under indirection. It's basically the purpose of the
languages we tend to use today, otherwise we would all be still using
assembly.

Your job as a programmer is being able to walk this ladder of indirection up
and down until you find what you seek and fix/add/remove whatever.

You'll always be dealing with way more than 20 levels of indirection when
programming, even with a "hello world" program. If adding two more levels of
indirection makes your mental model break down, you might consider upgrading
your environment/workflow a bit to support this.

Regarding naming I agree with you. Good names are really, really, really hard
to come up with. Entire books have been written on how to name things. Doesn't
excuse us from trying though, the only way we can get better is by doing.

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

------
ch4s3
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't do that,
but Ruby and Elixir devs often do. I would imagine he's familiar with that
approach.

~~~
mping
Clojure folks do that. Don't know about all of them, but lots of them do. You
even have emacs cider shortcuts to run tests from a live repl.

~~~
emidln
I literally wrote code in .clj files and then my editor can slurp that up and
barf it into a repl. There was never a point where I was writing something
that "only existed in the repl" such that I couldn't just put it in a unit
test if it needed formalized.

The usual workflow was something like

    
    
        (comment
        
           ;; experiments go here
           (defn add [a b]
             (+ a b))
    
           (= 2 (add 1 1))
           (= 3 (add 1 2))
           (= 99 (add 9 90))
    
        )
    

Once you have what you want, you move the code out of the comment block.
Whether you move it into a library or a test file is just dependent on the
type of thing you're moving. Functions moved into library code. The samples
that proved the happy paths (or unhappy paths) would go into test files using
`clojure.test/is` (and typically a direct copy/paste).

------
gumby
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.

A few years later a friend referred to this dismissively as “Programming by
successive approximation.”

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.

Even though I do most of my work in compiled C++, my work model isn’t that
different.

~~~
cozzyd
You can use ROOT (or cling standalone) as a C++ REPL if you want to. It works
surprisingly well, at least until you segfault it.

~~~
gumby
Thanks! ROOT itself looks interesting too.

------
kitanata
Is this just the equivalent of saying "Hey, REPLs are nice when you're trying
to figure something out", but spouted off as some deep programming wisdom?

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.

Like.. how is this a deep profound revelation for folks?

------
frou_dh
I think there's a big distinction in the general developer population between:

a) Knowing both how to effectively write tests & how to effectively use a
REPL.

and:

b) Knowing only how to bang around in a REPL enough to use it as a crutch to
avoid writing any tests.

~~~
lvh
When you say "use a REPL", do you mean something like CIDER/SLIME, or do you
mean something like ipython/irb? I do REPL (that is: CIDER) driven development
all the time, and most of my experiments turn into tests quite naturally.

~~~
gmfawcett
The distinction is a bit artificial. I agree that Python's REPL is
underpowered when compared with SLIME. But it's trivial to write up a bit of
Python code in an editor, and just 'reload(modname)' or
'exec(file(...).read())' from the REPL. Emacs' python-mode (like many other
editors) also supports "evaluate this expression / line / block" to make this
process simpler. YMMV, but my Common Lisp development really doesn't look very
different from my Python work.

~~~
lvh
Even if we stipulate that's true[ _], saying you could do it in non-Lisps
doesn 't detract from the observation that virtually nobody actually does it,
while both groups still call it "REPL".

[_] I really don't think it is: reload(mod) comes with way more caveats than
C-c C-k in CIDER.

~~~
gmfawcett
How could you possibly know that "virtually nobody actually does it"? I have
no reason to believe that I'm a special snowflake. 'reload' and 'exec' exist
for these very purposes, and have been around since Python immemorial (well,
at least since I started using Python 20 years ago). As for the 'caveats': if
you're using 'reload' in your development process -- yes, you should take a
few moments to read the documentation first, as you should with anything else.
It isn't magic, and its behaviour is well explained.

You're making far too much of the distinction between different kinds of REPL.
As Peter Norvig put it [1], as long as you have a "development process that
allows for rapid development with continuous improvement", minor distinctions
between languages [such as quibbles over how 'reload' works] really don't
matter that much.

Squeeze all the power out of the tools that you use, and get things done --
ultimately that's all that matters. Religious wars like these were tiresome in
the era of the Smug Lisp Weenie, and they haven't improved with age.

[1]
[https://news.ycombinator.com/item?id=1803815](https://news.ycombinator.com/item?id=1803815)

~~~
lvh
I made a distinction between CIDER/SLIME (which I think is what most Lisp
users think of when they hear REPL-driven development) and ipython/irb/iex...,
which I think is what most Python/Ruby/Elixir/... programmers call "REPL" in
REPL-driven development. This distinction is important, because much of the
criticism in these threads has been around how you translate REPL-developed
code into saved-in-files code. If I'm using, say, Jupyter Notebook, I'd say:
yes, that's exactly an issue I've had and can immediately identify -- but with
my CIDER "REPL-driven" flow, that's not an issue at all. You don't need to
declare superiority of one to observe that they are different. I am pointing
out one highly contextualized advantage, yes, but I did not anoint CIDER the
One True Way. There are advantages to Jupyter Notebooks compared to REPL-
driven development too. I think calling my commentary a "religious war" is
unnecessarily inflammatory.

You ask how I could know that: I have used Python for a similar amount of time
as you, and have been a Fellow of the PSF for about a decade. During that time
I've attended dozens of PyCons across the world. My wife is the Executive
Director of the PSF, so I've been the second person in and the penultimate one
out for most of those PyCon USes, including the post-conference sprints.
Previously, I was the Freenode group contact for and one of the most active
contributors to #python. I've worked with a lot more Python programmers than
most, and typically meeting them where _they are_: either pairing next to them
or over IRC. People from all over the world and different experience levels
and backgrounds. People who lived and breathed Emacs and are definitely aware
of how SLIME/inferior processes work. I can't recall a single instance where
someone said "eval this in a REPL" and the other party did that by calling
reload() or exec from an editor. The vast majority of times someone mentioned
reload(), it's been someone who built a long-lived process like an IRC bot,
with hot code reloading via reload(), being confused that reload() "didn't
work" because they kept seeing the old behavior. YMMV. This is all anecdata,
sure, but I observe that IPython 5 casually broke inferior-shell compatibility
and somehow that made it to release. It's possible that there are huge swathes
of people who do write their own "trivial" reload()/exec integration, but that
feels like the stronger claim to me than "there may be confusion here between
what users of these languages typically mean when they say REPL".

I want to make sure I understand your argument correctly. Starting with the
strongest form of the argument: are you saying you believe most Python/...
programmers think "REPL" means "something involving reload" and not, say,
ipython? I assume we can agree that seems silly, but perhaps not: and I think
that's closest to directly refuting my claim. Unless I'm misreading your
comment: I'm saying "different groups use this term to mean different things",
and your comment is "come on they are practically the same" (ok, fine, we can
disagree!) and "you can do reload()!" (sure, but I didn't say it's impossible,
I said that's not what people generally mean). So, perhaps a weaker version of
your argument: you're saying you think some nontrivial amount of Python users
use a reload/exec-based editor integration? Enough that "REPL" is not suddenly
a confusing term? So, something like what, 20%, 10% of users?

~~~
gmfawcett
Fair point about my religious-war comment, and I apologize. I was probably
deserving of the Smug Lisp Weenie label at one point in my career, and for
whatever irrational reason your comment sparked those memories. (For what it's
worth, while I don't use Clojure any more (and stopped before the CIDER days)
I'm fairly familiar with the language -- I was even a core contributor for a
brief shining moment. (I think my contribution was the :as clause in (use)
statements. The old (use) clauses used to be horrendously long. No doubt that
my code has been replaced 10 times over by now.)) At any rate, it was foolish
of me to try suppressing a religious war by inciting one.

As for my argument, I think it was in two points. First was to challenge what
evidence you had to support your claims. From your reply, I'm confident from
that you're speaking from knowledge of many developers' experiences. Perhaps I
am more of a special snowflake than I realized.

As for the second point, I'm basically restating Norvig's argument, as I think
it's a good one. I'm not terribly concerned about distinctions between
different REPL-ish tools. I do take your point that the distinctions can muddy
conversation, e.g. when trying to relate experiences of (say) Jupyter users
vs. `python-mode` users -- or worse, Lisp vs. Python.

But to paraphrase (co-opt?) Norvig, I think these are second-order
differences. Important enough in a few contexts, but distracting in most. My
thesis is simple: everyone should experience interactive programming, and
should ideally incorporate it into their development process, because it makes
development faster and more effective. Whether that means Jupyter, CIDER,
SLIME, ghci, etc. is a local decision, based on where you're at and what your
community is; I don't think "REPL" in particular is a special shibboleth of
the Enlightened. The difference between the Java/C++/Rust set and the
Python/Ruby/CL/Clojure set is far greater than any minor differences we might
have within the interactive camp, and "internal" disagreements in front of the
unindoctrinated tend to distract from the greater good, IMO.

Any way that we can help new developers to experience interactive programming
is a positive step. Personally I think _that 's_ the first-order problem, and
I think our collective, repeated failure to recognize that is a source of much
pointless and religious argument. Perhaps that's why this conversation
reminded me of those wasted days, and why I responded with more aggression
than I should have.

~~~
lvh
Apology accepted: I completely understand why a reasonable person could infer
those things, especially since I'm hardly a neutral party given that I founded
a Clojure nonprofit--"partisan" would be an entirely fair assumption :-)

I also happily stipulate that non-Lisps not working that way is largely praxis
and not some fundamental language deficiency, and definitely strongly agree
that interactive programming is a powerful tool we should get into more hands.

------
wglb
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 "At least he had the
courage to post his failure".

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.

TDD isn't going to find solutions to hard problems beyond bowling.

There is a stark contrast between agile development and actual software
engineering. Agile works where the customer and the developer don't really
know what is being developed.

And as much as he has lectured about software development, I don't get the
feeling that he has actually developed a substantial quantity of serious
software.

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.

I have a friend who worked with him and it was sort of Uncle Bob's way or the
highway.

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

~~~
nerdponx
Yup, a notebook is a REPL with better scrollback + the ability to take notes
alongside your code.

~~~
smabie
Except unlike a REPL, all your code is still there so that you eventually find
yourself in an unreproducible state that on the surface looks reproducible.
Referencing variables that don't exist in the notebook (only to be caught when
run by someone else), cells that need to be executed out of order, etc. The
problems go on and on. People sometimes go days or weeks without restarting
their notebook and the amount of "shadow" state is remarkable.

I think notebooks are useful (though only for exploratory analysis), but there
has to be a better way.

~~~
EForEndeavour
Part of the problem is discipline and avoiding anti-patterns. It's unfortunate
that Jupyter encourages this kind of inconsistency to creep in, leaving it up
to the analyst to maintain top-to-bottom "runnability".

------
xapata
That's the similar to the issue I have with coding in (Jupyter) Notebooks. It
_feels_ productive, but it discourages modularity.

~~~
zelphirkalt
Not sure it really discourages modular code. I usually write code modularly in
Notebooks as well, but not sure how this is for most people.

~~~
Jtsummers
I suspect the problem is less that it discourages than that it does not
encourage.

Which gets back to the posted article. REPL-driven development permitted him
to feel confident without doing his usual process, it didn't _discourage_
decoupling, but it didn't _encourage_ decoupling either. TDD, to be done well,
almost requires decoupling your code to make it more testable.

The same may (I'm not sure I agree, but I've never used Jupyter notebooks) be
true of using notebook-styled development approaches and modularity. If the
workflow permits relatively easy (and mostly safe) development without
encouraging modularity, then it's incumbent on the developer to bring that
discipline into the workflow.

~~~
xapata
And unfortunately, most of the new crop of programmers don't have that
discipline. I tell them to write tests and they eyeroll when they think I'm
not looking.

------
cjsaylor
I rarely use REPL driven development, however in my limited experience using
it, it only makes integration testing faster, not unit testing.

I used this methodology with a Slack bot, because doing integration testing
with Slack is annoying when I'm not directly testing the Slack communication
portion.

For example:
[https://github.com/cjsaylor/chessbot/blob/master/cmd/repl/ma...](https://github.com/cjsaylor/chessbot/blob/master/cmd/repl/main.go)

Edit: It seems like there are a lot of comments surrounding him "abandoning"
TDD. Not only did he not do that, he literally says in the conclusion of the
article that he would not recommend doing it.

~~~
capableweb
What languages have you tried REPL driven development with? As far as I know,
Golang doesn't have a REPL that is connected with your editor so you can
evaluate inline code and Golang is not made for REPL driven development
either, so you have bunch of implicit state and you can't overwrite function
definitions at runtime either.

I think you need to have a language (or structure your particular program in a
way) that is really made with live-coding in mind for it to actually give you
any benefits, like Smalltalk or Clojure and similar. Otherwise it's just
adding another step to reach the real program you're running.

Edit: using your example as an example here, hope you don't mind. A program
made with REPL driven development would have way less code in the main
function, in order for you to test the code outside with your REPL. The
`StoreGame` function would accept a data-store + the argument you have now, so
at development-time, you can pass it arbitrary stores. And similar changes.

~~~
cjsaylor
I don't mind the criticism at all. I don't use it often enough to claim
expertise. Fair points about my usage.

You can still get proper editor support with Golang (even though it isn't
designed for it). I've done so here with VSCode working with a "remote" delve
session:
[https://github.com/cjsaylor/chessbot/blob/11e1059aa77fed84d2...](https://github.com/cjsaylor/chessbot/blob/11e1059aa77fed84d20f03ce2cad06bb87e313da/.vscode/launch.json#L7-L18)

~~~
capableweb
Thanks :)

My point being, if you wanted to execute the following code:
[https://github.com/cjsaylor/chessbot/blob/11e1059aa77fed84d2...](https://github.com/cjsaylor/chessbot/blob/11e1059aa77fed84d20f03ce2cad06bb87e313da/cmd/repl/main.go#L128-L132)

You probably wouldn't be able to, without restructuring how you're handling
your state that is being used there. A REPL driven made program usually is
made that the runtime carries the state and exposes it, so you could just
select that part and run it, and see the output of it.

I'm guessing delve is more like a traditional debugger that steps through each
line, rather than an REPL, correct?

~~~
cjsaylor
Correct, but it does allow you to modify values in memory, so you could do the
branching and state changes as you go. I admit I could have made that flow
more "editable" from the debugger/REPL, however it did serve its purpose in
terms of prototyping ideas before I integrated them into the real thing. I
also do use it to debug weird state things of issues reported to me, which I
do mess with the values at runtime with Delve to simulate.

I may be misunderstanding the "true" REPL development here, but I think the
points laid out by the article seems to match my experience to a degree.

~~~
capableweb
That's interesting, didn't know that! Thanks for sharing. I don't think there
is anything that is more "true" than something else, it's just varying degree
of personal productivity and in the end we all work very differently, so one
size does not fit all. I'm glad you're sharing your thoughts with me and seems
to be similar to the REPL environment I'm running myself.

~~~
cjsaylor
I looked into this subject a bit more deeply in regards to Go, and you are
right. Go doesn't have a REPL built in, and most of the implemented REPLs only
work off of stdin. So, the Clojure style of REPL development is not as
straight-forward in Go. However, it does seem like one of the userland REPLs
could be adapted to work with an editor (like vscode) if the input source
wasn't locked to stdin.

It seems like a ripe target for an opensource library to accomplish this. I
may explore this later on when I have more time to devote.

------
TurboHaskal
Some people really can't stop making up new terms.

~~~
mac01021
Some people really can't stop discovering new concepts?

------
blunte
You still write tests in any non-trivial Clojure codebase, and you still
probably do REPL-based development for some parts of that project.

And if you'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's one of the best ways since you don't suffer the JVM
startup cost.

------
stopachka
Im not sure I agree with the conclusion.

Why not compose with the repl, then write tests at the end?

The common fear hear is that “you be motivated to write the test, or the test
will be less good”

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

------
shay_ker
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).

------
brlewis
> 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.

 _In the long run_ it's not faster. However, the feature he was using REPL
driven development for did ship faster. That's a valid tradeoff to make, as
long as you're doing it consciously.

------
meddlin
What's the difference? And why does executing commands (even if you're
actively developing the code they execute) in a terminal need a new name?

Isn't this just... _using_ a computer?

I don't know; maybe I missed something.

~~~
michaelmrose
It needs a name so that we can have this discussion and compare and contrast
different methodologies.

For example

* Compile run debug. You write some code potentially with tests. Run it and either poke it manually or run tests to see what it did. If it didn't do what was expected you either edit it, write some more tests, add print statements, add break points or whatever and try again.

You are forced to create all state in one go and pay one complete edit build
debug cycle for each thing you want to modify in isolation. This could be 30
seconds or hours.

* Minimal interactive development. You mostly write code as above but gain the ability to poke individual functions or pieces of functionality in order to aid your understanding when things don't work correctly. You write tests eventually or not.

* Repl driven development. You mostly write and interact with a live environment either by actually typing the code in a repl or writing it into a source code file and hitting a shortcut to evaluate as you make changes redefining it piece by piece in terms of the rest of the code and the state you have built up by prior evaluations. This persistent state and the ability to redefine parts of it are what separates it from writing some python and occasionally opening up ipython to poke the code.

------
whalesalad
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.

Being able to poke and prod at a system is priceless for debugging and
introspection.

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

------
hartator
Do both? Lot of manual and automated testings?

------
skratlo
It's not REPL-driven design, it's REPL-driven development. You don'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't read such a hollow article
in a while.

~~~
wglb
I agree with hollow.

But TDD is not design either, in my opinion.

