3 ms·
If you only learned Common Lisp from skimming PG's On Lisp, it's forgivable that you never really learned it. PG doesn't like OOP, but like, approximately all t
by Jach 2y ago
If you only learned Common Lisp from skimming PG's On Lisp, it's forgivable that you never really learned it. PG doesn't like OOP, but like, approximately all the big Lisp systems I've seen make use of it, and it helps with understanding quite a bit. Same thing with using more namespaces (defpackage) instead of throwing everything into cl-user. One reason I prefer CL to Clojure or Scheme is indeed the compile-time warnings about things like type mismatches. It's a trivial problem (it didn't really bother me when I did lots of Python) but it's nice to not worry about it. Similarly, I can do a lot of code navigation with vim, I don't need to learn emacs though it can do the same navigation, as can vs code or whatever. If I'm coming back to a piece of code, or investigating something new for the first time, it's rather easy to get my bearings, more so than a C program. I hacked my PDF viewer (atril) recently to show estimated time left while auto-scrolling a doc, it took me longer than I bet it would have if it was written in Lisp.
Typing being optional is not a problem. Like, if I'm looking at some function, and for some reason it's not clear what type of argument it's expecting, with one command I can pull up a cross-reference of other code that calls that function, and jump to it, and jump to the definition of the argument. If it's an object, I can jump to the definition of the class. This isn't really any more burdensome than jumping to the class in the first step, especially because in static langs I'll occasionally need to look at uses in context via cross-references anyway.
I don't get your dismissal of runtime probes. In large static systems, runtime probing is necessary for me to orient myself, the types don't really help. "How does the execution thread even get here?" is easily answered by sticking a break point there and running the thing, then you can inspect the stack. Common Lisp also has a very nifty "trace" function built-in, with a keyboard stroke I now get output every time the function is called along with what its arguments were and what its return values were. I can do this for any function, even built-ins, no instrumentation setup necessary or modifying the code or stopping/restarting the program. The full interactivity also means I can just jump to the definition even in some library-of-a-library code and if it pleases me rewrite it to add some prints or other info or just fix a bug and move that redefinition to my project. It's much easier for me to investigate a large Lisp system than a large Java system even though I've probably had more experience with the latter. Even grepping stuff is rather simple because of naming conventions.
- hello_computer 2y agoNot a dismissal of runtime probes, but a statement that, sometimes, they are not the best tool for the job. I like the REPL, but I'd rather not have to use it just to find out what X is.