Lisp Is the Linux of Languages

From "Why most of us won't be inventing little languages", 2004 [0]

"It's quite possible that languages like Lisp failed to become popular (beyond a small community) partially because they encourage programmers to write domain-specific languages. This has a tendency to fragment the community into groups that have trouble communicating (a "tower of babel" effect)."

[0] http://slesinsky.org/brian/code/little_languages.html

>Although C and C++ are also built like this, Lisp is different: the implementations of Lisp are often much different than each other, and one implementation can offer plenty of different features not seen in another.

The author clearly has not spent much time developing modern C/C++ - the various pragmas, implementation details, and "here be dragons" quirks of undefined behaviour in msvc, gcc, and clang differ _greatly_.

I would argue that C is the Linux of Languages - a behemoth in the industry that every other contender is measured against, one that has large numbers of detractors and advocates, and that runs the majority of modern computing by an unholy trifecta of sheer inertia, the first mover advantage, and at their core, a really powerful tool.

Creating multiple implementations reduces network effects, spreads the already limited resources thin, and can potentially fragment the community and ecosystem.

Linux has the "small pieces loosely coupled thing down" in a way that LISP is no where near at all.

LISP could be this awesome. It has the bones to be flexible. Yes Lisp has a very cute creative re-use & some well tread stdlib.

But *nix/Linux keep evolving & changing & growing & LISP has been stuck forever with vaguely 1970's stdlib, with lurching attempts to become more that only ever semi-materialize. Linux kept levelling up, kept growing it's capabilities & systems, but LISP keeps being defined by it's core, and a robust capable evolving stdlib keeps being an illusory changing aspect.

There has been so much detesting of JS for being fickle & changing, but honestly, there's been a somewhat clear trajectory forward, vectors of growth where things happen & eventually sense is made & it gets adopted. I am not a LISP expert but my distant sense is that LISP continues to be a good bit more of a free for all, continues to have all the power, where "different implementations can focus on different needs of programmers, and can develop these features without affecting other implementations of the language," but there is almost never a real forward vector, nothing ever gets turned into an expected capability. Linux grew. It kept growing. In spite of the protests, it has kept refinining & iterating (systemd, wayland, & slow-but-growing new useful options for the base cli utils), and by compare I see LISP's "different needs" as it's core weakness, alas, it's inability to ever pick good ways forward, rather than it's strength.

Every time I see a yet next inventor designs its own configuration language and foolhardily crosses a rake field of syntax conflicts, design errors, and subtle logic bugs, I recall LISP with its S-expressions. The two last cases were CMake and BitBake.

Being a kind of divergent multiverse base is not bad, provided a common spirit is still shared and abidden between implementations. For LISP, having e.g. Scheme and Guile as a minimal working base, and Common LISP as an "all batteries included", it not that bad even despite their miscompatibility.

> There shouldn’t be a single place where all the development happens.

well, there isn't, for any widely used languages. actually, there probably are many single teams (or single persons) working on niche lisp-likes.

> Programming languages should be built like this. There shouldn’t be a single place where all the development happens. Different implementations can focus on different needs of programmers, and can develop these features without affecting other implementations of the language.

I'm reminded of the XKCD comic of competing standards. This is precisely what has held LISP back. You need standardization, you need a common place for all developers to work from or you can't make forward progress.

> This makes it easy for programmers to switch between different environments without having to learn tons of new skills.

Honestly... if every LISP developer has its own flavor and idea of how the language should work, how should continued development and progress on LISP as a language move forward?