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.
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.