Disclaimer: Below is my experience and shouldn't be regarded as universal fact.

I've been hiring and wildly advertising Lisp jobs for around 10 years now in all sorts of domains. Good candidates always come by, but you'd think that sentiments like yours ("hard to find a lot of jobs") would mean that supply is significantly greater than demand. There is enough supply (if your employer doesn't have lots of stipulations like local-only, citizen-only, etc.; unfortunately mine does), but it's still counter-intuitive to me that supply isn't overwhelming.

I find most people who are attracted to the jobs are

1. Long-time lispers who are pretty happy with their life as it is, and would only take the job if it was truly a killer deal (e.g., work a couple hours a week at a FAANG staff-level full-time salary);

2. College students who are fascinated with programming languages and have dabbled in Lisp; and

There are others, but those dominate in numbers.

I've never, not once, got an applicant that said, "I don't know Lisp but I'd love a job with an interesting language."

Not so remarkably, Haskell programmers, Clojure programmers, and others of those ilk rarely apply. I don't know why, but Lisp has a distinctly different philosophy and lacks a solid community like those languages have.

I've sort of come to the conclusion that advertising it as a Lisp job is perhaps not even so beneficial these days. My biggest success honestly has been finding people who are obviously good at programming, showing them Lisp, then seeing them take off in less than a week and fly to new heights.

> I've never, not once, got an applicant that said, "I don't know Lisp but I'd love a job with an interesting language."

I probably wouldn’t ever apply to a role that’s in a niche language I’ve never used. Most niche roles I’ve seen though want staff/principal level domain experts though.

Last time I looked for a job in a niche language (Erlang in my case) most of what I could find was actually looking for Clojure or Scala developers or something, but decided to keyword dump every functional language they’d ever heard of.

I think the counter-intuitiveness comes from the idea that low demand must equal high supply. It could also just be an illiquid market in both directions; supply and demand both low and roughly matched, but inefficiently.

I think very much this. I've known Lisp for a longish time now (even used it at work on occasion) but never considered to seek out a "Lisp job" because language choice is far from the most important criteria in a job. At the moment I probably slot into his first category.

> I've never, not once, got an applicant that said, "I don't know Lisp but I'd love a job with an interesting language."

I don’t know Lisp and I’d love a job with an interesting language - but it would never occur to me to apply to a job requiring experience with a language that I don’t have experience in.

I think these meme job ads (we need 30 years of Go experience), as well as inexperienced technical recruiters and software engineering managers, have soured the market. If somebody is a good programmer, the last thing I care about is whether they know what NRECONC means... all that stuff can be figured out on the job.

Common lisp is surprising not functional. It embraces that all things can be first class things. But mutable code is very very easy in common lisp.

Until everyone and their dog decided to turn functional as a synonym for as Haskell does it, Lisp was quite functional.

My understanding is that Scheme is quite functional. So were the very first versions of Lisp. Common Lisp, on the other hand, strikes me as not very functional at all (from what limited experience I have of the language). It does have first-class functions, and functions like ‘map’ and ‘reduce’, but that isn’t enough to make it truly functional — it seems to lack the characteristic approach of building functions from smaller functions that is so common in functional languages.

(Also, functionality is more of a continuum than a binary category. CL certainly is more functional than Python, but less functional than Scheme or SML. It all depends on where you draw the dividing line, though I’d argue that classifying CL as ‘non-functional’ makes for more meaningful categories.)

Scheme directly supports call-with-current-continuation (which CL doesn't) and it requires tail call elimination (which CL doesn't require but most CL implementations do it anyway). Scheme also has slightly easier syntax for dealing with functions in function position, at the cost of potential namespace clashes.

Some schemes (e.g. Racket) provide immutable data structures.

So I guess Scheme is slightly more functional than CL but with the exception of call/cc the differences are so minor that it doesn't matter.

The very first versions of Lisp were less functional than Common Lisp: imperative, mutable data, mostly only dynamic scoping for variables, no lexical scope, first class data type of functions unclear, ...

Common Lisp at least has lexical scope and first class functions.

Common Lisp has lexical AND dynamic scoping.

This is very nice with constants. A function can make a hard dependency on standard out for example. If I change that value locally then call the function, it will operate as expected while everything else using that variable name will continue using their own expected values too. Lexical scoping would instead require passing that value in every time it is used.

> The very first versions of Lisp were less functional than Common Lisp: imperative, mutable data, mostly only dynamic scoping for variables, no lexical scope, first class data type of functions unclear, ...

Hmm, perhaps I’m misremembering — I know very little about the history of Lisp. I was thinking specifically about the very beginning of the language, where it could be used to define ‘eval’ and nothing much else.

This is the manual of Lisp I, the first actual implementation of Lisp, from 1960:

http://bitsavers.org/pdf/mit/rle_lisp/LISP_I_Programmers_Man...

If functional means "higher order functions", sure Lisp is quite functional.

It's not ergonomic to compose functions in the way that Haskell is due to Lisp's forms essentially making every function able to accept a variable number of arguments. You end up with something like arnesi which provides these functions but it gets slow and verbose to write all those `funcall`'s everywhere. Or you have macros.

Whereas in Haskell, partial application and composition are first-class in the design of the language.

I really enjoyed programming in CL but I would say that it's one of those languages that let's you try functional programming but it's not the sweet spot for it.

Coalton is in Common Lisp and lets you write all that convenient syntax without much fuss.

I always understood functional in the matematical sense of: inmutable/no side effects. At some point someone decided typed lambda calculus was a superset of lambda calculus and the next thing was the haskell alike thing.

I wish it made more things first class. There are surprisingly many restrictions.

Example: the call stack isn't first class. You can only interact with it through the condition system, which is very limited.

Example: CLOS has a meta object protocol, which is great! But there's no equivalent to the MOP for, say, the language rules themselves (first element in a list in the reader is treated as a function namespace reference, for example).

I was lamenting this the other day, thinking of Smalltalk being able to snapshot the stack and store it in a variable for debugging later. Then it occurred that one should be able to write a Lisp function that creates a data structure containing a snapshot of the whole stack and then inspect that later. So maybe no new Lisp primitives are needed?

How would you write such a function? The ways to interact with the call stack in Common Lisp are very, very limited.

The debugger of a Lisp system is also not exclusively written in the language (operators, ...) described in the Lisp standard. The standard language is largely independent from a runtime. It says nothing about the implementation technology. The Lisp system could be running on a virtual machine (like many Smalltalk systems), it could be a whole-program compiler to C, ...

For example in LispWorks it's possible to look at a snapshot of a stack in a Debugger, later.

In your last point, isn't that the evaluator, not the reader?

That said, I'm all for more first class things. I really just meant that common lisp was ahead of the game on number of first class things.

I assume you mean mutable data, and yes, mutable data is easy in CL. But at the same time immutable data is not hard; it's just not the automatic default.

Yeah, I confess I should have said "lisp is surprisingly friendly to non-functional idioms." In large, this can mean mutable data, sure.

I've not yet had a problem finding a Clojure job, if you know where to look (Clojurians Slack for example). There's not a lot of competition for roles, so getting to an interview stage is relatively easy, and because there's low competition the interview processes themselves are also relatively easy. Most positions I see, and have worked for, are for start-ups however, so maybe that's not one of the "good ones" for some people, but the pay is great, and the work interesting, for me so far at least.