Some thoughts about raising the profile of Lisp | Hacker News Reader

Some thoughts about raising the profile of Lisp

liam-on-linux.livejournal.com

93 pointsAndrewDucker178 comments

There exists a product that meets most of the suggestions in this article called LispWorks. It has an IDE runs on multiple platform and has the features that a majority of Lisp programmers would consider mandatory. There is a listener, editor, debugger, various browsers and more. You can deploy stand-alone binaries for the supported platforms. The user interface library uses native widgets for each platform. There are iOS and Android runtimes for core library code. There is FFI support for calling code outside of Lisp. LispWorks is a high-quality, professional product.

So what are the downsides? It isn't open source and you have to pay for it. At some point developers decided that they wouldn't pay for development tools. This has mostly been positive, but languages on the edges have suffered because of it. Yes, you can cobble something together using VSCode and various plugins, or use an Emacs environment. To me, the ergonomics of these solutions are inferior to an integrated solution like LispWorks and perhaps some of the other commercial Lisps I haven't used.

Some of the examples the author mentions were also tightly integrated environments. If you ever used Dylan, or Self, of any of the other commercial Lisps that have come and gone over the years you can see the allure of an integrated IDE.

LispWorks has been almost magical for me. It was expensive, $3100 for the 64-bit IDE and another $1000 for the mobile runtime, but the ability to develop/debug the core engine code in Lisp with the benefits of an integrated IDE, live code editing, REPL, etc. is more than worth it. The mobile products have native UI for the platform, but everything else is Lisp. You can most certainly develop and ship modern applications for desktop and mobile using LispWorks.

3100 is absurdly expensive when the price of development tools for pretty much every other language is zero. Even if it's that much nicer (which I'm skeptical), to practically use it I'd also have to convince other people its worth paying that much since I want a community. And then it's proprietary on top of all of that? Yikes.

Don't forget, that's an "enterprise" price and it's meant for "enterprise" users. Individuals aren't going to be paying that kind of money, unless they're independent Lisp consultants.

By comparison, IntelliJ IDEA Ultimate is something like $3000 for an individual license over the course of nine years. If you're not strapped in for a decade or more of Lisp, then the $3100 IDE probably isn't for you.

0: https://www.jetbrains.com/store/#commercial?billing=yearly

Good point. LispWorks has licenses for non-commercial usage that are a third of the price of the enterprise licenses. I wish the non-commericial licenses cost less, just to bring more users to the platform, but once again, maintaining a viable company selling developer tools is difficult.

I was going to ask about training and certification from LispWorks, so I went to the site and was tragically underwhelmed by the knowledgebase and anything else resembling Lisp training or certification.

If the platform is as powerful as claimed, I do believe btw, then it will take some time. It is a learned skill.

I guess where I am getting with this, if a company makes LispWorks and Common Lisp part of their long term tech strategy, I would think that LispWorks would be more of a strategic partner than just a tools vendor. And in that regard, they should be offering language training, tooling training as well as certification. This is the prototypical MS Dev playbook from the 90s and it worked amazingly well.

Sheparding library standards is another thing that I would expect out of a company like LispWorks

Franz (Allegro CL) has training & consulting:

https://franz.com/services/classes/

https://franz.com/services/consulting/

Very good point. I can only assume that their resources are so constrained that they don't have the ability to provide the level of training and support truly needed. There is a chasm that has developed, perhaps dating back to when many of the commercial Lisp vendors switch focus to Java, that needs to be closed. As you said, it is tragic in many ways.

IntelliJ community edition is free and modern and well maintained, and if you're buying an enterprise edition you probably got your feet wet with the free version first. Lispworks for individuals is still close to a thousand dollars and from the screenshots I could find anyway looks ancient.

If you want to check out the look & feel of LispWorks, there is a Personal Edition for that purpose:

http://www.lispworks.com/downloads/index.html

For what it's worth, IntelliJ CE has a lot fewer restrictions than LispWorks PE.

This is fine for a software evaluation period / demo, but it's not at all equivalent to the IntelliJ free offerings:

> There is a heap size limit which, if exceeded, causes the image to exit. A warning is provided when the limit is approached.

> There is a time limit of 5 hours for each session, after which LispWorks Personal exits, possibly without saving your work or performing cleanups such as removing temporary files. You are warned after 4 hours of use.

> The functions save-image, deliver, and load-all-patches are not available.

> Initialization files are not loaded.

On the other hand, I do wish more "expensive" software came with a demo mode like this (e.g. Mathematica).

> but it's not at all equivalent to the IntelliJ free offerings

true, but for finding out the look & feel it's sufficient.

Sometimes this also has been used in educational settings.

For those who want to get a feeling for the full product, LispWorks has full trial licenses.

Sorry but this really feels like the Lisp people have something very precious and they want to be very careful and ration what and how much they want to share with common people.

The entire ecosystem at this point screams that people who can't spend significant portion of their lives fanatically dedicated to the Lisp cause are better off not even starting with this.

Those are the surving vendors: higher-end tools for a niche market. The other vendors did not survive for various reasons. It has been tried.

I understand your point of view, but absurdly expensive is a very relative term. When I do a cost benefit analysis, I see that the cost for my use case is quite cheap. I have the benefit of only having to convince myself. That being said, I have worked at much larger companies who spent much more on various software licenses and wouldn't have blinked if I submitted an expense report for $3100 for a piece of software.

The IDE is proprietary, but the code is all Common Lisp. If one had to leave the platform, or the platform went away, you might have a problem with the native UI layer, but not with any other code.

The price does reflect the difficulties a company has when there has been a race to the bottom in pricing, or in the case of Apple and Microsoft, the floor was removed for development tools.

For a company, sure, it's nothing. But the problem is if you want your community to grow you need to appeal to hobbyist and beginners and students etc. That kind of pricing model just guarantees stagnation, and who wants to invest time in a stagnant technology? Lets say LispWorks is like 50% more efficient to work in if you know it, but javascript is free, has 50000x more users and jobs. Why would any sane person go with LispWorks? Of course I'm guessing most Lispers go with emacs etc. but those tools are of course also a huge problem. I really agree with the article, Lisp is a lovely language but it would be much more accessible if I were using it in VSCode

My issue with Lisp in VSCode is that it isn't really Lisp. Yes, you are coding in Lisp, but the language is just one element. I have tried the various plugins and they have a long ways to go. Unless you have tried an integrated Lisp environment, it is hard to completely describe it.

I understand your point about the pricing, stagnation and the job market. This is a problem any language outside of the mainstream has, whether it is Lisp, Dylan, Erlang, Clojure, etc. Someone can always come along and promote Javascript or some other more popular language as a solution.

Elixir was an amazing bridge between two language populations that would have died out. Ruby and Erlang.

It gave Erlang a huge immigrant population that frankly gentrified Erlang's 80s nerd vibe to a 2005 hipster aesthetic updated to 2015. 9/10 programmers writing code that runs on the Erlang VM are writing in Elixir. It also gave Ruby folks that faced the contraction of Rails as the startup juggernaut that it was, a place to go, and a runtime that enabled massive web scale (non-ironic). These folks had already hit these problems in their previous jobs, so the realworld experience of the folks that showed up was high. All of this adds up to a great outcome for Erlang, Elixir and the Ruby programmers.

It's mostly survival over stagnation. There were cheaper Common Lisp vendors and where are they now?

In my case I pay for it because I can afford it and would rather write Common Lisp than in Javascript.

I think the OP already addressed everything you said.

While I use SBCL, CCL, and CLisp for free I also paid for the $3100 professional LispWork license and pay the yearly maintenance fee.

Recently, LispWorks stopped running when I updated my M1 MacBook so I had to just use other implementations for a short while until LispWorks gave me a custom built beta. They really do provide good service.

If this seems expensive, in 1982 I got a Xerox 1108 Lisp Machine that cost $25K, which is about $72K in 2021 dollars. Sometimes good tools cost money.

Around 1990, my employer paid about £40,000 for a fully loaded Sun 4 for us to run LispWorks on...

Our local AI lab paid that for a fully loaded (memory, disk, screen) Compaq PC with a Lisp license (GoldWorks).

I was particularly impressed when we upgraded the RAM someone flew up from London to personally deliver and install it.

It was a Sun 4/330 - big VME based thing.

Edit: I checked and the 4/330 had a maximum of 96MB of RAM so the upgrade was probably to add an additional 64MB.

I think people are willing to pay for IDEs. PyCharm is a great example. But Python is wisely considered a commercially viable language whereas Lisp is... generally not.

Not to say it can't be or won't be, but most people won't pay for it for non-commercial projects, and it won't be used for commercial projects until there are many developers who consider it a good choice for commercial projects. Chicken and egg.

> won't be used for commercial projects until there are many developers

this is the crux of "modern" software development. The implicit assumption by the stakeholder is that their engineers must be replaceable, and so will only choose a tech-stack which has existing engineers as a commodity.

Whatever happened to specialized engineers - aka, craftsman - which you (as the stakeholder) hold on to for dear life, and pay _any_ price to keep? That is how you produce great products - talents that aren't bound by an ordinary, commodity language.

https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp for example, are used to produced some excellent games. But today, most AAA games are made via a commodity tech stack, and lacks the soul that would come from such a craftsman, using non-commodity stacks.

They early on used Allegro Common Lisp on SGIs for their game software development.

> Whatever happened to specialized engineers - aka, craftsman - which you (as the stakeholder) hold on to for dear life, and pay _any_ price to keep?

I'm not entirely certain about this, but I would say that management decided they didn't want to be "held hostage" by such craftsmen.

Why pay ten times the price for a single developer, and be locked in to their presence and whims, while you can pay three times the price for three developers, and be able to manipulate them as desired?

