Comment by reikonomusha
2 years ago
Very cool story; thanks for sharing!
I think a major fault in the industry is "find somebody who's good at X". It's not a necessary or even optimal requirement. Common Lisp doesn't have too many particularly odd language features; I'd say learning the Rust borrow checker or Scheme's call/cc is more difficult than anything Lisp has to offer.
What organizations need to do is prepare to let smart engineers self-train on the language as a part of on-boarding, instead of making it a hard job requirement to know the tools before walking through the door. In my experience, even for good programmers who are pretty green in their career, are entirely productive in just a few weeks—maybe a month total. That includes learning a new language, a new editor, and a part of a new code base.
Perhaps counterintuitively, the hardest people to teach Common Lisp to in my experience have been "senior software engineers" who transition into the project, who are so dead-set on their preferred languages and tools that they're entirely unwilling to even try something new, even if they're being paid to do it. Instead, sometimes, they'll find it preferable to do political maneuvering to avoid it, either by carving out a new module in their language, by petitioning to rewrite it, or by prioritizing other things entirely.
> Perhaps counterintuitively, the hardest people to teach Common Lisp to in my experience have been "senior software engineers" who transition into the project, who are so dead-set on their preferred languages and tools
That's essentially my experience. There is something about developers... they learn a new language but most people never really learn a new way of thinking.
I worked with one guy who tried to learn Common Lisp and even after a year on the project his code was essentially Java written in Lisp.
But this isn't really a problem with Lisp, specifically. I had the same problem with pretty much every programming language. Just recently I had fun debating the usefulness of Kotlin as a programming language. In my experience, for all the features Kotlin has, every single Kotlin program I have ever seen looks like a Java program translated line by line to Kotlin. Which is to say none of the Kotlin features are actually used to solve any important problems like reducing complexity of the application.
> Common Lisp doesn't have too many particularly odd language features;
I would say for most developers I worked with the biggest challenge was always getting the idea of macros. There is technically no reason to use macros. But if you do not use macros you are not really programming Lisp.
The point of macros is the reversal of the programming process. In a regular programming language, you get a bunch of tools and then you learn the tools and then you figure out how to write program using the tools.
In Lisp, you figure out how you want your program to be written, and then make tools that make it possible. It is quite a big shift in thinking that many people have trouble with.
Once I got this, I am now using similar technique in other programming languages. I am looking at my problem and extracting the core complexity and try to figure out what would be the best way to write that complexity down as code. Then I figure out all the machinery to make it happen. It not as elegant as in lisp but it still leads to way better and more readable code at least where it matters.
"Anyone could learn Lisp in one day, except that if they already knew Fortran, it would take three days." — Marvin Minsky
The irony there is that someone first had to learn enough Fortran to invent the FLPL (Fortran List Processing Language) system that went on to inspire the impelmentation techniques and terminology of Lisp.