No and yes. Mostly no. Because load was a primary concern, we mostly used a test-driven cycle where we'd spin up the server and then attempt to DOS it for ever

No and yes. Mostly no. Because load was a primary concern, we mostly used a test-driven cycle where we'd spin up the server and then attempt to DOS it for every change. Not something you want happening much on your dev machine. However, for the simpler tests, if the test system hit a failure, it would then drop into a REPL (not on the production server). So it was sort of like a nicer debugger. The test system was developed in-house, but if I remember, it was something like a 100 lines of code. That's one of the things that Scheme guides you towards - if you don't have a wheel, it's generally five minutes to make one. I wouldn't generally bother fighting with emacs or configuration for anything. If you're fighting your tools, you're not being productive. Fine to do if you're not being paid, not so fine in a workplace. Keep things simple, and you'll do better than if you try and be clever. Rainbow braces and documentation lookup will get you 99% of the way to where you want to be. That being said, one of our devs wrote their code with Wisp (SRFI-119), and had a git pre-commit hook that automatically rewrote it back to normal Scheme, and another hook in their editor to turn it into Wisp code when they opened a file. Nobody noticed for over a month. Scheme makes it easy to write the way that you want to, using the tools that you like.