It's sort of mentioned indirectly at the beginning in that source-code scripts that use a shebang, or make use of exit, can introduce development barriers. I've not written many CL scripts but I like Roswell too, and haven't found those barriers significant/odd to work around. I agree Roswell is definitely worth checking out. (Plus at least for me it gets even more use by letting me trivially run my tests with alternate CL implementations...)
Like, I didn't even consider including "some ugly reader macros" to handle the shebang issue, since my approach has been to comment it out while developing and uncomment once I was ready to use it as a script. But I think this simple macro I put just now in my $HOME/.sbclrc file should suffice:
And in some programs (not scripts) where I make use of uiop:quit, I just don't call those paths during dev, but this is the same approach the article has differentiating calling run vs toplevel.
About uiop:quit, that sometimes are in the middle of a script: lately I have wrapped it around a check of the nature of the terminal: if the terminal is dumb ($TERM), we are very likely inside Emacs/Slime, so we don't quit. https://github.com/vindarel/termp
Like, I didn't even consider including "some ugly reader macros" to handle the shebang issue, since my approach has been to comment it out while developing and uncomment once I was ready to use it as a script. But I think this simple macro I put just now in my $HOME/.sbclrc file should suffice:
And in some programs (not scripts) where I make use of uiop:quit, I just don't call those paths during dev, but this is the same approach the article has differentiating calling run vs toplevel.