5 ms·

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

by lvh 6y ago

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.

zelphirkalt 6y ago
This is a good point. In parenthetically (it is also about not using statements) inclined langs it is easy to select from start to end of an expression or subexpressions. I never feel that ease when working with a Python REPL, while it is a joy to work in Geiser usually. REPL is definitely not REPL.
gmfawcett 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      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?

by lvh 6y ago

zelphirkalt 6y ago

This is a good point. In parenthetically (it is also about not using statements) inclined langs it is easy to select from start to end of an expression or subexpressions. I never feel that ease when working with a Python REPL, while it is a joy to work in Geiser usually. REPL is definitely not REPL.

gmfawcett 6y ago

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 6y ago
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 6y ago
  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 6y ago
    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?