Of course, I'm not saying that's the ideal approach. It has rendered software a buggy and disposable commodity, one that both the creator and the user expect to be of limited life, aesthetic quality, and use.

In software engineering, "survival of the fittest" rarely means what we would like it to mean, some beautifully crafted digital artifact that attains both immanence and permanence by the sheer force of pure virtue or something. It rather means "move fast and break things" on the back of a full stack of breakable and non-breakable things: from UX to, well, democracy, and including the well-being of the plug and play devs.

Therefore Java is better than Lisp in this regard, design patterns are preferred over macros and DSLs, and a replaceable pool of fresh-out-of-school programmer are favored over an irreplaceable tenured craftsman.

I (and you, and everyone of a similar bent) can certainly try and do "my bit", pour soul and art and craft into it to the limit of my abilities, and push these abilities to their next limits, by my deadlines are still going to be set by factors that don't consider craftsmanship a top driver, and I'll have to scrum alongside the other cogs to deliver and get paid on what is usually an internal proof of concept alpha christened a release on the basis of an arbitrarily chosen date.

Occasionally, however, I get to brush up against the ideal for a few fleeting moments; either in code, or in thought and conversation. A glimpse of the sublime through the keyhole.

But then it's time for a meeting, and a bunch of new tickets are -- ding-ding -- in my inbox. And, wouldn't you know it, that button now needs to be pink. Top priority, grab some coffee and get cracking, we need it yesterday.

The problem remains getting people in the door. The masses need to be sold on Lisp first, and then maybe their employers will shell out for expensive environments.

I also have to add that that's incredibly expensive even among the paid dev tools I'm familiar with.

I've flirted with Lisp over the years. I appreciate its simplicity, I'm always casting curious glances when lispers talk about slinging code around, editing it live, this (alleged) blissful nirvana of pure digital expression. I used to work at a company that used lisp (I worked on other things, but I poked at it occasionally), and I've done a couple of small projects in Clojure, just to try it out. I've even made a couple interpreters/transpilers of my own.

But advocates always seem to emphasize how fun and effortless lisp is, how that's one of its biggest strengths. And frankly, that has not been my experience. Mainly because of the tooling.

I don't have the dedication to dive into learning emacs for something I'm merely curious about. Clojure's experience was less esoteric in some ways, but the tooling was more complicated in other, more Java-flavored ways.

If somebody made an all-in-one Lisp toolkit tomorrow, complete with a modern editor experience that just worked, I would revisit Lisp in a heartbeat. Who knows, I might become a convert. I doubt I'm the only one.

Check out Portacle [1], or if you already are rocking Emacs and SBCL and just want the bare minimum dot-emacs to kick around Lisp, check out emacs4cl [2]. There is an older project called "Lisp In A Box", but it hasn't been kept up to date so most beginners start with Portacle these days.

[1] https://portacle.github.io/

[2] https://github.com/susam/emacs4cl

Yesterday, I installed Portacle and then worked through the emacs C-h t tutorial, and then started playing around.

This is probably attempt five and the first time I haven't bounced off without even getting through the tutorial, but damn if it isn't fun.

So I think "we need to find a way to get people to the 'damn if it isn't fun' part faster and more reliably" is a worthy goal.

If you use any of the JetBrains IDE's then full Clojure support is just a plugin install away (Cursive), likewise with VS Code (Calva). It really is pretty effortless these days.

I really think Lisp's strength is also its biggest weakness. It's so flexible that it causes massive fragmentation. Everyone has their own toy interpreter. There's a massive schism between Lisp and Scheme. Nobody really seems to have rallied around Common Lisp, and thus it's not actually very Common in any sense of the word. On top of that there is no canonical implementation of "Lisp".

Lispers love to say "Lisp is a family of related languages" which is great but daunting to a beginner, and I think also deters people from contributing to the ecosystem, which is where I feel Lisp really falls down. There's just no ecosystem of reliable, standard-ish packages.

There's Ironclad for crypto, but in the readme it explicitly says not to consider it secure because there are trivial side-channel attacks against arithmetic depending on your implementation (again, fractured ecosystem)

There's lquery, CLSS, and plump for web scraping, but you can't scrape anything modern with them and the author seems to have abandoned the libraries

There's a GPIO library that simply doesn't work

Et cetera, et cetera, et cetera.

Compare that to something like Go or Python, where there are rich, polished, full-featured libraries for nearly every application you can think of.

I thought about writing a bot to scrape finance data in Common Lisp, but I didn't want to have to write the scraping and DOM traversal logic from scratch. I thought about using Lisp to have my raspberry pi monitor my hobby garden, but the GPIO library doesn't work at all and I didn't want to write my own.

I picked different languages and was immediately productive thanks to wonderful community libraries.

This is a weakness that is talked about more than it actually matters, to my mind.

In diving into libraries for Common Lisp, I'm finding more in the realm of "basically works as I would expect" than I would have expected based on how much this weakness comes up.

What is still jarring for me, is that image based development is just not taught or cultured. The iterative based approach that can be used in such an environment is just... so foreign to everything I have ever seen/done before.

Oddly, jupyter notebook style build ups are getting there. With the scary realization that a linear realization of the cells in your notebook is something that simply takes effort. Not something that is required for results.

I invite you to read https://www.dreamsongs.com/Files/Hopl2.pdf which was submitted for the History of Programming Languages conference in 1993. I don't see how you can say with a straight face that no one rallied around Common Lisp given knowledge of Lisp history. (Edit: Uncut version: https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf or you can just read this from 2008 which is the main thrust of the uncut content, mainly that there's a cycle of diversification and consolidation with CL consolidating a lot https://www.dreamsongs.com/Files/PatternOfLanguageEvolution....)

I'm not sure what you mean by "no canonical implementation" -- there's the ANSI Common Lisp standard, of which there are multiple implementations. Is this somehow a bad thing to you?

> Lispers love to say "Lisp is a family of related languages"

Not really. I think it's slightly more common for Scheme or Clojure programmers to claim Lisp relations, but it's just advertising. If having s-expression-ish syntax (with nothing being compatible to CL like a real Lisp dialect would be, and was given how much code in pre-CL Lisps could be run in CL unmodified) makes it part of the "Lisp family", then why not speak of the ALGOL family? It's tiresome semantics and from what I've read Common Lispers at least don't tend to do it.

> There's just no ecosystem of reliable, standard-ish packages.

Here's everything on Quicklisp: https://sabracrolleton.github.io/short-descriptions and a curated list: https://github.com/CodyReichert/awesome-cl

