💾 Archived View for soviet.circumlunar.space › rwl › gemlog › 2022-01-03-lisp-internet-communities.g… captured on 2024-06-16 at 12:58:15. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-01-08)
-=-=-=-=-=-=-
If you start to read about Lisp, you'll eventually probably come across "The Lisp Curse":
http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
The alleged "Curse" is that Lisp hackers generally don't seem very interested in forming communities and sharing code. The people who are attracted to using Lisp as a programming language, so the story goes, tend to be "lone wolf" programmers. They would rather reimplement something their own way than cooperate and share. Lisp is such a powerful language that it doesn't necessitate sharing, in contrast to languages like C. Programmers who use lesser languages are /forced/ to share to get anything done; Lispers aren't forced, and so opt not to.
It's an interesting suggestion, though I think focusing on the personality of the mythical Lisp hacker tends to hide some other very real problems.
But it does seem like the Lisp community is more fractured than, say, the Python community. Why is this?
I think an important part of the explanation is that the notion of "community" involved here has shifted a lot since Lisp was standardized, between 1981 and 1994. The Internet as a phenomenon in which vast numbers of people participate, from their own personal devices, has mostly developed post-1994. And the Internet is very much a Unix world. In theory, tools built in any language and running on any operating can communicate with any other on the Internet. In practice, TCP/IP was developed on Unix and then ported elsewhere, and higher level abstractions on the Internet tend to reuse or build on Unix ideas. The way to talk to a server is via a stream of bytes. Almost every Internet protocol works more or less by transferring something that looks like a (Unix) /file/ in a certain format over a network connection. The way to visit a web page is to point a program to an address that looks like a server name plus a Unix file path. And so on. The Internet's conceptual framework comes from, and grew up with, Unix.
This means that the "Internet communities" which we now associate with community-based software development are generally Unix communities in a broad sense. They run on things that primarily deal with files (e.g. version control, patches) and primarily communicate over Internet protocols (mailing lists, git, the Web), with individual developers usually working from their own single-user machines. We take all this tooling for granted these days, so much so that it almost seems to be part of the /definition/ of a software community. But in 1981, and probably still in 1994, that conception of a software community was far from obvious and (I'm guessing) wouldn't have been seen as an ideal one anyway. Back then, it was much less common for individuals to own their own computer, and sharing streams of bytes between computers was a lot harder. A software "community" was more likely to be seen as a group of people who all had access to the same machine, or at least were geographically close enough to each other to share files and ideas in a way that didn't involve the postal system.
The memory requirements for running Lisp probably helped enforce that conception of a community. Lisp required better hardware; better hardware is more expensive; and so it only existed at places like universities and certain companies with DARPA contracts. The natural home of a Lisp community is a shared machine running a Lisp system. The language, as it was standardized, reflects that. It is /dead simple/ in a language like Python to open a file and start reading and writing bytes (especially ASCII). It is not dead simple in Lisp, at least if you come to it having cut your teeth on Python. How do you open a file in Python? Pass a couple of strings to open(). How do you open a file in Lisp? Well, first you need an arcane representation of its path, which you pass to with-open-file along with a bunch of keywords and a form to be evaluated... It's functionally equivalent, but it /feels/ verbose and bolted on by comparison.
By contrast, Lisp makes it /dead simple/ to define and re-define and incrementally refine function definitions, and to work with data structures that are in memory. This is great for interactive development, especially by multiple operators working in front of the same computer. But "function definitions" and in-memory data structures are too abstract to be shared over the Internet, put into today's version control systems, or attached to an email. They first need to be represented as streams of bytes.
So my hypothesis would be: it isn't that Lispers are lone wolves that would rather blaze a trail themselves than contribute to a community. Lispers are just as happy---maybe happier---than other hackers to share code and ideas. But their historical circumstances between 1981 and 1994 meant that the /kind/ of sharing that they do natively and best wasn't well-suited for the Internet and its Unix-y conceptual framework, and then the ANSI standard froze Lisp in time at exactly the moment when Internet-based sharing suddenly became possible for a whole lot more people. It's not that surprising, from this perspective, that the Lisp community atrophied and the communities based around Unix-y languages exploded.
If this hypothesis is right, I see two strategies for breaking the Lisp curse. The first is to accept the Unix way of doing things and integrate with it. The goal here would be to make it easier to work with Lisp code and data /just considered as a stream of bytes/. It is of course possible today to check Lisp code into git, just like any other language. But the things that make Lisp development great, like interactivity, are mostly orthogonal to this Unix perspective and not well integrated with it. Although it's dead simple to redefine a function in a running Lisp, for example, it's not so simple to check the previous definition of a function or class into version control before evaluating and testing out a new one, roll back to the previous definition from version control, or turn the current in-memory definition into a patch you could send to a mailing list. Lisp could do a lot more to better integrate with the Unix tools and concepts that have made Internet-based software communities possible.
The second option is a lot more work, but will appeal more to the ideologically pure: it is to build a set of native tools for Lisp that are better suited for sharing in communities where members all have their own computers and are distant from one another in time and space. The place to start here would be to make the notion of "system" work transparently across machines over the network, instead of forcing all network communications to go explicitly through a stream of bytes interface. Today, it is incredibly easy---just a few keystrokes in Slime---to pull up documentation or source code for any function in the locally running Lisp system. What if it were just as easy for me to search for all the more or less similar versions of that function running out there in other systems on the Internet, pull up /their/ documentation and source code, see a diff against my own version, and install them in my local Lisp? If sharing Lisp code across networked machines was as frictionless and native-feeling as modifying the code in a local Lisp, maybe we would see a lot fewer lone wolves.