4 ms·

REPL driven development is great, but there are still tons of situations where you want a full recompile and restart. Slow compile and start time really slow do

• didibus 4y ago
  > Recently I was porting a small application from Clojure to Rust, and 'cargo watch -x run' was faster than 'clojure.tools.namespace.repl/refresh' and is more reliable I think this tells me we differ greatly in our development approach. Because it seems you still practice a kind of traditional TDD. I'm not saying one is better, but I think this is either a personal preference of style, or maybe you haven't tried the Repl driven approach? For example, I almost never use REPL/refresh. Any amount of, delete state, reinitialize the whole app from scratch, be it by restarting the app like cargo does, or some tear-down/re-init like refresh does, is a very different approach to how I use the REPL, where I make many small changes that I hot-reload as I go, never really needing a full refresh. That allows me to maintain state and context as I code. Also, small applications are nice, but most real app will grow to be big applications, not sure how `cargo watch -X run` will keep up in that setting, it doesn't just become compile/start times at some point, it's also how long does it take to instantiate your SQL driver and establish a DB connection, start your web server, etc. REPL driven development allows all this to be initialized in the morning when you start your day, and just kept open till you clock out. So all development throughout the day you get instant hot-reloads of the functions you're changing, while maintaining all that state alive as you go.
  • synthc 4y ago
    I've worked with Clojure for years using the REPL driven approach and found I needed restarts quite often, for example when adding updating dependencies or other changes to the project file. REPL driven development is great, but sometime you want to make sure that you are not using some function that was only defined in the REPL session but not in the source code. Also the REPL session sometime gets in a bad state when printing big outputs, blocking forever with some concurrency stuff or other mistakes.
• capableweb 4y ago
  > but there are still tons of situations where you want a full recompile and restart What situations specifically? In my career as a Clojure/Script developer, making servers, desktop UIs, frontends, CLIs, almost anything, I've never had that requirement. So I'm a bit curious of when that would be required.
  • synthc 4y ago
    When you mess up the repl session somehow, for example by starting a http server on a port but not storing the server object. You now have blocked a port, and restarting the server does not work. Or if you run something like (future (while true ...)) There is some wierdness when redefining protocols and multimethods where a good 'ol restart is the easiest way to set things right. Try working in an ecosystem with fast compile and startup and you will see why it is an advantage
    • capableweb 4y ago
      > When you mess up the repl session somehow, for example by starting a http server on a port but not storing the server object. You now have blocked a port, and restarting the server does not work. Or if you run something like (future (while true ...)) That's true, but how often do you end up in those cases? I usually end up with those one time per project, if it happens at all. Once solved, you won't hit it again. Once you know what can hang a REPL session or block a port you want, you usually don't hit those issues again. > Try working in an ecosystem with fast compile and startup and you will see why it is an advantage I have, Clojure is not my first nor last programming language I've learnt. Even working with language that has no compile step at all (interpreted languages), being able to edit the program in real-time is still preferably for me, as it's much easier to iteratively come up with solutions. But of course, not all approaches are suitable for everyone, to each their own, etc etc.