As a professional user of lisp that works with it on a team and delivers products, I agree with the sentiment. Nobody I’ve had the pleasure of working with to on-board has had issues given about two weeks, but that’s in a different environment than a curious somebody who is just poking around from the internet.

The effort to get an editor going and to open a file and load a package (“system” in CL) is a lot. Of course, I’ll die on a hill claiming that those things are a constant overhead and aren’t even detectable when you wield lisp’s power.

Nothing inherently stops lisp from becoming simpler to start with and use, but most everybody who knows lisp has become not only competent with the current tooling, they’re happy with it. I’m happy too: I love using Emacs and SLIME. I love it better than VSCode, PyCharm, etc. I’m faster and more productive.

I wonder why other professions aren’t like programming. Adobe Premier isn’t exactly easy to use, yet professionals aren’t apparently clamoring for an iMovie equivalent.

They’re not? Take a look at at a Final Cut Pro.

Final Cut 10 is a prank, I'm sure of it.

> It fails to attract many people because it's not a fun language to get started in.

Interesting. Nobody is born knowing any computer language. Languages therefore are popular (among other things) in proportion to their ability to convert "those who don't know the language" into "those who know", and "those who know" into actual users. A gentle introduction to those who don't know anything is therefore a good start. I suspect that both Lisp and Haskell suffer from this.

I think that it is even simpler than that.

There are languages for people who want to get things done, and languages for people who want the perfect language for getting things done. The problem is that definitions of perfection differ between people, so people who are searching for perfect languages wind up in a small niche of people who agree, separated from people next door whose idea of perfection is just slightly different.

In the meantime people whose focus is on getting things done go with a popular language which builds a critical mass of ways to get things done. And the availability of useful libraries makes them actually better to get stuff done with than languages that are theoretically nicer in some way.

This is, of course, a worse is better kind of argument. See https://www.dreamsongs.com/RiseOfWorseIsBetter.html for context on that.

I don’t like this argument and paints a picture that Lispers are overly concerned by some academic aspect of programming. Many people, myself included, use Lisp because it lets us get something done more quickly, more efficiently, more easily, or all three.

It’s true. Importing flask in Python and starting a server takes about 1/2 as much code as in Lisp. Some extraordinarily routine stuff Python has down to a one-liner. A lot of people have also written more Python libraries, so chances are you’ll be able to cobble any random doodad together with a huge dependency tree. But after a certain very short prototyping period, I end up fighting Python’s terrible deployment, terrible efficiency, and slapdash language implementation when trying to build something robust.

The following phrase is telling.

"But after a certain very short prototyping period, I end up fighting Python’s terrible deployment, terrible efficiency, and slapdash language implementation when trying to build something robust."

How many programmers would see Python's language implementation as "slapdash" or care? The fact that you both see it that way and care speaks volumes towards you fitting my characterization of the kind of person who uses a minority language.

The other points likewise. Python's inefficiency is well-known and acceptable for most use cases. Where you need better, it lets you escape down to more efficient languages in libraries. Some good examples of this include pandas and various machine learning libraries.

And as for deployment, it is more of an organizational challenge than technical one. The strategy of taking half your servers offline, deploying, then swapping and repeating worked fine 20 years ago. It works fine today. (You might have to do some ceremony with kubernetes. But the strategy remains conceptually similar.) This is only a significant pain point when there are other problems that interfere.

The fact that these things bother you, and bother you enough to rewrite wheels that already exist, speaks volumes.

The fact that people who agree with you on this then can't agree on whether strong typing is worthwhile (like Haskell), or continuations are good (like Scheme) or whether performance is critical (like Common Lisp) or whether access to the JVM toolset matters (like Clojure) causes you to not create a critical mass around a better toolset. And so the situation remains. You all agree that the popular languages are so terrible that you avoid them. But then can't agree on which unpopular language everyone should use instead, or why.

>cant agree on which unpopular language everyone should use

All lispers agree everyone should use lisp. Any lisper that doesnt like lisp is welcome modify that lisp to make it something the lisper does like.

And that is the problem.

Lispers wind up with a myriad of incompatible Lisps, and a solution written for one may or may not be portable to the next. Sure, you can call them all Lisp. But Common Lisp, Emacs Lisp, Clojure, and Racket are, syntactic similarities notwithstanding, actually different languages. A library written for one will generally not work for the others.

Then its only a ten-minute diversion to modify that library to work with my lisp. Or to build a library in my lisp which can work with that library.

I disbelieve.

A complex application written with CLOS will generally not be portable to Emacs Lisp. An application written in Emacs Lisp that takes advantage of dynamic scope won't be easy to port to Clojure. A library in Clojure that wraps something in the JVM ecosystem won't work in Racket. And something written in Racket using continuations or Pict generally won't be easy to port to Common Lisp.

