I wouldn't propose to do it in Lisp. Batch programming is done better in languages like Go, especially if you are already feeling comfortable with a batch workflow. You can write web servers and command line tools in Lisp, but it would be a huge investment to learn that and it is not clear if it pays back for you.

Essentially for anything slightly complex one would use an interactive programming style and 'only' deliver the application in a batch style.

Racket is more oriented towards batch programming, compared to popular Common Lisp development environments.

Lisp is terrific for batch programming (too).

You can edit a Lisp program strictly in files, and run a build step to produce a clean image which is tested, using a REPL just as a debugger, to "go in" and find out what is wrong.

If he uses a REPL, it is no longer batch programming. The plain edit/compile/run cycle is best left to other languages.

Ok, so the definition of batch programming means that debugging is only allowed by print statements (or other side effects from which we infer what happened in an actual run of the program and work backwards). For instance, using a breakpoint debugger on C isn't batch.

Still, Lisp is good for that. I've debugged Lisp programs with print statements and it was at least as good an experience as debugging programs in other languages using print statements.

For instance, if we compare to C, C has no trace, and generally no easy way to wrap any function with a wrapper that takes the arguments. Ecosystems built around C, like the Linux kernel, have developed things like that: Linux has a function tracing thing in it (more than one, I think).