7 ms·

REPL is a killer Clojure feature that nobody (outside the ecosystem) talks about. Probably it's hard to comprehend what developing in a REPL feels like, majorl

REPL is a killer Clojure feature that nobody (outside the ecosystem) talks about. Probably it's hard to comprehend what developing in a REPL feels like, majorly because no other commercial language has a REPL as powerful as Clojure. I gave a talk[1] explaining the REPL and most people in the audience (including senior Java, C# and Python developers) had never seen something like that before. REPL is the reason why I (and perhaps other Clojure devs) endure the pain around Clojure tooling, demand, supply and ecosystem in general. [1] https://www.youtube.com/watch?v=Bs44qdAX5yo https://www.youtube.com/watch?v=Bs44qdAX5yo

snorremd 7y ago
Everytime I've singled out the REPL as why I like Clojure so much when explaining why Clojure so great to my friends they seem to mention that other languages have repls too. Like F# or JavaScript. When I counter that Clojure's REPL is connected to the running app instance they are developing I don't think they really understand. Perhaps this is one of those things that you just have to try out to grok.
- wtf_srsly 7y ago
  As is javascript. Have you ever tried debugging an application with Chrome ? I frequently use the "pause on exception" feature of the debugger or also place breakpoints strategically and then use the console as REPL for further debugging.
  - ss3000 7y ago
    I think the "_running_ app instance" is the key distinction here. Breakpoints require halting your system, so while you can inspect the system's state, you can't meaningfully alter it as you could with the kinds of Clojure REPL workflows talked about here. Another limitation is that you can't really inspect parts of your system outside the context of the currently running function where the breakpoint was triggered. I think debugging with state-preserving hot reloading in UI development is probably the closest analogue I've encountered to debugging workflows with a Clojure REPL, though it's still nowhere near as flexible.
    - lispm 7y ago
      > Breakpoints require halting your system, so while you can inspect the system's state, you can't meaningfully alter it as you could with the kinds of Clojure REPL workflows talked about here. Fix and continue. Various language implementations provide that.
      - ss3000 7y ago
        That's altering the _code_ as opposed to altering the _state_ of the system.
        lispm 7y ago
        Just change the state, too. Many languages/implementations provide that.
  - kqr 7y ago
    One difference is that you might then be debugging compiled, possibly even modified JS. The Lisp REPL deals in the original Lisp source code.
S4M 7y ago
> I gave a talk[1] explaining the REPL and most people in the audience (including senior Java, C# and Python developers) had never seen something like that before. I find that quite surprising, as I use the REPL a lot when coding in Python.
- kqr 7y ago
  There are big differences in capabilities between the Python REPL and a Lisp REPL.
  - aerique 7y ago
    Even then the Python REPL can be quite useful but I do not expect most Python developers to use it. (This is from personal observations as a Common Lisp enthousiast.)
mtreis86 7y ago
> no other commercial language has a REPL as powerful as Clojure Except for other Lisps like CL
- lispm 7y ago
  Smalltalk.
  - shivekkhurana 7y ago
    My use of the word "commercial" is not apt. I meant to say "mainstream" languages.
    - lispm 7y ago
      That would exclude Clojure, too.
      - yogthos 7y ago
        Seeing how Clojure is actively used at places like Apple, Amazon, Atlassian, and even Walmart where software development isn't even their primary business, I think it's pretty safe to call it mainstream.
        lispm 7y ago
        I would call languages like Java, Javascript, Python, C++, C# 'mainstream'. But not niche languages which have 1/100ths or less of open positions. Monster lists 68000 positions after a search for 'Java', and 180 for 'Clojure'.
        yogthos 7y ago
        I would call any language that's actively used in the industry with a large and active community mainstream. Restricting the term mainstream to a handful of most used languages is pretty silly in my opinion.
jcadam 7y ago
When I started learning/using Clojure, I didn't use the REPL much and kept on working in the traditional way: Write code, compile, test. Repeat until it works. It took some time to break my old habits and start using the REPL. It's unfortunately made me a bit lazier writing unit tests :), as I can hammer on a piece of code until I know it works - and small, deterministic functions tend to not break once you get them working. So much of my test code is integration tests. Nowadays, when I have to work in Java (or Scala, Javascript, Python, etc), I seriously miss the Clojure REPL. Though Clojure (and Lisp in general) has definitely affected the way I write code in other languages.
Scarbutt 7y ago
A good REPL is nice, but its hardly a killer feature or a big productivity boost. If Clojure didn't have a REPL it would have been completely dead by now cause its startup time is really bad. Clojure needs to have a REPL in order to survive (which is barely doing). Programmers are equally productive[0] (or way more because of their big ecosystems) in languages that have a fast code-run cycle. [0] https://groups.google.com/forum/#!topic/comp.lang.lisp/L5dZ-j6Id-s%5B76-100%5D https://groups.google.com/forum/#!topic/comp.lang.lisp/L5dZ-...
- deleted 7y ago
  [deleted]
- yogthos 7y ago
  REPL driven workflow allows me to put the application in a specific state, and then continue developing features against that state. If you have to restart the application each time you make a code change then you have to rebuild that state each time. This creates a much slower feedback loop, especially when you're working on large applications. Furthermore, the REPL is a fantastic tool for troubleshooting live systems in production, and in some cases even patching them with zero downtime. I don't know a single person who's worked with this workflow on a serious project and would want to go back to compile/run cycle afterwards. Meanwhile, Clojure leverages host ecosystem getting all the same benefits as any other language running on it.