Yes, it's not as impressive as Maven. Yes, not everything is as well-documented as, say, PyGame (http://www.pygame.org/docs/ -- though not every Python library you'll find with pip is, either) or even the Common Lisp Hyperspec (http://www.lispworks.com/documentation/HyperSpec/Front/Conte...). Yes, some things are broken, or even abandoned, though in the latter case it may just be that they're "done" pending anyone coming up with a new issue or feature request. I've happily used web scraping libs to save my HN comments with their context, there's a good Twitter API lib I moved to when something broke the Python one I was previously using, I've orchestrated Selenium, I generated some FFI bindings to FMOD and had it working within a few minutes... My point here is just that there is an ecosystem for CL, and many things are reliable, when something works it's rare to stop working. Sorry about your GPIO experience, it happens, I had a bad experience trying to quickload a library that depended on iolib which opaquely depends on a custom C library the author also made and is not in my distro's package manager.

I'm not sure what you mean by "standard-ish" -- is Python's urllib3 "standard-ish"? What about urllib and urllib2? Do they qualify merely by being part of the standard library, or is it something else? My other guess is you mean something like "X is a common area of development in the current year, are there any packages dedicated to that area, what are they, and are they any good?" But this is a shaky categorization and in other languages changes all the time, not worthy of the attribute "standard" or even "standard-ish".

You're right though that what does exist is small and limited, and that's a natural limiting factor to growth, far more I think that what editors are available or easy to use. Quicklisp came about way too late. Yet the ecosystem continues to grow, so maybe you'll be willing to give it another chance in another 10 years.

> My other guess is you mean something like "X is a common area of development in the current year, are there any packages dedicated to that area, what are they, and are they any good?"

I think perhaps what Lisp lacks (or appears to lack) is tentpole developers such as - from the Python world - Mike Bayer (SQLAlchemy) or David Lord (Flask/Pallets), or the Django community, or Kenneth Reitz (Requests) who keep high quality 3rd party libraries going for a long period of time.

This is where Lisp should be able to kick ss. You can do literally anything you want semantically. I mean looking at the Stallman circuit Lisp [1] from 1975 should show the power language construction inside of Lisp. Most of the APIs I use don't have that expressive power. Another one that blows people's mind is the amb operator [2], and that you can construct new novel control flow directly in the language itself, including in libraries.

I frankly don't understand why the programmers of the world aren't demanding Lisp.

[1] https://electronics.stackexchange.com/questions/462215/repre...

[2] http://community.schemewiki.org/?amb

Eh, it's debatable. CL has got (github usernames) Shinmera, Fukamachi, ruricolist, edicl, among many others (I have to stop my list somewhere). There are some collectives that work on a handful of projects together too. What would help is more word about contributions that already exist -- blog posts (or if possible additions to the Lisp Cookbook (https://lispcookbook.github.io/cl-cookbook/)) and StackOverflow and so on. sabracrolleton has some amazing work for instance cataloging and comparing e.g. the various logging frameworks, test frameworks, json parsers, and more. (Example: https://sabracrolleton.github.io/logging-comparison.html) More of that I think will be more helpful than more tentpole devs, and more ways for Common Lispers to communicate what's out there even to themselves. A lot of unmentioned people are doing heroic work on those fronts already. Another thing that would help is just a critical mass of devs working in a similar area at the same time, but getting such critical masses is its own problem.

Shinmera is one of the big problems in that their web scraping library chokes on CSS selectors with parentheses and their gpio lib simply doesn't work.

Yeah, that's why it's debatable.. Some maintainers do a better job than others, or only with a subset of the libraries they've made. I found your bug (and the go-file-it-in-the-other-project non-response); in Shinmera's defense I'd want to be charitable and attribute most shortcomings to him devoting all his time to his video game.

One interesting advantage of Lisp (and dynamic languages in general, though Lisp's nicer) in cases like these is that if you can fix it yourself, it's easy to load the fix in. By that I mean, for example, suppose (I have no idea how this lib works) the lookup function has a pre-check on the string for invalid search characters before searching, but after inspecting the code you see no reason why it shouldn't work anyway. You can just jump to the code and edit the pattern or remove the error entirely, send the function to the REPL, and you're good to go. Save a copy in your own code if you need to persist your change. You could even do this while the debugger is active and not have to re-request the web page or lose whatever other state you'd built up until that point...

That's extremely cool, but if Lisp is more like Putty than Lego, and you sort of have to mould all features for yourself rather than plugging in some blocks, then it will struggle in this area, I think.

Having said that, I would love to use it more.

I don't see how you can say with a straight face that no one rallied around Common Lisp given knowledge of Lisp history.

What do you think went wrong, then? (Assuming of course that you do think something went wrong!)

One observation I’d make is that both Scheme and Clojure seem to be much more widely used than Common Lisp. My perception is that Scheme is still somewhat popular as a teaching language, and Clojure is somewhat popular as a real programming language for large-scale projects, but I barely hear about anyone using Common Lisp these days.

If I’m right, I think that adds to the feeling of fragmentation, as the official standard isn’t the most widely used variant.

I think ML is in a similar situation. I hardly hear of anyone using Standard ML, but Ocaml is alive and kicking.

Maybe my perception is wrong, though? Are there industries I’m overlooking where CL is bigger than Clojure?

A lot has gone wrong in terms of achieving high adoption, but specifically about something going wrong with rallying around CL, I don't think anything went wrong. No more are Maclisp, Interlisp, Lisp Machine Lisp, Zetalisp, Franz Lisp, Portable Standard Lisp, Spice Lisp... They were all slain or subsumed by Common Lisp. (You might have seen Franz elsewhere in this thread; rather than continuing it Franz, Inc. just developed Allegro Common Lisp separately. Spice Lisp meanwhile changed to become a CL implementation, became CMUCL, which was later forked into the now most popular implementation SBCL.)

Le Lisp/ISLisp are interesting European competition that didn't fall in line, but I don't ever hear about them, I only know they exist/existed, they might nowadays be effectively dead for all I know. Emacs Lisp is probably the biggest success in not caving to CL. Not big enough to constitute anything "going wrong" though.

I think your perception is wrong in two ways. First is the idea that Scheme and Clojure are somehow "variants" or "dialects" of Lisp. Scheme was never a Lisp dialect, it was instead described as "a LISP-like language, SCHEME, based on the lambda calculus, but extended for side effects, multiprocessing, and process synchronization." Also notice neither Scheme nor Clojure even have "Lisp" in their name, unlike all those other languages that got eaten by CL. "Lisp" meant something, and "Common Lisp" unified that meaning and I think deserves to be synonymous with "Lisp"; many writers have treated it that way. But Common Lispers are giving up that fight, because it's tiresome but also an understandable confusion not helped by Scheme or Clojure's attempts at capitalizing on some primordial idea about the good name of Lisp or whatever drives them to associate with the term. (#lisp in Freenode used to be only for Common Lisp, now in Libera #lisp is for all Lisp-likes and CL has its own channel.) Anyway, Scheme and Clojure have happily had their own evolution and separate largely incompatible s-expressions. I don't think their continued existence is a flaw against CL any more than another random programming language would be. One aspect of Clojure that might sting a little is that its entire reason for existing was because the author couldn't win political fights about having CL in production instead of the JVM.

The second way I disagree with your perspective is on prevalence. Scheme has had some success in teaching (mostly thanks to SICP) though Common Lisp was/is also used similarly at various places, however I think that's hurt [Common] Lisp more than anything. (Basically CL gets taught like Scheme, and so whether CL or Scheme is used students come away thinking they "know Lisp" without ever really having seen its OOP power, its handling of types, its condition system, its easy-to-define macros, let alone the trivial things like LOOP or SETF that make imperative programming possible and easy. It's like C++ classes that teach it as C-with-classes, but worse.) Scheme has also had success as GNU's official extension language (with Guile, which goes a ways beyond standard Scheme to be useful) and you see Scheme pop up in places like GIMP plugins. Racket seems like the most popular modern Scheme, aimed at being suitable for real work, but it has gone waaaay beyond standard Scheme and slowly seems to be becoming as large as CL. Real stuff is presumably made with it, not just education stuff or scripts or extensions, but I'm less familiar with what's going on. It may yet eat CL's lunch.

Clojure of course has been a rising star and has enjoyed a lot of success in real stuff. It's popular, it's fashionable, and in terms of projects-per-second your perception is probably right that it's more widely used than CL right now. Where I would draw disagreement is in total pound-for-pound code that's Out There. CL has the benefit of decades of existence, so for example https://www.ptc.com/en/products/creo/elements-direct has been developed for a long time and is made of several million lines of CL code, and that's just one project. If you only used "active" (i.e. someone executed it over last month) code perhaps there's enough Clojure out there now to be an interesting race though there's no way to really tell; if you allow for all the CL that has been written and is no longer run, I don't think there's any contest, CL has such a rich history. (A random application being Mirai https://en.wikipedia.org/wiki/Mirai_(software) with demo https://www.youtube.com/watch?v=-IRsYGfr4jo -- has there ever been a 3D modeling program written in Clojure? Will there ever be?)

https://github.com/azzamsa/awesome-lisp-companies is an ongoing collection of companies known to be using CL. In terms of "industries", right now quantum computing companies seem particularly drawn to CL. Symbolic math historically also, with Maxima and Axiom being still-working/developed code bases. (The latter is a million lines of literate CL.)

But drawing on legacy again rather than last-few-years stuff, an old quote by Kent Pitman seems relevant: "Please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list." We can of course add more things to the list if that would help, like Mars Rovers or video games, https://news.ycombinator.com/item?id=9510945 has a few more, in recent news I learned about https://www.reddit.com/r/Common_Lisp/comments/osnsgz/intels_... and https://github.com/shop-planner/shop3 was open-sourced in 2019. Is it dominant in any area (besides maybe quantum)? I don't think so. Against Clojure though I'm sure it dominates some areas while not at all winning at others, it'd be a case-by-case thing. Common Lisp is in a lot of places all over the world (it's had quite a legacy in Japan even), but not the most fashionable stuff, so it's also understandable that many people haven't heard about it, realized they're using it, or heard people talking about it. (Edit: one final example that's not too esoteric, if people have ever used pgloader for Postgres, it may surprise them to learn it's written in CL, and even more than that, used to be written in TCL and later Python before moving to CL...)

I think that name fight about the word Lisp is costing the CL community mindshare. Encountered as one of the first things about CL, it's not a good filter if you want to welcome people coming to the language curiously and pragmatically. Unless you especially want to select for curmudgeonly people.

> I think hardcore Lispers see stuff like a Lisp GUI and natively-graphical Lisp editors as pointless bells and whistles – Emacs was good enough for John McCarthy and it still is for me! – but they really are not in 2021.

That's almost the last line of the article, but it hasn't established any credible argument about why "they really are not in 2021" other than a much longer form of the same assertion.

> Summary: You have to get in there and compete with mainstream, play their game by their rules, if you want to compete.

1. Why does someone want to "compete" ?

2. What would you be competing with?

Convincing people that they could & should use Lisp instead of Python or Swift is facing stumbling blocks far, far larger than the user-experience in an editor/IDE.

> Convincing people that they could & should use Lisp instead of Python or Swift is facing stumbling blocks far, far larger than the user-experience in an editor/IDE.

It is a perennial complaint among those learning lisp that they didn't want to have to learn a new editor too. It's certainly possible that lots of other hurdles keep people from ever getting far enough to complain, but given that growth begets growth, fixing any hurdle would potentially have outsized gains.

Emacs is a huge stumbling block for me. Everyone used emacs and expected you to as well.

Common Lisp seems great - I'm so curious about CLOS - but I cannot get along with emacs, and I have tried.

If you happen to already be a Vim/Neovim user, the Vlime plugin + Parinfer (or at least Paredit) is pretty good.

If you don't use either Vim or Emacs... that's harder. You can use the Lispworks IDE, although that's limited if you're not paying for it.

I don't think the lack of tooling in Common Lisp is for lack of trying, but for lack of person-hours dedicated to open-source.

That said, there are a lot of gaps in the overall Lisp experience:

- Quicklisp is very unusual, and while it's quite an impressive effort (and definitely a good thing to have in the world), it's a bit odd coming from other programming languages.

- Roswell is great, but under-documented in some areas, and appears to be outright missing features that are actually specified in the docs.

- Qlot, like Roswell, is under-documented in some areas. In particular, using it in conjunction with Roswell can be unintuitive, and there's no guide out there (that I know of) to help with this.

- ASDF itself has the weird restriction that all of your source code has to be in one single directory. A lot of Lisp users I've spoken to don't see this as a problem, but that in and of itself I think is a problem and a reflection of the problems with the Lisp world when seen from the outside. Of course, Qlot alleviates this issue, but see above.

- There is a huge documentation discoverability gap in general. Docs tend to have very trivial examples, and hardcore reference material, with nothing in between. Figuring out how to use even popular libraries like Hunchentoot is not a trivial task.

- There's no actual spec for the SWANK protocol (that I know of), which makes it difficult to build new tooling around it.

- Editing s-expressions efficiently requires special tooling. Paredit is table stakes, but Parinfer is really what you need once you learn the basics and you understand how indentation works in Lisp code style.

Experienced programmers don't need a GUI IDE to get started. But they do need a base of sensible tooling. There will always be a push and pull between "harnessing the full power of Lisp" and "making the power of Lisp accessible outside of some very specific text editors".

I agree with your list, except for what I feel is the implicit argument behind:

> Editing s-expressions efficiently requires special tooling.

In the interest of clarity to non-lispers: without Paredit/Parinfer, editing S-expression is an experience equivalent to writing C++/Java - you roughly have that many delimiters to deal with when structuring code. Paredit/Parinfer make this process much more efficient than you can reasonably do for Algol-like languages, because of the inherent simplicity of S-expression structure.

Specifically it's really easy to, like, decide all this code here should live in an if statement now, something I still find kind of hard to do in C++

I think that for most people, s-expressions are harder to deal with than curly braces and begin/end.

1. Non-Lisp languages have fewer braces in general due to the presence of non-expression "statements" and infix operators, while in Lisp nearly everything is an s-expression. Common Lisp in particular has a lot of double parens, so even a garden-variety LET form already has _three_ levels of parens, or four when you have a function call involved:

    (let ((x (foo :a 1 :b 2)))
      (princ x))

2. Indentation and spacing conventions in non-Lisp languages generally make it easier to spot unbalanced braces, while Lisp indentation and spacing conventions are specifically designed to make the braces "disappear".

3. Non-Lisp languages have a wider variety of delimiters, which can help visually distinguish groups of delimiters in . Common Lisp and Scheme almost exlusively use parens (). Clojure has more variety in this area, and I have no doubt that this was a deliberate design distinction.

4. Lisp and Scheme tend to be more functional, and discourage things like early returns, often leading to deeper nesting in the syntax tree and therefore a larger number of parens to juggle. Many other popular functional languages generally use as few parens as possible, almost entirely eschewing their traditional purpose for function calls, so they don't share this problem.

The combined effect of these differences makes editing non-trivial Lisp code a bit tiring and slow/difficult for someone who isn't already very comfortable doing it without the editor support. That's a serious deterrent for would-be newbies, who could go try any one of 1000 other interesting good-quality languages out there.

Being forced to use _Emacs or Vim/Neovim_ of all things is a huge compounding factor. At that point, they'd be better off even with Clojure, which at least has excellent support in VSCode (via Calva https://marketplace.visualstudio.com/items?itemName=betterth...).

C-like curly brace pseudocode:

    function pythag2(a, b) {
      if (a <= 0 || b <= 0) {
        throw MathDomainException("Sides of a right triangle must be positive in length.")
      }
      const aSquared = pow(a, 2)
      const bSquared = pow(b, 2)
      return sqrt(aSquared + bSquared)
    }

Algol/Pascal-like begin/end pseudocode:

    function pythag2(a, b)
      if a <= 0 or b <= 0 do
        raise MathDomainException.new("Sides of a right triangle must be positive in length.")
      end
      const aSquared = pow(a, 2)
      const bSquared = pow(b, 2)
      return sqrt(aSquared + bSquared)
    end

Haskell/ML-like pseudocode:

    square = pow 2

    pythag2 a b =
      if a <= 0 || b <= 0
      then (MkMathDomainError "Sides of a right triangle must be positive in length.")
      else
        let aSquared = square x
            bSquared = square x
        in sqrt (aSquared + bSquared)

Lisp-like pseudocode:

    (defun pythag2 (a b)
      (if (or (<= a 0) (<= b 0))
        (error 'math-domain-error
          :message "Sides of a right triangle must be positive in length.")
        (let ((a-squared (pow 2 x))
              (b-squared (pow 2 x)))
          (sqrt (+ a-squared b-squared)))))

When writing this, the _only_ one that I had to stop and really think about was the Lisp one. With Parinfer, the parentheses completely disappear and I can code at the speed of thought, and I have the sublime Lisp experience that everyone talks about. But without it, I had to somewhat-carefully construct the "skeleton" of the IF and LET forms, and I had to literally count the parens at the end to make sure I did it right.

Moreover, I would bet good money that for most inexperienced programmers, the Lisp version would be the hardest to read.

The IF expressions have either an ELSE or not (first two examples)...

I don't use Parinfer, but my editor shows matching parentheses while typing -> I don't need to count.

> The IF expressions have either an ELSE or not (first two examples)...

This was specifically part of the example. Early returns either being not present or not idiomatic changes how you write code at a fairly basic level.

Honestly, I've written a fair amount of Lisp, and sometimes Lisp-like languages (e.g. GCC RTL), and never felt the need for either paredit or parinfer, and virtually never use structural navigation either.

Somehow the assisted indentation in Emacs is enough that I've never been confused about parentheses or felt the need to have them typed for me. I find them visually clear, so long as the indentation is not misleading.

I do find the close-paren matching which lets me know when a mismatching parenthesis is typed quite useful though. I use that in all programming languages, sometimes to tell me where a long block begins.

So I wouldn't agree that paredit or parinfer are essential.

For me, the fastest available cursor key repeat rate is more essential. I code like it's a video game: Hold down cursor key, let go when it lands in the right place. Write what I need, newlines and all, use <tab> or C-M-q a few times to trigger automatic indentation as needed. But this applies to all languages, not just Lisp.

Agree 100%. As a newbie in Lisp land, I am loving it, but using just electric-parens mode and it works awesomely.

> If you don't use either Vim or Emacs... that's harder.

Honestly, it's full on "hacker heresy", but who would, at this point?

That's part of the disconnect. The current generation (hell, the last 3-4 generations of programmers) has earnestly given vim/emacs a fair shake and found the whole paradigm of CLI editors wanting. And that's old news; that shoe dropped a couple decades ago. To them it's not a serious tool; it's a "toy" you dabble in for historical re-enactment like you would with film photography versus digital. Or like writing traditional console games in assembly. A curio.

There were real advantages to oldschool CLI editors, and it's not like they've gone away, but the world moved on. GUI editors have grown so many of their own advantages that you'd have to live without that it stopped being worth it a long time ago. Hacker heresy, like I said, but it's exactly that sense of "things you're not allowed to say" that breeds the disconnect of "why isn't anyone using this?"

I wouldn't be surprised if someone has a solid VSCode language server for LISP out there, and it'd be damned ironic — but not surprising — if something like that grew legs with the traditional community being completely oblivious to its existence.

For what it's worth, Neovim has at least 3 solid open-source GUI frontends, a closed-source full-fledged IDE, and at least 2 more experimental open-source ones.

And your guess about LSP is exactly why I think Swank not having a protocol is such a problem. It discourages entry and expansion.

I don't think that's true. I'm in this current generation, I use VSCode for almost everything, and I don't see Emacs and Vim as toys. I see them however as a very large timesink, and I don't know if it's the best way to invest my time. Grinding leetcode and studying system design can get me into a big company that pays very well, almost 5 times more than what I make currently. Learning about JS, the web in general, the cloud can be used in my day job, and can allow me to easily spin up my own product. Learning about technical writing and blogging can increase the value of my "personal brand". Learning about people and how to navigate an organization will be useful wherever I am. Contributing to open source can also help my "personal brand", and it gives me a sense of accomplishment. And that's only for the "work" part of my life. I don't think Emacs and/or Vim are a good investment compared to those other things.

On the other hand, I know that a lot of people use them, and like them, and I respect that. If I could take a pill to instantly know how to use efficiently one of them, I would. But right now, they're far from a priority.

Ah yes, the last 3-4 generations of programmers that have lived and died out in only 8 years. Behold the most popular editor chosen by 1366 programmers on HN in 2012 https://news.ycombinator.com/item?id=3717754 is none other than vim.

Sure, basically no one uses vi. vim is not vi.

There is an LSP backend for Common Lisp (two actually if memory serves) that probably just wraps the venerable Swank, but I haven't tried it. I like vim + slimv + all my other plugins.

Here,

https://franz.com/products/allegro-common-lisp/acl_ide.lhtml

http://www.lispworks.com/products/lispworks.html

Emacs is a subset of the whole experience.

Thanks. Just installed. Beautiful IDE.

>>Emacs is a subset of the whole experience.

Can you please elaborate on this? How is emacs a subset of this IDE?

Emacs is a subset of Lisp Machines developer experience.

I was exactly there, after experimenting with someone else's CommonLisp and being amazed at how fast and concise the code was.

Result: learned emacs. I have to say I don't regret a second of the weeks it took me to fully grasp it :D highly recommend going down the rabbit hole.

I would recommend perhaps to start with Spacemacs though: everything is ready to do the job: just install the "layer" you want, in this case, Lisp, and you're set... if you don't like Vim just make sure to not choose "evil-mode" (Vim bindings on emacs) as I think that's what you get by default.

> I think hardcore Lispers see stuff like a Lisp GUI and natively-graphical Lisp editors as pointless bells and whistles.

It's a solved problem to be honest. Those that care about building multi-platform GUIs simply pay for a LispWorks license.

The point of Lisp is to use it to create good tooling. Whether it's MOP or Racket's macro system or ELisp... the point has always been maximal power and customizability.

Lisp is the system to create systems. It's not the endgame. It's not a finished product. That is the point.

What is better tooling? What improvements can be made? How can it be done?

These questions are wonderful questions to consider and experiment with. Every lisper does - it's the entire point of using lisp. Everybody has answers.

There are, however, some lispers who, never thinking they could provide all the answers, spent countless days to create tools to make it easier for other people to express their answers. Macro systems... ELisp... MOP...

We shouldn't expect all the answers to be given to us. It's not wrong, but it's so limiting.

(P.S. JavaScript is what happened when Brendan Eich was tasked with adding Lisp to the browser, but was asked by the suits to make it look like Java. The entire area of thought comparing JavaScript tooling to Lisp tooling runs really deep. Are they even different?)

That sounds kind of nice in a weekend tinkering project way, but what about getting actual product made? If I'm using something like typescript, I download a free IDE, optionally install a couple plugins, and in ten minutes I'm productively actually making something and I can easily share it with the world for them to modify. The Lisp thing sounds like I spend the rest of my adult life trying to build the perfect setup instead of getting on with actually making something?

It sounds like you have found a solution that works well for you. I don't like to tinker around with my coding environment, which is why I pay someone to do that for me. The primary purpose of my software development efforts is to ship products and generate revenue. Anything that I can do to optimize this process, I will do. If I thought using VSCode and Typescript would reduce costs and increase efficiency, I would use it. This simply isn't the case for my use case.

If your primary use case is developing websites, then VSCode and Typescript are perfectly good solutions.

I guess my main point though is that most other languages don't require complex/expensive tooling though. Like, I also use VSCode for writing C++ microcontroller code and writing python scripts or writing C# game code for Unity. And not just VSCode so I don't sound like a shill here, I'm also able to use the same set of unix utilities, other generic tools, etc. without having to adopt an entirely new tool stack. I just look at the Lisp situation and it's either something like Emacs which just does not appeal to me, or proprietary and expensive tools where I worry if the vendor will even be around in a few years

I am moving away from VS Code and IntelliJ for this exact reason actually: on emacs, there's ALWAYS a package that supports anything you want. And it's so lightweight compared to either VSCode and IntelliJ, it's really refreshing...

Have you tried emacs/SLIME? It really isn't complicated, in fact it's the most straightforward stack I've ever tried except for maybe JS right on the browser.

In March 2020, somebody asked PG what language/tech he would recommend for competitive advantage, if they were willing spent 1000 hours learning it ("Is it still LISP?"). He said Clojure.

https://twitter.com/ndehouche/status/1240218141742878720

Personally, I like to imagine PG scoffing at the idea of spending only 1000 hours (6 months, 40 hours per week) learning Lisp, then sarcastically recommending Clojure aka macro-less, continuation-less, Java-lisp.

You want to spend 10 minutes? Use Typescript! ;)

(I love Typescript too btw.)

> Clojure aka macro-less (...) Java-lisp

Unless something changed in the last ~2 years since I worked with it, Clojure has macros.

Most Lisps (fex Common Lisp) don't have continuations. And yeah Clojure definitely has macros.

Here are the colour versions of that screenshot.

https://franz.com/products/allegro-common-lisp/acl_ide.lhtml

http://www.lispworks.com/products/lispworks.html

https://ccl.clozure.com/docs/ccl.html

https://apps.apple.com/de/app/clozure-cl/id489900618?mt=12

Oof, screenshots that haven't been updated since the Windows XP era do not inspire confidence.

Much better than the article one.

I feel you on your dismissiveness, I had the same reaction years ago. Even using modern Windows UI (which it does) doesn't improve things that much though. Of the two, I like Allegro's UI a bit more, but it's still dated. I haven't convinced myself to buy a license for either of them, and I don't get the sense that for either of them their IDE is anything close to a cash cow, and hence there's little motivation to invest more effort into it or even updating the screenshot.

But if I were running a business using Lisp, I'd cough up licenses for employees if they wanted to use one (and encourage them to try the free demos if they're new and aren't sold on emacs or vim or one of the other newer plugins for VS Code/Atom/Sublime). It's similar to how many Java shops cough up licenses for IntelliJ, except JetBrains has a sane business model that's not straight out of the 90s, you can trust they'll continue to make improvements to it and not drop a Big Update at some point that you have to debate whether to pay for, and for both an organization or an individual it's very affordable.

I don't think I'm being dismissive. Windows XP came out 20 years ago, and it's been practically out of use for a decade. Things like that scream "unmaintained"

This is commercial software, not something that a dev dropped into github and left untouched.

Most likely their customers don't use the screenshots on their buying decisions.

When you ask $3000 per license surely updating those few screenshots once every few years is worth it if it generates even a single sale.

I use LispWorks on Apple's current OS (Big Sur) and on a current Linux. The IDE picks up newer looks in many respects, since it uses a native graphics backend (Cocoa, Windows, GTK).

If a new OS would cause UI problems, they would fix that. Usually just shipping tiny patches of compiled Lisp code.

It takes a bit more than one screenshot for me to think "unmaintained", like one click to the Support page and another click for details on a bullet item takes me to https://franz.com/support/apple_silicon.lhtml and I'm at least assuaged that it isn't abandonware even though I'm not an Apple user. But in any case I still get a bad feeling from the ancient images and sympathize with similar negative reactions, whatever they are in detail; for you it's a sense of being unmaintained and for me it's a sense that they don't care very much about the product and aren't interested in attracting new customers. And this is just from the window chrome, looking at what the screenshots actually depict produces another set of emotions that I don't think anyone at either company cares about exploring. At least LispWorks' has syntax highlighting... (In case any employee happens to catch this, take a look at https://www.jetbrains.com/idea/ and compare.)

I do feel the same but let's face it, no amount of PR magic will make them attract new, young developers.

Imagine a venerable tool in the late 1990s using a screenshot of the tool in use in the late 1970s as part of its marketing campaign.

Franz is also going to offer the Allegro CL IDE to be used in the web browser, soon.

It looks perfectly fine if you ask me:

https://i.imgur.com/ml4jlYB.png https://i.imgur.com/qkgIXhE.png

Sheesh, that's quite a lot of

BRICK WALLS OF ALL-CAPS SHOUTING.

I love lisp and emacs but saying that all the good tooling is in emacs and emacs is not like modern ui and so should be made like the modern ui is arse about face.

Making emacs like other ui would be wholly counter productive, it's just not the paradigm the whole system is designed for.

The tooling for other editors should be created or updated to allow developers to use their editor of choice.

And I know the come back will be that all the developers are in emacs and won't develop for the other editors and unfortunately that chicken and egg scenario needs to be solved.

Sticking an ipad on a horse and cart will not make it a Tesla just like updating emacs to have some buttons and CUA won't make it appealing or useful to a sublime user.

> The tooling for other editors should be created or updated to allow developers to use their editor of choice.

Doesn't LSP enable this, to a certain extent?

Handing out Dale Carnegie books to Lisp evangelists would be a good first step.

I laughed out loud. Working through SICP right now and yeah... All the forum posts I've seen when troubleshooting my lisp code make the community seem insufferable.

I don't mean this in any sort of derrogatory way at all but I honestly think Lisp programmers might have a higher rate of autism. Also, seemingly higher IQs, cause it seems like anyone who actually builds software in Lisp extensively is some kind of savant.

Apparently, there are some VS code extensions for Common Lisp, e.g. Alive: https://marketplace.visualstudio.com/items?itemName=rheller....

I will check it out.

If you're worried that Emacs is what's holding Lisp back, the answer is definitely to build first class VSCode support, not to try to make a new modern Lisp environment.

I remember seeing this post on r/lisp earlier today, and the thought that I had then was that perhaps the reason why Lisp hasn't embraced "modernity" is because many Lisp programmers have not only embraced Lisp the language, but also Lisp the ecosystem, one that came from a world completely different from today's popular commercial systems. Lisp's heyday was during the time of Lisp machines and interactive environments/operating systems such as Xerox Interlisp and Symbolics Genera. While we don't have these things today (though thankfully Interlisp Medley was made open source), we still have Emacs as a surviving and thriving vestige of that world. I see the same thing in the Smalltalk community, except Smalltalk still has modern evolutions of the Smalltalk-80 environment in the forms of Squeak (which is more conservative) and Pharo (which has gone beyond Smalltalk-80 in terms of features). Many Smalltalkers relish the "other world"-ness of Smalltalk environments. These Lispers and Smalltalkers, among others, are still the keepers of the "the right thing" (coined by Richard Gabriel of "Worse is Better" fame) and "The Unix Haters Handbook" flames, and they want to evangelize their world.

I disagree with the notion that in order for a programming language (or any other software product, for that matter) to thrive, it must conform to the "standards" of the most popular platforms and tools. In fact, I argue that providing a compelling difference that is substantially better than the competition is what makes a programming language or software product thrive. Why are Lispers so attached to Emacs? Why are Smalltalkers so attached to their environments? For them, they feel that these things are compelling enough to provide an advantage over "standard" tools. I love vi, but I have great respect for Emacs' extensibility through its own Lisp.

I also disagree with the notion that a tool needs to be "modern" to be popular. Now, if modernity means running on current operating systems and adhering to current protocols, then I agree. However, if modernity means conforming to mainstream expectations at the expense of a tool's identity, then I disagree. Here on this forum we have a sizable, vocal segment who speaks out against "modern" trends such as the flat UI aesthetic, desktop environments that are designed for mobile computers instead of workstations, Electron apps, Web framework churn, and large siloed applications. Many people find Lisp, Smalltalk, Plan 9, and the suckless (https://suckless.org/philosophy/) community of traditional Unix users refuges from this type of "modernity," and they want to keep things the way that they are.

Now, this does not preclude Lispers (and Smalltalkers) from embracing mainstream platforms and tools and building solutions that will make Lisp a more attractive solution within these worlds. After all, I love these "other world" environments, but my livelihood relies on coding for mainstream platforms. However, I wish the author had a better appreciation regarding why Lisp programmers evangelize the Lisp world instead of making efforts to have Lisp conform more to mainstream platforms.

They exist, but keep being ignored by FOSS devs, because "evil commercial vendors" buuu.

https://franz.com/products/allegro-common-lisp/acl_ide.lhtml

http://www.lispworks.com/products/lispworks.html

The cheapest LispWorks hobby license is $500 USD in North America [0].

The cheapest Allegro license is $599 USD [1].

If you're already a highly productive professional, this is probably totally worth it. For everyone else, there's no way you're going to get newbies to pay even close to that much, while DrRacket and Thonny are both free-as-beer and free-as-in-freedom.

0: http://www.lispworks.com/buy/prices-1h.html

1: https://franz.com/products/packages/

> The cheapest LispWorks hobby license is $500 USD in North America [0]. > > The cheapest Allegro license is $599 USD [1]. > > If you're already a highly productive professional, this is probably totally worth it.

If I'm a solo developer, then sure, but right now I cannot think of a single non-trivial pro or hobby project that is run completely solo.

Asking contributors to shell out a sizable amount of money before they are able to submit PRs is a deal-breaker. It's just no going to happen no matter how productive those products make me, because next to none of my work and/or hobby code is done with the expectation that other people are not allowed to contribute.

Unfortunately the prices don't scale down, and there don't seem to be places that would offer installment payments...

Despite pretty sure being among better paid people in Poland, I'd need to save non trivial amount of my salary each month for a chance to buy necessary set of LW licenses for it to make sense :-(

I don't know....FOSS tools have their advantages, and I don't think it's unreasonable for FOSS developers to ignore proprietary tools, even high-quality ones. I think the advent of affordable and later FOSS alternatives to Lisp and Smalltalk during the 1990s when the cost of Lisp and Smalltalk development tools were generally high helped hinder the adoption of Lisp and Smalltalk, and these communities are still dealing with the effects of this; while there are high-quality FOSS implementations like SBCL and Pharo, respectively, they have to compete with the likes of well-funded languages like Java, C#, and Python. Even newer languages such as Rust and Julia have had rather prodigious growth. In addition, no major company is backing FOSS implementations of Lisp and Smalltalk like how Python and Rust are being backed.

Perhaps one of the big keys toward broader adoption of Lisp is for a large corporation to embrace Lisp and to participate in the FOSS development of the Lisp ecosystem. Unfortunately it is hard for companies to solely focus on developer tools since they have to compete against FOSS offerings.

Here is a challenge to the Lisp community: Show us your Lisp on Rails. Show us how much more productive you will be using Lisp on Rails compared with Ruby on Rails. People learned Ruby just to use Ruby on Rails. People will learn Lisp just to use Lisp on Rails if (and that is a big if) it truly is much more productive than Ruby on Rails.

And copy how Ruby on Rails was promoted. It worked.

Why not just use Clojure?

This is like asking "why not use Haskell?" in a Kotlin thread.

I don't follow.

For context, I've been thinking about learning Clojure.

I'm pretty new to the Lisp world--I went through most of SICP in Scheme years ago, but that's about it.

In 2012 Clojure was HN's second favorite programming language: https://i.imgur.com/toGKy21.jpg

What's the best argument for me learning a Lisp besides Clojure?

Serious question, I'm not particularly attached to Clojure, and I want to know what I will miss out on by going with it instead of some other Lisp.

Learn it, it's great, productive, wonderful ecosystem and community, and it will get you a Lisp variant that runs in a modern deployment context and has access to maybe the biggest ecosystem of libraries out there.

You'll miss out on some of the details of cons cells, symbols and macros and such, but you'll get the meat of learning to work with a REPL, macros and all that.

Fair enough, I thought it was snark so I responded with snark.

I think you should try both. Lisp as a language gives you a lot more freedom than Clojure, but Clojure has a more consistent and elegant language design. Clojure focuses on mostly-pure functional programming with immutable data structures, while Lisp lets you do pretty much anything anywhere, including hacking deep into the runtime itself (Clojure lets you do this to some extent too, but not as much as Lisp).

Some videos that are worth viewing, which together I think provide a good sense of how the languages differ:

- "Common Lisp for the Curious Clojurian" by Alan Diepert. A very lucid side-by-side comparison of Clojure and Common Lisp; assumes some but doesn't really require much knowledge of Clojure. https://www.youtube.com/watch?v=44Q9ew9JH_U

- "Maybe Not" by Rich Hickey. An unusual but thoughtful take on "types" in programming, which I think cuts to the heart of what Clojure is all about. https://www.youtube.com/watch?v=YR5WdGrpoug

- "Immutable Conversations - Common Lisp" interview with Alejandro Serrano and Michał "phoe" Herda. Demonstrates the deep programmability and flexibility of the Common Lisp runtime, including its unique "condition system". https://www.youtube.com/watch?v=pkqQq2Hwt5o

Thanks!

With what editor? (Rhetorical question, emacs and vim are dominant there too, providing another data point for "it's not the editor" that's somehow hindering Common Lisp's resurgence.)

Clojure with VSCode and Calva is the best development experience I've ever used in any language.

I have a good experience with Cursive IDE, built upon Intellij IDEA.

I'll bite.

Tooling. The CIDER devs are doing a great job, but Clojure gets to suffer by being tightly coupled to the JVM. Meanwhile CL thought deeply about having a truly dynamic developer experience, for example look at the CL condition system.

Multiparadigm. Sometimes I want an object, sometimes I want goto, sometimes I want to mutate a thing. CL is probably the least opinionated language every made, Clojure is highly opinionated. For a long-term investment, I want to have options.

There's a spec. CL is done. I have faith my code will continue to run as-is well into the future. Hickey very much values long-term backward compatibility and maintenance today, but who knows what he'll value in the future? For that matter what does Clojure look like if he gets hit by a bus? I don't want to have to worry about things like that.

CL has more parens. People love to complain about CL let's excessive parens, but I find them much easier to read, but more importantly they are much easier to work with when using structural editing tools, and easier to work with in macros. I find Clojure's extra syntax for literals to be a net negative.

No JVM. The JVM is a mixed bag, if you need it for operational reasons then its a huge win, but if you're not constrained by somebody else organizational policies, then I think the JVM is a net loss. Instead of dealing with the JVM, CL gives you a variety of tools to tune performance to make your programs scream.

Reader macros. Clojure rejects them as a giant footgun, CL gives them to you since CL is all about maximal power and flexibility for an uncertain future.

Thanks!

I'm curious why you think the JVM is a net loss if you don't need it, if you want to elaborate on that.

For example some Lisps allow us to save the state of the heap to disk easily, incl. the runtime, to make an executable. This is then no special feature, saving is done in a second and starting the executable is also extremely fast. There is no extra tooling needed. That way one does not need to restore the state by loading a bunch of files. The default JVM does not support that. Code is by default compiled to native code -> no JIT needed.

The JVM also does not support optimization of tail function calls into jumps. Thus the language either has to implement it in a slower way, provide limited hacks around it or omit that feature. Various Lisps provide full TCO as an optimization feature in the compiler.

The JVM is also not optimized to represent Lisp data. For example the numerics of Common Lisp are relatively powerful and thoughtful designed with bignums/fixnums, ratios, complex numbers, etc.. The JVM has its own idea of numeric types and its operations.

Common Lisp has CLOS as a very dynamic object system with an optional meta-object system. That maps also not directly to JVM classes/objects (no full multiple inheritance, no multi-methods, no method combinations, ...). One can implement that on top of the JVM, but it will always be slightly slower than a native Lisp implementation.

Looking at compiled code / backtraces / ... on the JVM will always look slightly alien to a Lisp programmer - some Lisp implementations have simpler stack traces, tailored for Lisp.

The positive side of the JVM is the better integration into the IT landscape, modern garbage collectors, a mature runtime with lots of users and the direct integration into Java/... software on the JVM.

If we look at Common Lisp, there is a full implementation of Common Lisp on the JVM called ABCL. That's a great achieve, but native implementations like SBCL are much faster and thus more widely used amongst CL users.

SBCL comes with the added bonus of an excellent native code compiler written in Lisp itself. I would recommend the SBCL compiler also for beginners, because it gives a lot of warnings and other information at compile-time.

> For example some Lisps allow us to save the state of the heap to disk easily, incl. the runtime, to make an executable.

Wait, hang on. Is this feature analogous to Smalltalk’s image-based environment? Does this mean I could run a Lisp REPL and “save all” then “restore all” later? Or is this a subset of what Smalltalk does? Excluding the Smalltalk GUI environment, of course.

Asking because that’s the biggest “you must try it to understand the experience” selling point of Smalltalk. Some Lisps (hopefully some of the same ones?) have a really nice interactive debug mode, which IIRC is another Smalltalk selling point.

If those are both covered by a single Lisp, I’d like to try that out instead of Smalltalk, because Lisp’s structure makes more sense to me. I am biased towards Clojure because I like its opinionated language design choices irrespective of Java interop. Mainly the seq abstraction and immutable-by-default. A first-class debug REPL and “save / restore the whole runtime environment” are both things I want to examine though.

Yes. Saving to an image, loading the image, modifying the image while the program is running and seeing the program update without recompilation is part of the magic of programming in a good Lisp IDE.

Smalltalk was influenced by how Lisp used images and went on to build on the concept of images and do all the other things that make Smalltalk Smalltalk.

Various commercial Smalltalks have come and gone over the years. I am assuming you have been looking at either Squeak or Pharo. Both are nice, but the user interface is trapped inside of a windowing system inside of the environment you are executing in. A Pharo program will present a window and inside that window is another desktop environment. This seems unnatural to me, but it is the result of how Smalltalk works; it does everything. If you have the time, you can read about this in the Smalltalk-80 books.

LispWorks allows you to use the native widgets of the platform you are targeting. Your program will use native widgets. Clozure CCL (not Clojure) also has native widget support. Take a look at the OpusModus [1] composition program. It is written in Clozure CCL and is very polished, professional application.

It sounds like you already understand the philosophical differences between Lisp and Smalltalk. You can use an object system in Lisp, but it is option. Smalltalk is objects all the way down. Lisp can be molded to operate in variety of idioms, so you can create your own opinionated system, but one is not dictated for you.

[1] https://www.opusmodus.com/

Lisp had images from day one -> already in 1960. The feature of saving and restarting was already developed then.

Yes, one can save all and restore it later. Problems are then naturally: open files, network connections, native threads, ... those are usually not restored after load. The state of a network connection is not to be restored.

Interlisp had also image-based development which is another step up: source code is managed and stored. Most Lisp systems nowadays save source code in files and can keep track of locations, etc. Thus the source code management feature is usually stronger in Smalltalk. Smalltalk usually also has a VM with machine-independent code, where Lisp systems often have machine-native code. Thus in Smalltalk one can transfer an image to a different machine architecture, where most Lisp systems only transfer images on the same machine architecture & operating system combination.

The Java VM lacks this easy memory image feature.

You CAN write CL in a very Clojure style, as there are libs for both the seq abstraction and immutable data structures. It won't be as ergonomic as in Clojure simply because the standard lib is not built around assuming these by default and its unlikely other libraries will be using them as well, but you can have a very Clojury experience if you like.

fyi http://www.sbcl.org/manual/#Saving-a-Core-Image

Has this guy heard of spacemacs? At least for people familiar with vi bindings, it can get their foot in the door with a more IDE-like experience quicker while retaining and emphasing the unique advantages of emacs as a platform. I think for a lot of users, getting that taste of the tool's capability early on is what motivates them to embrace the platform as a whole, even if they don't stick with a heavy, general purpose emacs "distribution" in the long run.

Well, he doesn't seem to even be aware of Allegro, LispWorks and Clozure CL.

Everyone who could possibly care about Lisp already knows everything they care to know about it. It is trivial to install a fully functional development environment on any machine, and be up and coding in minutes. Anyone curious has done it, some many times over.

Lisp has had six decades to take the world by storm. It is at full saturation already. There is absolutely no need to raise its profile, or room to raise it in.

> Everyone who could possibly care about Lisp already knows everything they care to know about it.

I think you're in a bit of an HN bubble if you honestly believe this to be true.

And yet, Clojure keeps growing, year after year.

Not true, I’m a couple years out of college, and only recently stumbled on it because of a Paul Graham essay.

I’d say a lot of people (including professional software engineers) have no idea about lisp

Is this what people want, though? Why wouldn't we push for more open, expressive and semantic languages, instead of trying to dust off older languages because of some abstract warm and fuzzy feeling?

TFA seemed neutral to me on this question. It was merely trying to answer "why isn't Lisp more popular" not making a judgement on whether or not doing so would be a good thing.

[edit]

And the source of the question of Lisp's popularity was here: https://www.reddit.com/r/lisp/comments/pdpl5w/hell_is_other_...

[edit2]

And the fact that the author was reading comments in /r/lisp is a pretty strong indication that they have positive thoughts about lisp...

I've been really impressed with Chialisp, a functional smart contract language that's really really cleverly designed to be auditable, safer, and more efficient than Ethereum/Solidity. There's not a lot of tooling for it yet but this would be a great place to add it.

https://chialisp.com/

I'll bite by answering a different question: What brought me to Python?

1) The Standard Library. I should say this while biting my lower lip with a "That ass!" look on my face, nevermind the usual xkcd. I do not have to hunt down twelve packages on CPAN, wondering if any of them will work on Windows, or require an enormous set of dependencies, or if the eighty percent of the topic it actually accomplishes overlaps with my needs. Nope. The Standard Library just has all of that, in a fairly conventional syntax. I do not want to re-implement a spec from scratch, either.

