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

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?