diff --git a/src/pages/blog/live_repl.mdx b/src/pages/blog/live_repl.mdx index 8ec82c84..4470a64b 100644 --- a/src/pages/blog/live_repl.mdx +++ b/src/pages/blog/live_repl.mdx @@ -38,7 +38,7 @@ Every REPL will allow you to explore a language, defining and evaluating new fu The big difference between Lisp (or Erlang/Elixir) REPLs and ones found in other programming languages like Python/Ruby however, is that the former allows you to interact with a live system, while the latter doesn't. For example, when you start iPython you can play around with Python, evaluate code interactively, but, you can't attach to a running Python process in production. -Being able to attach to a running process gives you super powers effectively, because it means that you can both explore the status of the living system and even change its behaviour without redeploying or even restarting the JVM. +Being able to attach to a running process gives you effectively super powers, because it means that you can both explore the status of the living system and even change its behaviour without redeploying or even restarting the JVM. For historical reasons there are a few different REPls available in Clojure, I will just refer to this [comparison](https://nrepl.org/nrepl/1.0/alternatives.html) for that. It's also interesting to note that even deciding what exactly is a REPL can be controversial, as mentioned in [this discussion](https://groups.google.com/g/clojure-dev/c/Dl3Stw5iRVA/m/D_Kcb-naOx4J). @@ -85,15 +85,15 @@ All the previous use cases don't really need to change the behaviour of the appl You might have a bug in a production system, and know exactly how to fix it, but when every minute lost costs a lot of money, you still have this option. It's also true when you are not 100% sure of the fix, but the system is down anyway, so at least you can try it out very quickly instead of going through the whole flow. -In the simplest possible scenario all you have to do is to simply connect your IDE to the production REPL, re-evaluate the offending code with your fix, and everything is fixed. +In the simplest possible scenario all you have to do is simply connect your IDE to the production REPL, re-evaluate the offending code with your fix, and everything is fixed. It's not exactly as simple as that, but we'll look later in more detail at the limitations. -Of course hot reloading production code can be dangerous and should be done extremely rarely, but it can also be a life saver when you really need it. +Keep in mind that hot reloading production code can be dangerous and should be done extremely rarely, but it can be a life saver when you really need it. ## Limitations For a live REPL to work, you need the language to support it. In many languages, a REPL was an after thought, and sometimes you can't do everything from a REPL. -While in Clojure the REPL was always a first class citizen, you still have to be aware of a few things that cause issues with hot reloading, and write your application accordingly. +While in Clojure the REPL was always a first-class citizen, you still have to be aware of a few things that cause issues with hot reloading, and write your application accordingly. Thankfully these tips also help with local development, and make your codebase nicer to work with. @@ -124,7 +124,7 @@ So if you do want to allow access to production you (at the very least): ## Other tips -- use separate checkouts of the project for local development & live repling (see potentially [git worktree](https://git-scm.com/docs/git-worktree) to help with that) +- use separate checkouts of the project for local development & live repling (or use [git worktree](https://git-scm.com/docs/git-worktree) to help with that) - add banners in the live repl to make sure you are aware of the environment you are connected to. It's currently not exactly supported but might be in cider when [cider issue about dynamic banners](https://github.com/clojure-emacs/cider/issues/3599) is implemented. It's also easy to hack it together yourself by creating some more functions.