And even with closer Lisps than that, I have enough experience of "that should be easy to port" then blowing up over minor details to be suspicious. Sometimes it will be 10 minutes. Sometimes it will be several weeks and incomplete even then. The latter happens often enough that, the developer's confidence notwithstanding, the average is waaaay longer than the estimated 10 minutes. (The phenomena of tasks being rarely faster than we thought, but roadblocks can be unlimited in extent is generally true in programming. This is one of the reasons why our time estimates tend to be systemically low.)

And if the library is not easy to port, then writing an interface which generates code that DOES work with that library is easy to do.

I still disbelieve.

I've done this. I've seen other people do this. Sometimes it works. Sometimes it doesn't. Sometimes it works fine for the demo but then has weird failure modes that you trip over in production months later.

It may be the right thing to do. It may be feasible. But a general "10 minute job" estimate is laughable.

I can only speak from the perspective of using Clojure, I toyed around with Racket and have no experience with CL.

That said, I disagree with some of the points you make:

> availability of useful libraries

Clojure is embedded in both JS runtimes and the JVM. Both feature massive ecosystems.

In terms of getting things done:

Languages like Python, JS and so on are fantastic at plumbing. But when it comes to modelling data-structures, manipulation and algorithms then they are far less expressive and productive than Clojure from my experience.

I personally think the main issue really is the learning curve. There are quite a number of things that 'suck' about Clojure initially:

1. In a Lisp you are essentially manipulating an AST rather than writing statement-based text. Initially this is cumbersome and taxing both while reading and writing programs.

2. In a functional Lisp like Clojure (and other FP languages) there is a wide variety of commonly used functions which are used to manipulate and compose data-structures and other functions. Especially when reading code this can be daunting.

3. Setting up a environment correctly for REPL driven development as a beginner and tuning it as an intermediate user is quite an undertaking in comparison to many other languages.

4. Clojure specifically being a hosted language forces you to understand the hosted ecosystem as well plus the wiring between the host and Clojure.

The payoff for all those four points is worth it:

1. Search for paredit visualizations like this one: http://danmidwood.com/content/2014/11/21/animated-paredit.ht.... Manipulating code this way requires mechanical prowess and exercise but scales up really nicely, especially alongside better understanding of Lisp code in general.

2. The incredible variety of functional building blocks scales really well with your experience and understanding. You are programming with a series of descriptive expressions, rather than lower level statements. Code becomes more declarative, dense and expressive. Abstraction is much more fluent.

3. A nicely set-up environment enables very fast development cycles and allows for understanding pieces of code of any scope in isolation, because you can evaluate, change and test any expression instantly.

4. This is in my experience a necessary evil to get higher adoption and a the massive library ecosystems of JS and Java.

I assume there are a lot of capable developers who simply cannot get over 1 possibly while being pushed back by 2-4. And I have to admit: If I wasn't already infected with Lisp at a younger age, I probably wouldn't have bothered with Clojure or any Lisp. But now it is my favorite for manipulating and modelling data AKA doing 'business-logic' and transformations between APIs.

Yes, Clojure is a special case. But still let's address your points.

Languages like Python, JS and so on are fantastic at plumbing. But when it comes to modelling data-structures, manipulation and algorithms then they are far less expressive and productive than Clojure from my experience.

My experience differs. It is hard to find a data structure that cannot be modeled with Python's native data structures with only a constant performance penalty. In fact I believe that I have only seen one, and I don't remember what it is.

I agree with the points that suck about Clojure. To them I must add, "It is hard to hire people who already know the ecosystem." For real businesses this is a non-trivial issue.

As for the purported payoff, I'm glad that you enjoy your editor. For all practical purposes the mechanics of editing code are not a pain point. Besides, I can do the same with vi in any language with braces. (Selecting a block in Python is slightly harder but again has not proven to be a significant challenge.) Designing code as a series of descriptive expressions has more to do with learning to program well than any particular programming language. The third point is not a significant pain point. And as for the fourth point, simply using the hosting language gives you the same library ecosystems without having to understand the wiring and translate all of the examples you find online.