2) My first IDE was Notepad. Now I use Notepad++, largely because it auto-saves. I do not want an IDE that looks like the cockpit of an F-15, I just want to write a few lines, see if they work, and continue.

3) One of the PEP 20 bits, goes something like "there should be one obvious way to do it." And if there isn't, there's some strong cultural idiom that pushes it.

4) I could make it work on Windows. I didn't have to defend my choices to a bunch of people who will relentlessly shill their own distro. I work in a Windows shop, I am not going to jump ship just to use your language, for fuck's sake. I curse here because you would not believe the number of times I have had to have that incredibly irritating conversation.

5) There's just Python, no need to pick. (Okay, now I have to deal with Python 2 and Python 3, for what are Very Good Reasons that, no, I'm not going to explain to you, but in the beginning, that's all there was).

According to The Lisp Curse, Lisp falls afoul of #3 and #1. Nothing really stops it from correcting these. We have enough Lisps that #5 is a problem. All of the odd-numbered ones are really a variation on a theme, the Paradox of Choice. #1 is a lot of hard work, on top of it.

Good thing reality seems to disagree with Lisp Curse.

Wonder why more people don't point out the much larger scale of the problem in C++ (yes, they do point it out, but where are the capitalics about "The C++ Curse"?)

As for #5 - that's mostly a problem with Scheme, where implementation specific issues abound, but most other languages in the family don't have multiple differing quality implementations.

