3 ms·

This is confusing to me. How is this better than tests that do the exact same work (document how to use a function, and provide setup to make iterating on a fun

This is confusing to me. How is this better than tests that do the exact same work (document how to use a function, and provide setup to make iterating on a function easy)?

orestis 6y ago
The difference is solely on the workflow. Using the rich comment approach you setup some state, fiddle around, change a function, invoke it again, store some arguments in a variable, change the function again, split it into two functions and so on. It is advised that once things stabilize you take your learnings and stuff them into a unit test for posterity.
EsotericAlgo 6y ago
It's not better if you have an environment that allows easy iterative function development. This is just a way to achieve that. However, combined with some of the other clojure niceties (namely cider and structural editing) it does make it a better experience for me. It allows me to maintain a better flow as I can maintain REPL state if needed(especially if it's a quick hack where dependency injection like component isn't worth the overhead). When I'm done exercising the code I can just make minimal changes to make the comment a test, leave it in place, or move it over to a bag-of-tricks user.clj.
Scarbutt 6y ago
Clojure's very slow startup forces you to this workflow, relying entirely on the REPL to compensate. It's not any better compared to a language with a fast change-test-debug cycle.
- iLemming 6y ago
  That's not true. There are plenty of other Lisp dialects with a faster startup time - Chez, Fennel, CL, etc. You still would want REPL-driven-workflow. Practically, it's the other way around: Clojure's slow startup time doesn't matter because it's a Lisp, and no other non-homoiconic language (except maybe Smalltalk) gives you the productivity boost that "true REPL" allows, no matter how fast change/test/debug cycle is. Because it's not just about fast cycle, with non-homoiconic languages that do not have "true REPLs" you also have to think about the program's state and other things. Homoiconicity of Lisp allows you to evaluate any expression or sub-expression without any kind of ceremony. Other languages do not have the luxury of giving you the answer right away. There's always some "ritual" involved, automated or not, but it is still required, but in a Lisp connected to a REPL, you immediately get the answers.

This is confusing to me. How is this better than tests that do the exact same work (document how to use a function, and provide setup to make iterating on a function easy)?

orestis 6y ago

The difference is solely on the workflow. Using the rich comment approach you setup some state, fiddle around, change a function, invoke it again, store some arguments in a variable, change the function again, split it into two functions and so on. It is advised that once things stabilize you take your learnings and stuff them into a unit test for posterity.

EsotericAlgo 6y ago

It's not better if you have an environment that allows easy iterative function development. This is just a way to achieve that. However, combined with some of the other clojure niceties (namely cider and structural editing) it does make it a better experience for me. It allows me to maintain a better flow as I can maintain REPL state if needed(especially if it's a quick hack where dependency injection like component isn't worth the overhead). When I'm done exercising the code I can just make minimal changes to make the comment a test, leave it in place, or move it over to a bag-of-tricks user.clj.

Scarbutt 6y ago

Clojure's very slow startup forces you to this workflow, relying entirely on the REPL to compensate. It's not any better compared to a language with a fast change-test-debug cycle.

iLemming 6y ago
That's not true. There are plenty of other Lisp dialects with a faster startup time - Chez, Fennel, CL, etc. You still would want REPL-driven-workflow. Practically, it's the other way around: Clojure's slow startup time doesn't matter because it's a Lisp, and no other non-homoiconic language (except maybe Smalltalk) gives you the productivity boost that "true REPL" allows, no matter how fast change/test/debug cycle is. Because it's not just about fast cycle, with non-homoiconic languages that do not have "true REPLs" you also have to think about the program's state and other things. Homoiconicity of Lisp allows you to evaluate any expression or sub-expression without any kind of ceremony. Other languages do not have the luxury of giving you the answer right away. There's always some "ritual" involved, automated or not, but it is still required, but in a Lisp connected to a REPL, you immediately get the answers.