The result is that if you want JS (I only occasionally do), you can just write in JS (or TypeScript). If you want Java (I don't), you can just write in Java.

However Clojure gives you the perfect tool that is customized to exactly how you have to work. Bully for you. My experience with evaluating such environments and tools is that for me to master it is a large investment of time and energy, at the end of which I might or might not (probably not) have much payoff.

(This doesn't stop me from learning said tools. There are good ideas there that I can adopt. But I have not found them particularly useful for me in practice.)

> My experience differs. It is hard to find a data structure that cannot be modeled with Python's native data structures with only a constant performance penalty. In fact I believe that I have only seen one, and I don't remember what it is.

My claim isn't that they don't exist or that one cannot implement them in for example Python (which is very false). I was imprecise there. What I was trying to say is that there is a higher degree of uniformity and generality to do the same in Clojure, which leads to more cleanliness and easier, more fluent abstractions. Clojure code (and I assume similar to true with other Lisps) feels more compatible with itself so to speak. Syntax plays a role here but also the fact that Clojure is designed to be primarily an FP language.

> I agree with the points that suck about Clojure. To them I must add, "It is hard to hire people who already know the ecosystem." For real businesses this is a non-trivial issue. (...)

I fully agree with this and with the rest of your points. I think there might also be factor of personal taste or way of thinking.

I understand what you are saying. I am unable to back it up or refute it from my personal experience. I do not know Clojure well enough.

I do know from personal experience that programming in a familiar environment is significantly more productive than programming in an unfamiliar one. And that many, many programmers have mistaken their personal productivity for the productiveness of the environment.

This is one of the causes of a lot of "holy wars". Because everything from indentation style, to operating system, to text editor, to language feels critical. And indeed is...for the programmer who hasn't learned how to switch between these things.

If someone had an oracle that could give us the answer, I would happily take an even money bet that something of this at least contributes to how much you prefer Clojure.

I also agree with you that there is a lot of personal taste and way of thinking involved. And furthermore that our opinions usually match whatever environment(s) we imprinted on. (In the interests of full disclosure, my background is math, Perl and relational databases.)

The above post didn't say unpopular, they said 'underpopular'. While that's a bit of a neologism, it just implies that it's less popular than it should be.

Also: "Lisp is the most fun you can have programming, yeah from the start," while subjective, is by most accounts, wrong. Especially when referring to Common Lisp; there could hardly be a more convoluted Lisp than Common Lisp.

I learned much of my initial Lisp programming decades ago with Macintosh Common Lisp. I found it to be incredible fun to work with a tight interactive environment on my Mac.

So did I--or, rather, I started with Coral Common Lisp, which is what it was called before Apple bought Coral Software.

I found it hugely fun--so much so that it took over my brain. I've been primarily a Lisp programmer ever since.

Coral Common Lisp offered an extremely easy way in to Lisp programming that was also tons of fun to work with, and an industrial-strength development environment for the full panoply of Mac applications. At AAAI in Detroit in 1989 I mentioned to someone that I was working in Coral Common Lisp and a passer by quipped, "Oh, the good Lisp."

It ran just fine on a 1 MB Mac Plus. You could start it up with a double-click. It launched with a Listener window and a blank Lisp source file (unless you launched it by double-clicking an existing Lisp file with some code in it.) You could save an image, copy the image file to a different machine, launch it, and you would see the same windows in the same state.

Creating a fully-functional Mac window looked like:

    (make-instance 'window)

You could populate the window with working widgets with similarly simple interactions. If you built something you wanted to keep using, you could turn it into a Mac application by doing

    (save-application "Foobar")

If you preferred constructing UI by dragging together widgets by direct manipulation, you could do that, too. Once your UI was assembled, you could tell the Lisp to save the Lisp source code needed to reconstruct it.

The built-in editor, Fred, was a species of Emacs, with the Lisp-oriented features that you would expect, but you'd never have to know that if you didn't want to, because it was also a fully-featured Tesler-style modeless editor at the same time.

The stepper, inspector, apropos, and other development niceties all had Mac graphic interfaces that made them easy to discover and tinker with. They were all written in Lisp, so you could use the Lisp reflection tools to crack them open and poke around inside to see how they worked.

Coral Common Lisp made it easy to get started using Lisp to build apps--about as easy at it can possibly be. At the same time, though, it imposed no arbitrary limits on what you could do with it. When I first met Dave Vronay he was working on the GUI for SK8, and gushed about how easy it was to write window-definition resources (WDEFs) in assembly language using CCL's LAP subsystem. He was an experienced arcade-game hacker, well versed in assembler, but Coral Common Lisp was his first fully-interactive assembler, able to define and integrate new assembly-language code while the program under development was running.

The CCL of today, Clozure Common Lisp, is still a great Lisp, but it isn't as easy or as inviting for newbies. It doesn't have the same graphical environment or the tight integration with the underlying system.

In part that's because when the Clozure Common Lisp project was created (under the name "OpenMCL"), its creators had the rights to the compiler and the Lisp runtime, but not to the Macintosh graphical environment. In part it's because modern macOS is quite a bit more complex than Macintosh System 9 and its predecessors, and development systems have a lot of additional hoops to jump through nowadays to do the kinds of things that MCL was able to do.

If a modern MCL existed, I expect a lot more people would find Lisp a lot easier and more fun to get started with. I think it's perfectly possible to create such a Lisp, but it would be a heck of a lot of work.

I used MacScheme earlier, which also was a huge amount of fun - even though I did not have the extension to access the Mac Toolbox (Toolsmith, IIRC).

MCL was a whole new world then. First with Object Lisp and later with CLOS. I used MCL before it was owned by Apple - at one time it was called MACL (from a market agreement with Franz, IIRC). But later LispWorks was another step up, because it was a big grown up full extended Common Lisp with everything from the commercial UNIX workstation Lisps (like Allegro CL, Lucid CL, LispWorks): it suddenly ran on small and simple to use Apple or Windows laptops, plus it had a Cocoa port.

But, as you describe, the simplicity and integration of MCL into the early MacOS was a lot of fun and there was a lot of tinkering by users. Some friends were still using MCL years after it was obsolete...

I started with the full version of MacScheme about the same time that I started with CCL. I loved them both, and at first I liked MacScheme better because Scheme was a smaller, simpler language, and easier to learn. CCL won me over in the end because it was just so much easier to get things done.

Later on, John Ulrich, who owned Lightship Software, the publisher of MacScheme, came to work at Apple and became a friend and colleague. I continued to use MacScheme off and on for years.

I’ve happily paid for Lispworks licenses many times now, but even Lispworks isn’t a good solution for everything I want to use Lisp for. A modern version of CCL’s graphical environment would still be a nicer place for newbies to start. You could even use Lispworks to build a product like that, if the license didn’t prevent it. (Lispworks doesn’t allow their product to be used to make Lisp development systems, which is understandable. They’re a small company who don’t want to put themselves out of business by enabling a customer to give their Crown Jewels away.)

yes, building a product to include development tools (compiler, ...) of LispWorks or Allegro CL would be expensive and not really attractive. I think Franz, Inc. has such a licensing agreement for Allegro CL, but their licensing model is different anyway.

In former times there was a market for add-one GUI or IDE tools. Lucid CL made money from licensing their Lisp to other companies, which then resold those with tools added on (like the SUN Common Lisp IDE). The Action! GUI designer was available for MCL. CLIM was an add-on product. The big Expert System development environments were available as add-on products to Lisp systems.

For a commercial customer something like LispWorks or Allegro CL might still be worth it - they are technically very stable platforms.

I tried to work out a way to reimplement my old programmable WYSIWIG word-processor, Alpaca, using Lispworks, but we've been unable to reach an agreement that works for me and for Lispworks. They don't want me to make something that someone could use to compete with their product, and I don't want to make a crippled version of Alpaca.

I wrote the original Alpaca in CCL, using its Cocoa interface. I used it to write a book, and a Japanese company approached me about licensing it for a product, but I fell ill before I could do anything more with it. By the time I recovered enough to look at it again, it had bitrotted. The macOS interfaces had changed out from under it.

I imagine I could fix it up and get it going again, but I'd really like to make a version of Alpaca that works on Linux and Windows as well as macOS. The obstacle is that I need a rich-text engine that can do a good job with page layout, and I don't know whether there's a suitable one, or which Lisp (that isn't Lispworks) would be best to use with it. Qt maybe? Perhaps with ECL? I guess I'd rather use CCL or SBCL. Anybody know of a text-and-page-layout engine or collection of libraries that will work well on macOS, Linux, and Windows with CCL or SBCL?

Yes, thanks for putting it so concisely.

Personally, I do think Lisp is fun, and was having fun pretty much from the start. But, with how many people I've watched just bounce off of it, I simply can't bring myself to imagine that my experience is anything but unusual. Nor am I inclined to console myself with self-congratulatory stories about Blub.

I suspect that certain styles fit the way certain people think, and don't fit the way that other people think. If Lisp fits the way you think, then learning it is a revelation - it's like being let out of prison. But if it doesn't fit, it's really hard. And those who find Lisp to be "the right way" (for them) expect that if everyone else really understood Lisp, they'd have the same magical experience. When everyone else does not have that experience, they assume that those people just haven't really understood Lisp yet.

I think that this is a function of how you were taught, not a personal preference. An excellent teacher can make pretty much anything interesting to pretty much anyone.

Ah. Okay. I misread underpopular as unpopular. My apologies.

Chronically popular? Unless you're using some weird definitions, I would expect to see Lisp used more if you were correct.

The time integral of usage is maybe greater than most languages. Admittedly that’s a conflation of longevity with popularity.