In fact, a common argument for Common Lisp instead of Python, is that unlike Python Common Lisp has a standard and implementations adhere to it - and the rest is handled by common portable libraries. One doesn't have to deal with spec that amounts to "what's the actual emergent behaviour of PyEval_FrameEx".

Try Racket and DrRacket.

Racket and DrRacket are great, but Racket has a ways to go if you want to package and ship desktop and mobile applications. It can be done with a lot of work, but the result isn't great.

Racket continues to improve. I would love to see more energy put into making it viable as a commercial application development system.

>>I would love to see more energy put into making it viable as a commercial application development system.

From what I learn from reading about Racket from people in this forum. It's supposed to be a language to develop other languages. The other uses are to teach introductory programming classes. It's not designed to be a full fledged production grade programming language.

They also seem to be working on discarding the Lisp syntax entirely and making a new language out of Racket with a new syntax called 'Honu'. The project name is Rhombus/Racket2.

I dare you to build a several thousand LOC project using DrRacket.

I've spent way more time with Racket than Common Lisp (just picked it up over the last month) and Racket just doesn't have the same development experience as Common Lisp. There's no iterative / interactive development in Racket, by design [0]. That means you have to stop-and-reload-the-world every time you make a change.

[0] https://blog.racket-lang.org/2009/03/the-drscheme-repl-isnt-...

