3 ms·
Ask HN: What does your Lisp workflow look like?
[I'm not sure what the etiquette is re. cross-posting; I've also asked this question at http://programmers.stackexchange.com/questions/36535/what-does-your-lisp-workflow-look-like/ in the hopes of getting a broad range of answers.]
I'm learning Lisp at the moment, coming from a language progression that is Locomotive BASIC -> Z80 Assembler -> Pascal -> C -> Perl -> C# -> Ruby. My approach is to simultaneously:
* write a simple web-scraper using SBCL, QuickLisp, closure-html, and drakma
* watch the SICP lectures
I think this is working well; I'm developing good 'Lisp goggles', in that I can now read Lisp reasonably easily. I'm also getting a feel for how the Lisp ecosystem works, e.g. Quicklisp for dependencies.
What I'm really missing, though, is a sense of how a seasoned Lisper actually works.
When I'm coding for .NET, I have Visual Studio set up with ReSharper and VisualSVN. I write tests, I implement, I refactor, I commit. Then when I'm done enough of that to complete a story, I write some AUATs. Then I kick off a Release build on TeamCity to push the new functionality out to the customer for testing & hopefully approval. If it's an app that needs an installer, I use either WiX or InnoSetup, obviously building the installer through the CI system.
So, my question is: as an experienced Lisper, what does your workflow look like? Do you work mostly in the REPL, or in the editor? How do you do unit tests? Continuous integration? Packaging & deployment? When you sit down at your desk, steaming mug of coffee to one side and a framed photo of John McCarthy to the other, what is it that you do?
Currently, I feel like I am getting to grips with Lisp coding, but not Lisp development ...
- wglb 16y agoI use slime and the repl that it provides. I start a project generally early in the process, and put stuff in methods there, recompiling (reloading with ,lo projectname (a slime trick)) as needed. I also often do ESC-x with the cursor positioned in a function or top-level form to compile just that function. All good work flows with Lisp include adding little bits of code, then executing to see how the result has changed. This leverages the beauty of lisp develpment. There are those who do something similar with vim--adding little bits of code, perhaps in a function, then pasting that either directly or with the help of a package to the REPL. For many of my programs, I generate an executable that is kicked off automatically, e.g., by cron. To build the executable, use 'save-lisp-and-die'. And don't hesitate to use quicklisp at http://www.quicklisp.org http://www.quicklisp.org. There are many very useful libraries there. For example, if you need to integrate through the command line, there is the getopt library. For unit testing, i use xlunit, but I seem to be in the minority for that. There are a handful out there. Some info here http://aperiodic.net/phil/archives/Geekery/notes-on-lisp-testing-frameworks.html http://aperiodic.net/phil/archives/Geekery/notes-on-lisp-tes... and here http://www.cliki.net/development http://www.cliki.net/development. Now you are mentioning a pretty specific deployment cycle there. WiX will work for executable delivery in a windows environment. Keep in mind, however that many using lisp for production keep an emacs/slime session open, generally using term, to a running production instance. This is likely to be culturally different that the environment that you are describing above. I haven't done anything that requires a continuous integration step, as my team size is just one.
- drdo 16y agoEmacs + SLIME, ASDF for "packaging" systems.