Our great sponsors
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Haven't had a lisp job, so maybe I shouldn't comment, but... I did use CL and Clojure on the job for a few things at my last two places. It's easier to find Clojure companies (and them to find you) than Common Lisp ones. You might want to peruse https://github.com/azzamsa/awesome-lisp-companies from time to time and see if any have openings. There's other resources linked too and of course there's the reddit and discord community (such as there is) hubs. You can also see if there are any meetups in your area, that's how I almost ended up at a Clojure startup some years back.
I should have taken strategy notes after talking to a guy at my last job who got management buy-in to rewrite a lot of Java code (for android) to Kotlin and have all new code for android be in Kotlin (before that was considered the sensible default). I think that's in general a better approach for a lot of would-be paid lispers: don't wait for or look for the lisp job, make the lisp job. Whether that's doing work where the customer doesn't care what language the thing is made in, or introducing it (some have even snuck it in -- the original clojure.jar got a lot of early success that way) to an existing work place. What I somewhat remember from my conversation was that if you can make a good technical case and have at least one other person supporting you (ideally your entire dev team as was his case), it's a lot easier to sell. No one raised bogus concerns about increasing the hiring difficulty or effort learning the new system. (I say bogus because engineers are learning all the time, and huge swathes of the industry have already had to do things like migrate from ObjC to Swift, or the various versions of JavaScript and later TypeScript + all the framework churn, switching IDEs; learning and change are quite common and a non-issue.) From other Lisp company reports, getting a new hire up to speed to be productive with the team using Common Lisp is a matter of a week or two, a small portion of the overall onboarding time a lot of new jobs have. Mastery takes longer, of course, but that's different.
If I had stayed longer at my last job I would have continued to flesh out a better demo for interactive selenium webdriver tests for our main Java application after injecting ABCL into it, it seemed like the easiest vector to get more interest from my team and other teams. It kind of sucks when you're debugging a broken test and finally hit an exception but now you have to start over again (especially if you stepped too far in the debugger), especially with heavy webdriver tests that can take a long time. The Lisp debugging experience is so much better... And when writing the test from scratch, it's very interactive, you type code and execute it and verify the browser did what you intended. When you're done you run it again from scratch to verify.
Manual recursion often isn't needed. You can get basically all of what you want from Transducers: https://github.com/fosskers/cl-transducers
It also gives you access to Babashka if you want Clojure for other use-cases where start-up time is an issue
https://babashka.org/
It's also available in Clojure: https://github.com/clojure/core.logic
If you want to write one yourself, it's pretty easy: https://www.youtube.com/watch?v=y1bVJOAfhKY
I spent a lot of time unsuccessfully bending Common Lisp into something I could love.
It's still one of my favorite problem solving languages, but far from trivial to fix from the inside.
Tried writing my own readers that compile to Common Lisp.
Then I ended up on a side track to write my own interpreters; mostly Forths at first, then gradually more Lisp-like and practical creations.
My latest attempt may be found here:
https://github.com/codr7/jalang
I also liked that reference since I had not heard of Jank before. It is a work in progress so I just added a calendar entry for 9 months from now to check it out. https://jank-lang.org/
> The problem with learning Lisp is `(a ,b c)
If you can understand "String ${interpolation}", you can understand list quasiquoting.
> But the problem remains: it only takes one wizard to make reading code impossible by outsiders.
This really is a Lisp meme. There are plenty of Lisp wizards like Guy Steele, Rich Hickey, and Matthew Flatt. The wizards perform the magical act of making code legible and intelligible. I have stumbled around several Clojure and Racket code bases and never felt like "I should understand this code but the features of Lisp make it impossible to know for sure." "Infinite power" macros and whatever are really only used sparingly and generally when it's impossible to achieve a goal otherwise. No one is doing (define + -).
> But this means no-one outside of the language/system developers know the language, this means Lisp tends to be write-only by design - not in the line-noise meaning, but in the obscure foreign language meaning.
I, as a Racket novice, have been able to add candlesticks [1] to the plot library without learning much about it. I have also debugged DrRacket (an IDE) to uncover that Racket GUI operations performed significantly worse if non-integer scaling was used [2]. At no point when I was going through Racket internal code did I ever feel it was write-only. In fact, it was quite convenient to modify Racket internal source code, rebuild, and test changes in a way that would be much more difficult in Java or C++.
> You certainly can not do that, but if you choose to not do that, why pick Lisp?
Built in rationals.
The ergonomics of defining [XML / JSON / etc] data as S-expressions and doing things like pattern matching on that data.
Great, coherent integration between GUIs, plots, statistics functions, and all the other bits of Racket's batteries inclusions.
You still have access to all the other great features that other languages have borrowed from Lisp like REPL development, package managers, good IDE tools, etc.
It is nice to learn the meta-syntax of parentheses once and know that the code will always look like that. No need to consider if some feature is implemented as a syntactically different new keyword, annotation, function call, or whatever. It'll always be a (feature).
> something you have to conciously work for with Lisp.
Plenty of languages have style guides, linters, static analysis tools, etc. to make sure the code conforms to certain restrictions. Lisp feels no different in this regard.
[1] https://docs.racket-lang.org/plot/renderer2d.html#%28def._%2...
[2] https://github.com/racket/gui/commit/20e589c091998b0121505e2...