Great article - thanks for sharing!

All good ideas. However nobody in the Lisp community seems to actually want to do the work. Despite claims that Lisp is so much more powerful than anything else that it should be “trivial” to do. A bit like people introducing themselves as book writers, without actually ever, you know, having written any books. They are brilliant writers in their own heads but just can’t seems to actually deliver their masterpieces to the real world. While dismissing the rest of us who actually deliver every day.

It is hard for me to want to work on an open source Lisp IDE, when I can pay a relatively small amount of money in return for a professional and well-maintained commercial product. It just doesn't make sense for me. If all of the commercial Lisp vendors vanished one day, then it would become much more important.

I always feel these sorts of posts are misguided. They portray VSCode gaining market share as something other than an marketing investment by Microsoft. Similar vibes go for why Java rose to popularity.

At some level, to build a market, you have to invest in marketing.

You need marketing. Someone has to know your language exists, and is useful, and why it's useful. But to build a lasting language, you need a language that solves real problems better than other alternatives.

Java promised three things, and delivered two and a half. It promised - and delivered - an end to manual memory management. It promised and delivered a huge, thorough, useful library. And it promised and kind of half-delivered "write once, run anywhere". That worked well enough to be at least somewhat useful, and failed enough to be really annoying.

Marketing can get you in the door. To stay there, though, you need something that is actually useful.

