Python vs Common Lisp, workflow and ecosystem (2019)

Programming is something interesting and fun they are going to do for a few years while young, until (pick one) {their band takes off, someone funds their startup idea and they hire others to do the programming while they generate genius ideas and run the business, they get promoted to a high paying executive position that involved management and architecture and others do the coding, their podcast becomes a hit and they can live off that, the small company they work at IPOs or gets bought and they make enough to retire at 30, etc).

So they learn a fairly easy language that has lots of libraries that cover most things you do in a routine developer job.

...and before they know it they are 50-60 and still writing a lot of code, and realizing that if they had known they would still be doing this 30-40 years later they would have been better off if they had learned and used and gotten good with some of the languages that have a reputation of being very productive but hard to learn.

I'd also add spreadsheets and database to that. At one point I was the database guy at work, because no one else was available. I learned enough SQL to get by, but was in no way a database expert. Heck, we had to pick job titles at one point that described what we did to have on the business cards the company was giving us, and I put down "Database Roustabout" [1], which should give you an idea of where I stood. That was 20 years and I'm still the database guy at work. It would have been a lot better if sometime early on I had said "I'm going to become really good at SQL even though I'm sure someone else will become database guy in a year or so".

[1] Roustabout. NOUN. An unskilled or casual laborer. (North American) A circus laborer.

For someone to to even make the determination that "Lisp did my better" they must

A. Have a comprehensive knowledge of both Python and Lisp.

B. Have some understanding of the history of the languages.

C. Understand the problem on an intrinsic, fundamental level that enables them to evaluate which approach is better.

D. Generalize the problem to a broader scope to demonstrate why one language is better on a broader level.

E. Understand every other language ever used so when they show why Lisp does it better, they can defend themselves when someone comes up and tells them, "actually, Pascal does this even better yet."

Furthermore, it doesn't really matter what language did it better. The point of most talks is simply to demonstrate how to solve some problem in a certain language. If every talk started with "you can do this in Python, and I'll show you how, but you should probably just switch to Lisp because it does it better," that isn't very helpful.

This manifested in a few spots. The first is, yes, s-expressions. Yes, yes, I know, s-expressions are integral to the power of lisp, and they're really not hard to read once you get used to them. All of that is beside the point. The reality I saw on the ground, when teaching people to program, is that even people who have no prior programming experience whatsoever, and therefore no preconceptions to get over, have a harder time grasping s-expressions than they do algol-style syntax. I don't know why. I didn't have the same problem myself. But it's a real phenomenon that I struggled to help people through on a regular basis, and the lisp community's defensiveness about it is not going to make it go away.

Arbitrary-seeming names with zero mnemonic value is another problem. Car, cdr, progn, etc. - it takes a special kind of personality to not be put off by this sort of stuff. Not everyone has that kind of personality. Not everyone should have that kind of personality.

Finally, all the hair-splitty (at least to a newcomer) distinctions to contend with. =, eq, eql, equal, and equalp, or let, let* and letrec. Sure, there are reasons for these distinctions. But a language that can get by without quite so many of them is going to be a lot more attractive to newcomers. Even if it comes at the cost of footguns, if they're unlikey to be discovered until later.