As said by @vvvvalvalval the Stuard Halloway talk is very elucidative, in showing that the Clojure REPL is more than a simple console or shell as we find in other languages. Follow the transcript of the video as well: https://github.com/matthiasn/talk-transcripts/blob/master/Halloway_Stuart/REPLDrivenDevelopment.md
I still donât get it.
Most of what is mentioned in @vvvvalvalval article and in Stuartâs talk seem to be available in ruby (irb) and node.js console.
Could you give concrete examples of valuable tasks that can be donei in Clojure REPL but not in irb and node.js console.
Open a REPL against a running system and change code and state in realtime. Ruby and NodeJs shells only allow you to run interactive examples, but doesnât allow you to get session attached to program process and start to change the program while it is running.
I donât think so, actually.
I donât know too much about Rubyâs IRB; but I think it suffers from many limitations, as indicated by the mere existence of Pry. So we might as well ask that question of Pry instead of IRB. From what I understand of Pry, itâs good at letting you interact with an existing combination of code and state, but not much so at letting you change the code while preserving the state - although I see there is some support from that, so I might be wrong. You use it more to understand programs than to interactively reshape them IMO.
About Node.js however, I can tell from experience: it doesnât let you âput yourself in the shoesâ of your code. Thereâs no equivalent of in-ns
in the node.js shell. Iâve tried really hard to get the same power from the Node.js shell as I had from Clojure, and always failed because of this limitation.
Itâs also worth noting that neither Ruby nor JavaScript have the âdata notationâ story of Clojure. That turns out to be important to the REPL experience, because having the same syntax for code, data notation AND data visualization accounts for a lot of the âseamlessnessâ of the REPL experience of Clojure.
Finally, itâs important to mention a more down-to-earth, but important aspect, which is editor integration - you gain a lot of focus from the ability to evaluate expressions directly from your editor buffer.
As always with comparing technologies, please donât interpret this as a proof that Clojure offers a superior REPL experience - I donât believe in such theoretical proofs for comparing languages, where the most important factors lie in the practical details. The only reasonable proof is thorough experience using all alternatives - I canât claim that for Ruby, I somewhat can for Node.js.
Please do keep challenging the argumentation if youâre not convinced - it should help me make the article better!
âThe main reason you end up doing that in imperative languages is to enforce boundaries between components. However, immutable data structures already facilitate low coupling by design.â
Thatâs a terrific point, and not one that I had thought of when considering microservices in clj/s. Thanks!
What do you mean by that?
Can you give an example of when in a Clojure REPL, one can change the code while preserving the state?
-
Say youâre exploring a payment API, requiring to perform a succession of requests to complete a purchase flow. You craft the first request, save it in a def, write some code to make the first HTTP call, and save the response in a Var. You then iteratively write some code based on that Var to access the data of interest in the response until you get it right, make the second HTTP request, save the result in a Var, etc. These Vars are some local, transient state you use as checkpoints while youâre changing the code towards correct behaviour.
-
Youâre debugging an error in your code. You locate where in the code you think the error is; you reproduce the context (~state) of the code during the error either by hand or using a tool like scope-capture. You make changes to the code, experimenting on that saved state in the REPL, until you get the desired behaviour.
What are the alternatives in languages without this interactive story? You get to either change the code without preserving any state (auto-reload) or observe the state without the ability to change the code (debuggers). Preserving state is especially important when development / debugging gets you answers through multi-steps manipulations, which require improvisation.
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.