I feel you are dodging my assertion. Java promised those, with a stupid large marketing budget that shoved it down the throats of anyone near computers at the time. VSCode probably has more money going into developer reach out than I can imagine. And I can imagine big numbers.

Am I claiming that intrinsic quality is fabricated? Not intentionally. I am claiming that it only goes so far.

There was no "stupid large marketing budget" in 1996, when the only thing available was the JDK, and we had to use emacs/vi/Ultraedit to write our Java programms and rely on makefiles to build the whole thing.

Yet our distributed computing department decided to move right away into Java from C to teach distributed systems, thanks RMI and a coherent toolchain across the platforms we had on the labs. Similarly by 1998 the compiler development classes had moved from C into Java, thanks tooling like SableCC.

By 2000, IBM that used to be a big Smalltalk vendor, and used Smalltalk as foundation for their Visual Age IDEs, moved into Java, and from Visual Age ashes Eclipse was born.

Borland added a Java IDE to their collection, while Symantec not only did the same, they also created their own Java implementation.

Ah, and then there was this fellow called Anders Hejlsberg that left Borland to Microsoft, and joined Visual J++ team.

That is real work, and people paying real money for products.

We didn't need someone shoving it down our throats to appreciate what it brought into the 1996 - 2000 computing landscape.

You are comparing the budget to push Java, the language, with every other editor. My assertion is there wasn't a journalist, college student, or product manager even closely related to computers that wasn't courted with regards to Java being the best language of all time.

You do hint at another angle I left out. Getting Microsoft to pour money into this landscape, in the form of Visual J++, was probably more key than makes sense. It is very much like real estate, in that regard. You want to spend where other people are spending, if you want the best return.

