3 ms·

Unit testing doesn't provide the level of interactivity a REPL does. A REPL lets you see the output of parts of an unfinished function based on the running prog

by Zak 2mo ago

Unit testing doesn't provide the level of interactivity a REPL does. A REPL lets you see the output of parts of an unfinished function based on the running program's state. If you've already thought out the whole program before you start writing it, that may not be as valuable. In my experience, software often isn't that way and the ease of exploration a REPL and long-running process provide are unmatched.

bluGill 2mo ago
yes and no. You are correct the REPL provides more interactivity. However the downside is you can break something that used to work while make something else work. There is no reason you can have a REPL and unit tests in the same. Every change results in running all the tests. (of course most changes are syntax error - just "if foo()" is 7 syntax errors. ) I've seen various attempts of this over the years, but quickly your code becomes more complex than the computer can run while you type and you fall back to running most of the tests after in some way.
- stackghost 2mo ago
  >I've seen various attempts of this over the years, but quickly your code becomes more complex than the computer can run while you type and you fall back to running most of the tests after in some way. That does not match my experience with lisp.
  - jottinger 2mo ago
    Mine, either.
  - bluGill 2mo ago
    My last experience with lisp was assignments in college which are too small to count as anything more than a toy problem. For real world code in other languages I've worked with the complexity of the problems demands so much code that the REPL cannot keep up.
    - Zak 2mo ago
      > the complexity of the problems demands so much code that the REPL cannot keep up. Now we disagree, at least in part. REPL-driven development is in part about incrementalism. You wouldn't run all the complex code every time you want to examine some state or try out an experiment. You would run it once at the start of your session, then compile just the definition you're editing with your editor's equivalent of `compile-defun`. Of course that breaks if you're making changes that touch a bunch of different areas of your program and require rebuilding all the state, but it's usually a mistake to design programs in a way that would make such an issue frequent.
- Zak 2mo ago
  I think we're largely in agreement here. Unit tests and REPLs serve different purposes and are poor substitutes for each other; red_admiral was arguing that unit tests obviate the need for REPLs.
- smaudet 2mo ago
  REPL isn't just more ineractive, it's open ended. I.e. you could execute a unit test in a REPL (after e.g. loading the test), but you can't run a REPL in a unit test - you can debug a test and maybe do some REPL like things, but, it's not the same at all... You also can't write a unit test in a unit test, you can in a REPL. Heck, an AI chatbot is a (non deterministic) REPL (it reads, evaluates, and prints something)... Like others were saying, they are different, i.e. nothing at all alike, tests do not obviate REPLs...

by Zak 2mo ago

bluGill 2mo ago

yes and no. You are correct the REPL provides more interactivity. However the downside is you can break something that used to work while make something else work. There is no reason you can have a REPL and unit tests in the same. Every change results in running all the tests. (of course most changes are syntax error - just "if foo()" is 7 syntax errors. ) I've seen various attempts of this over the years, but quickly your code becomes more complex than the computer can run while you type and you fall back to running most of the tests after in some way.

stackghost 2mo ago
>I've seen various attempts of this over the years, but quickly your code becomes more complex than the computer can run while you type and you fall back to running most of the tests after in some way. That does not match my experience with lisp.
- jottinger 2mo ago
  Mine, either.
- bluGill 2mo ago
  My last experience with lisp was assignments in college which are too small to count as anything more than a toy problem. For real world code in other languages I've worked with the complexity of the problems demands so much code that the REPL cannot keep up.
  - Zak 2mo ago
    > the complexity of the problems demands so much code that the REPL cannot keep up. Now we disagree, at least in part. REPL-driven development is in part about incrementalism. You wouldn't run all the complex code every time you want to examine some state or try out an experiment. You would run it once at the start of your session, then compile just the definition you're editing with your editor's equivalent of `compile-defun`. Of course that breaks if you're making changes that touch a bunch of different areas of your program and require rebuilding all the state, but it's usually a mistake to design programs in a way that would make such an issue frequent.
Zak 2mo ago
I think we're largely in agreement here. Unit tests and REPLs serve different purposes and are poor substitutes for each other; red_admiral was arguing that unit tests obviate the need for REPLs.
smaudet 2mo ago
REPL isn't just more ineractive, it's open ended. I.e. you could execute a unit test in a REPL (after e.g. loading the test), but you can't run a REPL in a unit test - you can debug a test and maybe do some REPL like things, but, it's not the same at all... You also can't write a unit test in a unit test, you can in a REPL. Heck, an AI chatbot is a (non deterministic) REPL (it reads, evaluates, and prints something)... Like others were saying, they are different, i.e. nothing at all alike, tests do not obviate REPLs...