Some developers don't!
On HN:
The tooling is nice, but it’s not what defines CL. The language has ample benefits just on its own.
A paren matching editor is the minimum tooling necessary for CL. Auto indent is a nice to have. vi has had both for pushing 50 years now.
The REPL is a standout feature of the system. Being able to load your code and poke at it is wonderful. Very powerful feature.
Python has a REPL. I never felt it was very good, but that’s me. I never used it much. Perhaps I was missing something. I wrote a bunch of Python without ever using it. And I’d wager many coders have treated Python like they’d have treated Perl, or most any scripting language. Write code, save code, run script, rinse, repeat.
With no interim step, turn around was fast and work got done.
There is nothing stopping folks from doing the same with CL. I’ve developed 1000s of lines of CL with little more than 2 little defuns. (e) and (l). (e) fired off ‘vi code.lisp’ and (l) wrapped ‘(load “code.lisp”)’. My knowledge of the debugger was knowing how to abort it back to the top level. I mostly did “print” debugging. If I was clever, I’d write a ‘dprint’ function that would take variable arguments. If I was lazy, I’d just “(print ‘(“x=“ x “y=“ y))”. No big deal.
Even when working with LispWorks (which has much to recommend it), I operated much like this. Reload all the code, dabble with the REPL, add print calls, reload, test individual functions. I never took the time to learn the higher level tooling and such. I didn’t feel it was necessary, and I’d rather code than fight tooling.
So, as the Lisp cognoscenti stares on in mouth agape horror as I left much of the Lisp experience on the shelf, I got stuff done anyway.
Which goes back to the fundamental point. CL is a language like any other. It’s a very cool language, very powerful, and worth using just for itself. Its environment does not define it as a language. It augments it, it’s cultural and useful to be sure, but you don’t necessarily need it to be capable and productive and to solve problems.
If all the talk of tooling and what not deters you from trying the language, don’t let it. It’s worth trying all on its own. Try it your way, however you’re comfortable.
But do get a parenthesis matching editor.
Edit: just to highlight the point, if you read PGs “On Lisp” and “Common Lisp” books, you’ll notice they’re pretty much all about the language and its power. He does not talk much as I recall about the environment.
https://news.ycombinator.com/item?id=38374577
On which I add that this is already more than a classical edit-[compile]-run cycle:
Nice! I'll note, specially for pythonistas, that even with your simple (edit) and (load) shortcuts, you are doing something more than in Python: while in Python you quit and re-run your program from the terminal, in CL you quit the debugger, you stay in the running Lisp REPL, you edit code while your REPL still around, and you re-load code from the REPL. It's already a faster write-run loop, and you can add advantages like keeping all your test variables around.
That's it! That's a refreshing testimony I wanted to share.
Lasting words
Now please check our list of good editors ;) https://lispcookbook.github.io/cl-cookbook/editor-support.html
Also higher on the thread:
After getting sbcl up with visual studio code and the alive extension, my mind was totally blown. I'm certain that emacs/slime is the true pure way, but for someone who's not wanting to learn emacs, alive is just pretty amazing and magic, and it fits well with what is described in the article. I wish I could do stuff like recompile functions in-place and just retry the call without exiting the process in every language in this way.
Top comments (0)