A tangent, yet I think it is in the same domain:

When I see a new movie advertised incessantly, I conclude it must be bad-to-terrible. A good movie, product, language needs little to no marketing.

Depends how much you trust the marketing channel. I recall back in the day, if Penny Arcade promoted something, I probably liked it. (Note, this may still be the case.)

Similar, if a few of the trusted artists and such I have on Twitter recommend something, in willing to buy it near instantly.

Otherwise, the marketing budget is merely correlated with the product budget. And, to a large extent, big budget productions are predictable. In that you can usually easily predict if you will like it.

On a tangential note, Java doesn't even have a decent documentation site these days. The documentation page feels like its from 2002.

In fact its more like non existent.

I'd like to think that's a non starter for some one new starting a project in Java.

Are you talking about the API docs[0]? Or about some official tutorial page for Java the language [1]?

The Java tutorials are seriously out of date (they even mention explicitly that they were written for Java 8, and that they may refer features that are no longer available).

However the Javadoc is well maintained and quite useful, discoverable and thorough in my experience. Certainly one of the best native library docs that I've seen.

[0] https://docs.oracle.com/en/java/javase/12/docs/api/index.htm...

[1] https://docs.oracle.com/javase/tutorial/

I got -2 points for stating the very noticeably obvious. That pretty much sums up just how rusty and old Java has become over the years.

So what is the way to learn Java in 2021? Buy 2 - 3 Paperback books?

These days even Perl has documentation on a site that belongs to 2021. These are some things that you need to do to make your language accessible to people wanting to start new projects.

As of now the only real way to read something about Java on the internet is adhoc answers on StackOverflow.

Not everything successful is due to marketing. VSCode is extremely accessible, performant enough, has a huge ecosystem tuned for a plug'n'play experience and is free, among other graces.

It's just a great text editor for programmer's to get productive fast, both beginners and experts.

I'm torn. I'm not meaning to claim that marketing is the sole requirement for success. That said, when the topic is raising the profile, I see profile as market share. Which... Needs a marketing budget.

If only it wasn't Electron...

It may be an Electron app, but a lot of custom engineering has gone into the core text editing stuff - https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r...

Why do you care? Serious question.

Have you ever compared the system resource demands of emacs and vim or neovim when you add enough plugins or extensions to reach feature parity with VS Code? They get to be just about as demanding on your disk space, ram and idle cpu.

I don't give a shit about Microsoft but VS Code is really good. It's performant, easily customizable and has a healthy extension ecosystem for most popular languages.

Microsoft doesn't exactly have a fantastic rap with developers, especially OSS developers - do you really think it would have become this widely used if it wasn't good?

I feel I can claim the same on emacs. Such that this rings kinda hollow for me. :(

I'll concede the healthy extension ecosystem is possibly a result of the marketing budget ("Developer Outreach" being the preferred euphemism).

I suspect the learning curve is probably a big part of Emacs lack of mainstream success (same with Vim/Neovim).

Pretty much this. When called "developer outreach", it doesn't trigger nearly the backlash as calling it "marketing." But... these are the same things.

The learning curve on all software is stupid hard to pin down. Consider, arduino has been a massive success in the embedded hobby market. Why? Nothing really easy or clever about it. Just cheap and clearly marketed for what it can and intends to do.

I think the Arduino example might be stronger on the “they finally made it easy” than you give it credit.

I had done some electronics and micro-controllers work in college, so I wasn’t starting from zero, but the simplicity of the open an example, click upload, and watch it succeed was pretty magical. I’d tried with only modest progress to do some PIC development (as a hobbyist) a few times in the years in between. Arduino was an undetectable amount of effort to get the examples to work.

That, in turn, enables a bunch of GitHub and YouTube style of collaboration among regular, non-wizards who can hack something to a basically working condition, share it, and have someone be semi-confident that they can do it too.

Professionals sneer at the Arduino IDE (and its inherent removal of gatekeeping), but it’s massively popular because it’s easy. (It’s not because it’s a great IDE for sure; it’s the least pleasant program that I use somewhat regularly.)

They made it easier. Still far far from easy. Especially at the level that is claimed necessary by proponents of popular editors.

That is, my claim was geared to the IDE it ships with. And pointing out how successful it is despite any shortcomings that may have, precisely because of how empowering it is to users. In large, most of that empowerment is heavily invested in through maker fairs, magazines, and YouTube outreach.

And I find it hard to see how the ridiculous level of empowerment in emacs couldn't benefit from the same outreach.

I'm a long-term Emacs user (18.55 is the first version I can recall using); by comparison, I find even VSCode frustratingly limiting (but it's what I've gotten my kids started using).

Emacs is ultra-powerful and configurable, but the default configuration feels entirely foreign to users of modern computers, starting with the keybindings which are enough to turn most people off.

IMO, there's nothing inherently better about Esc Z Z vs C-x C-s C-x C-c. That was the state of "competition" back in 1989. There's something inherently easier to remember about ⌘-s ⌘-q, especially when nearly every app uses that same key sequence (and the analogous C- sequence on Windows).

I don't know who would benefit from orchestrating a massive outreach effort for Emacs (and therefore who'd fund it with time and money). Emacs won't die off, but given the overall balance of forces, it's pretty well destined to be a niche editor I think.

I think there is some accidental goal post shifting. I don't know that anyone cares if emacs gets more profile. The desire was for lisp to get more exposure.

To your point, though, I think I agree. Though, the rise in web based environments calls into question the accuracy of the claim. Notably, key bindings are completely messed up in browsers. And that is where my kids get most of their exposure. That and phones/tablets. Which... Just make me hurt when I try to use them for serious stuff.

Oh, man. I’d ignored/forgotten the nonsense inherent in my experience with browser-based environments, but then I think to my kids readily taking to scratch and how easy the learning curve was for them.

Perhaps the common theme is “the first five minutes matters a ton”, which might apply to Lisp advocacy (albeit at a slightly longer timeline, but still in the first couple hours experience that you can compare to node or React Native’s excellent “unboxing” experience).

What marketing? I use VSCode because it is really really good. Better than anything else I have tried (including Emacs). Emacs feels like it hasn’t evolved for 50+ years. The kind of thing that my grand dad might have appreciated but not something that a modern person would use.

Wow apparently some Emacs lovers don’t like it when somebody points out that Emacs is the Ford T of editors :)

Just don't start criticizing vi next. Then you will be in real trouble!

Don’t worry. I am brave but not stupid ;)

The only marketing I've ever seen for VSCode has been word of mouth

I have never seen an official emacs Youtube Short, whereas Microsoft are making some for VSCode

Lisp enthusiasts don’t get why Lisp isn’t popular. And they keep repeating the same thing over and over again: that somehow it isn’t Lisp that’s the problem but something else. Nope. The problem is Lisp. I have written my own Lisp interpreters just for fun. An it is nice how you can built a language from very little. However it still doesn’t make me want to use Lisp for real projects. The same way I admire Lambda calculus but would never use it for real programming.

I am yet to see a lambda calculus compiler.

Trust me you don’t want to program in pure Lambda Calculus!

Whenever I used Lisp for real projects over past two decades, the development was an order of magnitude faster and powerful. To stay on the positive.

So why isn’t the world full of brilliant software written in Lisp? Surely having a powerful language like that will make developers use it? And even if the non-Lisp enthusiasts don’t “get it” how come the Lisp enthusiasts isn’t blowing the rest of us away with awesome software? Honest question.

It is a good question and one with many nuances. There are large software applications out there written in Lisp and other "fringe" languages that intersect with everyday life but they are hidden away in various corporate infrastructures.

Software trends develop for many reasons, not all of them logical. The time for Lisp being used as a general programming language may have passed, or the right set of circumstances have not yet come together. It is very difficult to predict programming language winners. What seems obvious in retrospect was not clear at all at the moment.

I would like Lisp/Scheme/Racket to blow people away with awesome software. Questions raised about price are quite valid. Forcing people to use Emacs is not a path to greater Lisp adoption. There are those of us who have found career niches using Lisp, but there needs to a better effort both in education and tools.

Resurrecting old Lisp environments and dragging them into the present day probably isn't the best solution. Perhaps the best solution is a VSCode environment coupled with real-world examples. More Todo lists and CRUD editors as examples haven't done a lot of good in driving adoption.

Your questions might make some uncomfortable, but I like that you are asking them!

Thanks for a great answer.

So why are you not using Lisp all the time? Honest question.

And if the answer is “nobody will hire a Lisp programmer” then surely all the Lisp lovers of the world could create a company and crush the competition with awesome software? If Lisp really is as powerful as they claim?

A lot of Lisp lovers have found comfortable and profitable niches to practice their trade and aren't interested in forming companies or consultancies to crush the competition. Some Lisp lovers survived the AI winter of the 80s and have flashbacks of scrambling to port their tools over to Java. Some Lisp lovers are academics and education, not commerce, is where they find meaning.

Your question motivates and challenges me. Some of the emerging and successful no-code platforms could have been written using Lisp. Maybe that is one possibility...

Now thats the kind of thinking the Lisp community needs more of to be more successful. Find real world projects where Lips has an advantage and show the advantage by actually doing it. Or promote stories showing how Lisp has been used for cool projects in the past. I know some satellites were running on Lisp. Making it possible to remote REPL the satellite to fix issues. Now that is cool and shows one of the unique features of Lips that developers actually care about.

Look I wish Lisp was better than the rest. Because having something, anything, better than what I have now would obviously be an improvement. However Lisp clearly empirically isn’t better. It has failed in the only game that counts: the real world of software development.

Reply on news.ycombinator.com