- wglb 7y ago
  >Programmers are equally productive[0] (or way more because of their big ecosystems) in languages that have a fast code-run cycle. I would disagree with this. I feel much more productive in Lisp than, e.g. go or C or C++. In Smalltalk, the productivity was so great that I was dead tired after 8 hours, as it was all thinking and effectively zero compiling.

snorremd 7y ago

Everytime I've singled out the REPL as why I like Clojure so much when explaining why Clojure so great to my friends they seem to mention that other languages have repls too. Like F# or JavaScript. When I counter that Clojure's REPL is connected to the running app instance they are developing I don't think they really understand. Perhaps this is one of those things that you just have to try out to grok.

wtf_srsly 7y ago
As is javascript. Have you ever tried debugging an application with Chrome ? I frequently use the "pause on exception" feature of the debugger or also place breakpoints strategically and then use the console as REPL for further debugging.
- ss3000 7y ago
  I think the "_running_ app instance" is the key distinction here. Breakpoints require halting your system, so while you can inspect the system's state, you can't meaningfully alter it as you could with the kinds of Clojure REPL workflows talked about here. Another limitation is that you can't really inspect parts of your system outside the context of the currently running function where the breakpoint was triggered. I think debugging with state-preserving hot reloading in UI development is probably the closest analogue I've encountered to debugging workflows with a Clojure REPL, though it's still nowhere near as flexible.
  - lispm 7y ago
    > Breakpoints require halting your system, so while you can inspect the system's state, you can't meaningfully alter it as you could with the kinds of Clojure REPL workflows talked about here. Fix and continue. Various language implementations provide that.
    - ss3000 7y ago
      That's altering the _code_ as opposed to altering the _state_ of the system.
      - lispm 7y ago
        Just change the state, too. Many languages/implementations provide that.
- kqr 7y ago
  One difference is that you might then be debugging compiled, possibly even modified JS. The Lisp REPL deals in the original Lisp source code.

S4M 7y ago

> I gave a talk[1] explaining the REPL and most people in the audience (including senior Java, C# and Python developers) had never seen something like that before. I find that quite surprising, as I use the REPL a lot when coding in Python.

kqr 7y ago
There are big differences in capabilities between the Python REPL and a Lisp REPL.
- aerique 7y ago
  Even then the Python REPL can be quite useful but I do not expect most Python developers to use it. (This is from personal observations as a Common Lisp enthousiast.)

mtreis86 7y ago

> no other commercial language has a REPL as powerful as Clojure Except for other Lisps like CL

lispm 7y ago
Smalltalk.
- shivekkhurana 7y ago
  My use of the word "commercial" is not apt. I meant to say "mainstream" languages.
  - lispm 7y ago
    That would exclude Clojure, too.
    - yogthos 7y ago
      Seeing how Clojure is actively used at places like Apple, Amazon, Atlassian, and even Walmart where software development isn't even their primary business, I think it's pretty safe to call it mainstream.
      - lispm 7y ago
        I would call languages like Java, Javascript, Python, C++, C# 'mainstream'. But not niche languages which have 1/100ths or less of open positions. Monster lists 68000 positions after a search for 'Java', and 180 for 'Clojure'.
        yogthos 7y ago
        I would call any language that's actively used in the industry with a large and active community mainstream. Restricting the term mainstream to a handful of most used languages is pretty silly in my opinion.

jcadam 7y ago

When I started learning/using Clojure, I didn't use the REPL much and kept on working in the traditional way: Write code, compile, test. Repeat until it works. It took some time to break my old habits and start using the REPL. It's unfortunately made me a bit lazier writing unit tests :), as I can hammer on a piece of code until I know it works - and small, deterministic functions tend to not break once you get them working. So much of my test code is integration tests. Nowadays, when I have to work in Java (or Scala, Javascript, Python, etc), I seriously miss the Clojure REPL. Though Clojure (and Lisp in general) has definitely affected the way I write code in other languages.

Scarbutt 7y ago

A good REPL is nice, but its hardly a killer feature or a big productivity boost. If Clojure didn't have a REPL it would have been completely dead by now cause its startup time is really bad. Clojure needs to have a REPL in order to survive (which is barely doing). Programmers are equally productive[0] (or way more because of their big ecosystems) in languages that have a fast code-run cycle. [0] https://groups.google.com/forum/#!topic/comp.lang.lisp/L5dZ-j6Id-s%5B76-100%5D https://groups.google.com/forum/#!topic/comp.lang.lisp/L5dZ-...

deleted 7y ago
[deleted]
yogthos 7y ago
REPL driven workflow allows me to put the application in a specific state, and then continue developing features against that state. If you have to restart the application each time you make a code change then you have to rebuild that state each time. This creates a much slower feedback loop, especially when you're working on large applications. Furthermore, the REPL is a fantastic tool for troubleshooting live systems in production, and in some cases even patching them with zero downtime. I don't know a single person who's worked with this workflow on a serious project and would want to go back to compile/run cycle afterwards. Meanwhile, Clojure leverages host ecosystem getting all the same benefits as any other language running on it.
wglb 7y ago
>Programmers are equally productive[0] (or way more because of their big ecosystems) in languages that have a fast code-run cycle. I would disagree with this. I feel much more productive in Lisp than, e.g. go or C or C++. In Smalltalk, the productivity was so great that I was dead tired after 8 hours, as it was all thinking and effectively zero compiling.