There seems to be this reactionary rejection of free software itself on the software-aware left because many of its proponents have historically been bigoted pigs and shortsighted people of privilege (if very smart and ethical in one very small area). This is very stupid:

• The examples they provide of why free software "looks like shit and runs like ass" to end-users are cherrypicked and meaningless.
• The alternatives they propose (usually piracy) cannot actually produce anything, and thus are not an actually-workable ideology unto themselves.
• They keep saying that most free software isn't useful to end users, only to "nerds," but making those nerds' lives easier makes the production of ethical software for you easier.
• It is impossible for ethical software to be anything other than free software, because otherwise there is no accountability and no free association.

Many valid criticisms of this essay have been made over the years. 25% of your codebase being macros is terrifying. Language power is not a single dimention, but multiple, and Lisp is extremely powerful, but not the most powerful language. But despite these criticisms, I think the point of the essay does still stand: macros are extremely useful when you need them, that's pretty manifest from the amount of compiler plugins and codegen Java libraries like Jackson do, which is just a worse and more brittle form of macros; language power may have multiple dimensions, but some languages are just still more powerful across the board, or in sum, or on average, than others (think of a spider graph of language power); Lisp is probably one of the most powerful, considering it can even nearly seamlessly encompass Haskell and APL using macros. There are also responses to some of these critiques: for instance, maybe 25% of Viaweb's final generated codebase was the generated content of macros – indicating how much time was saved, not how often they were used strictly speaking – instead of 25% of its pre-compilation codebase being macro definitions, for example.

I'm not a fan of Erik Naggum as a whole – his prideful nigh-abusive holier-than-thou attitude and legendary flames probably significantly contributed to the death of the Common Lisp community in the 2000s to some significant degree. However, this is a classic essay. Naggum covers a lot of points, but among them:

• modern computer systems, both for users and for programmers, are so lacking meaningful automation (macros, an efficient, readable, comprehensible, reliable, and interactive way to compose applications that have to work with something more than plain text (and no, UNIX pipes are not interactive)), so full of drudgery and menial work, that we seem to have forgotten that the point of computers is to automate away tasks, instead of "perform menial tasks by mouse instead of lever."
• Because the bedrock abstractions of *nix and Windows are bad, new leaky abstractions have had to be piled up on top of them to make them do the things we need to them to do, and this has made them extremely unreliable and complex.
• The fast-paced, competitive mindset of the modern tech industry is a distortion in thinking: just because something isn't always changing doesn't mean it's dead.

A fun little historical paper documenting one perspective of how Common Lisp got standardized. I really like the focus on how human factors influenced the direction and completion of the project, not just technical ones.

As someone who's deeply interested in digital privacy and security rights, and deeply opposed to government surveilance and legibility, this was an inspiring book when I read it. It's been many years though and I'm not sure how it holds up. Hopefully well.

Written by the inventor of the concept of hypertext and the creator of Project Xanadu, this is a manifesto for personal computers, specifically personal computers as intelligence augmentation machines and machines for creative, associative thinking and exploration, by an outsider to the world of technology. I'm extremely interested to read it, although it'll be annoying since the only way to get a big enough screen for it to be readable is to read it at my desktop.

This essay is an impassioned, and historically-informed, plea for the return of computer software and hardware that is designed for professionals, or at least people willing to spend the time to learn it – things that are willing to sacrifice some short-term ease of use in favor of efficiency, power, and elegance. For those who are willing to delay gratification and invest the time to learn such tools, the payoff is immense – are skilled people willing to learn and co-evolve with their tools not also worth thinking about, just as much as the average unskilled person? And yet the software industry of today seems to only care about the latter, not the former – and not as a matter of profitability, either – proper professional markets are whales that can be deeply lucrative. There seems to be a moral objection to software tools that are designed squarely targeted at skilled people willing to invest time in them, and that's terribly sad.

This essay introduces an exceedingly useful framework through which to view computing environments that, ever since I've read it, I've used to think about the topic. The basic framework is that there are four different types of computing environment, each at a different level of abstraction and power for using, synthesizing, managing, and processing information, and generally we want to be climbing up the hierarchy. The hierarchy is:

Numeric Systems

systems designed entirely around numerical calculations, in a batch processed mode. Closest to what computing hardware actually does, and the earliest form of computing environment.

Application-Specific Systems

a computing environment that may do other things than numerical calculations, and may be slightly more interactive as well, but is still designed to do one specific task and nothing else.

Application-Centric Systems

computing environments that essentially operate as a framing device for multiple application-specific systems, one at a time or next to each other, but with little fluidity or even direct communication between them. This is the modern desktop operating system paradigm.

Information-Centric Systems

all of the information or content relevent to a task is in one place, displayed at once, with the tools needed to display or manipulate the varying kinds of information embedded into that common interface. Think Emacs, Acme, or Jupyter Notebooks. But the information centric computing environment is usually still relatively task-specific, even if it's a broad notion of task, and sits on top of something else.

Application-Less Systems

a version of an information-centric system where the information for all possible tasks, including operating system manipulation, is in one unified interface, fluidly communicating and combined.

This is the essay that started it all – the one that introduced the concept of hypertext for the first time. Interestingly, its concept of hypertext, which structures documents as a linked list like structure of small sections of content addressed by globally unique identifiers, which could be linked directly to from any other document, or anywhere else inside the document, and which included the concept of transclusion (that is, directly including another document's content into the current document, instead of just linking to it) is both more powerful than our modern notion of hypertext (where anchors and iframes are clunky, manual reinventions of the same ideas), and much more similar to how an org-mode document is structured, at least how I use it!

I haven't actually had a chance to read this essay, only listen to the summary given in the Advent of Computing podcast episode on Project Xanadu, and I'm very intrigued to read more!

A beautiful, funny, bouncy, entertaining, refreshing ode to free access, free information, and against intellectual property, gatekeepers, and all the apparatus that holds it still that capitalistm births, as well as a precient discussion of attention in the cyberspace age.

Richard Stallman the man is… far from perfect (links in order of massively descending severity), but his history as a champion of free software that isn't willing to sell out to corporate interests, and much of the software he created and improved, are very important, so this book seems well worth reading. Hopefully it will paint a complex picture, instead of being a hagiography.

This essay piggy-backs well on the back of Hackers the book, providing an in-depth explanation of the mindset a hacker takes toward their code – that it can be art in the same way painting can be, a thing of beauty and a means of self expression.

Out of all the books I've read, this one has had one of the largest and most lasting impacts, changing how I view my primary career and hobby, and who I want to be. Yes, the hackers were imperfect – sexist, gross, often somewhat myopic – but their ethos as explained by Stephen Levy, their passion, it's so much of what I want to be. And I think stealing and imitating the good of the past, and discarding the bad, is the best thing we can do. This book is also just entertaining and fun to read, and will teach you a lot about computer history, so it's worth it. I'm still obsessed with the MIT AI Lab to this day.

This guide is pretty much as true today as it was when it was written (probably because it has been updated over time), both in its technical guidance and its explication of the hacker ethos as it applies to programming. Since I'm a hacker, and I think welcoming more people into the fold, it's well worth putting here.

This is along, informal, somewhat rambling essay, but as someone who is a software developer as well, and is looking to get into the software industry in order to make enough money to survive, but is wholly opposed to the culture growing like a cancer there among "tech bros," this definitely speaks to my feelings deeply. It's perhaps a better statement of them than I could've made.

This is mostly of historical interest.

Despite being a relatively innocuous personal account, I find myself thinking about this often. The idea that computers should be bicycles for the mind, taken seriously instead of just as a marketing slogan.

A really profound talk with two parts: a philosophical one and a technical one.

I'm not sure I agree with the philosophical point, that choosing one purpose to staunchly follow for the rest of your days, to become a true believer in, is the way to a good life – that seems like a fixed idea, and the route to ego death if the idea turns out to be wrong or you change or the world changes around you – but certainly pursuing things you feel passionate about while you are passionate about them, focusing on that passion and even reinforcing it, making strong decisions based on it (and that can last a lifetime) is a great way to live. It's how I try to.

However, the technical part – demonstrating what a truly interactive software system looks like and why it's valuable, is amazing, and really blends well with the Hackers and Painters ideas.

Xah Lee is wrong about as often as he's right, but when he's right he's right. Languages that focus on meaningful practicality within their domains are better than languages that get preoccupied with their own beauty – better culturally, and more useful.

This is perhaps the most thorough outline in a single place of how modern operating system design, even at the level of things we consider foundational, such as processes, hierarchical filesystems, kernels, monolithic applications, and the distinction between memory and storage, are all arbitrary and suboptimal accidents of history that can be replaced with superior – more flexible, more powerful, and even more secure, through the use of operating system level object capability based security. It then describes the properties that a Lisp OS should have. Useful to read in conjunction with UNIX, Lisp Machines, Emacs, and the Four User Freedoms and my descriptions (one, two) of an ideal operating system, and things like Genera Concepts and Symbolics Technical Summary.

Maximalist computing is designing protocols and platforms which support doing "everything", and in a pleasant manner. It is, in one way, an extension of the idea of computing, which is to simulate anything; there are many situations in which universal simulation can enhance a platform.

It is not necessarily opposed to minimalism, but it is certainly at odds with kinds of reductive minimalism; that which simplifies protocols by forcing the simplification of use-cases.

A very interesting oral history from RMS, about exactly what it says. Has a somewhat distorted view of the reasons things happened but as a look at what RMS thinks happened, and thus what motivated Emacs and GNU, it's great.

Forget all the tedious arguments about whether Lisp macros are maintainable compared to languages that are more limited in their ability to program themselves. The entire point of computers is to automate the manipulation of information. If we're not using computers to do that as much and as efficiently as possible, so that our minds are free to do the most interesting parts of that, we're simply using computers wrong.

A concise, cogent list of the principles that any personal computing environment should obey. I deeply agree with these principles, but perhaps they should be viewed as ideals to strive for, not as total prerequisites, for acheivability reasons.

Laws:

• Obeys the operator
• Forgives mistakes
• Retains knowledge
• Preserves meaning
• Survives disruption
• Reveals purpose
• Serves loyally

An extremely funny, entertaining, well-argued, and interesting talk with a ton of historical and contemporary references that are really worth exploring – you could spend days just investigating all the links it makes – that talks about just how limited, clunky, out-dated, and counterproductive the way we program is, how we've somehow discarded all the amazing ideas and advancements that were made historically away from the batch-processed model of computing and just kept going with it, long past its sell-by date. But it doesn't just complain about our path-dependency: it gives rich historical and modern examples of alternative ways of doing programming. This is extremely influential on my notions of how programming should be done ideally, next to Inventing on Principle.

A rare, curated, one-of-a-kind collection of information and resources about the utlimate Lisp Machine OS, Symbolics Genera. The lost Atlantis of operating systems! Some good places to start with this are:

Taste, bought through experience and care for your craft, is important for programming – the massive amount of complexity, unknown unknowns, and the need to interface with the complex, fuzzy, and shifting world make absolute, rote methods impossible, and taste can be a good guiding heuristic the help us get to where we need to go, like in physics and mathematics. However, what does good taste mean? This essay has excellent guidance for us, pulled from the worlds of art, mathematics, engineering, and programming itself:

• Good design is simple
• Good design is timeless
• Good design is suggestive
• Good design is often slightly funny
• Good design is hard
• Good design looks easy
• Good design is redesign
• Good design is often strange
• Good design is often daring

A great takedown of the tendency of many hackers to frame themselves as "apolitical" in Xah Lee's usual inflammatory and sketchy style.

• Self-consciously rigid, minimalist software and software protocols tend to force more complexity into things around them – for instance, more complexity is needed to implement them to get around their limitations.
• Such software is often not responseive to human needs such as:
  • self-expression
  • accessibility
• As a result, what we need is minimal but extremely flexible software that can be built into something non-minimal. Like Smalltalk systems.

In this essay RPG compares the act of writing to the act of programming – how both are a dual process of discovery and refinement, deeply intertwined, as discovery must be refined, but the refinement of what has been discovered prompts new discoveries and insights that start the whole process over again. How systems are shaped not just by up front design and requirements (external) but also by internal forces, tensions, "triggers" of new ideas, possibilities, or problems. He makes the argument that programming languages, which are oriented around static thinking enforcing up-front specification of everything, rigid consistency requirements, and making code difficult to change dynamically, aren't suited to such an intertwined task of iterative discovery and refinement. At best, they're suited to a final version of a program, not a first version. See also, my arguments against formal methods and overly strong static type systems, Notes on Postmodern Programming, Hackers and Painters, and some other things I'm probably forgetting.

A sympathetic, but critical, portrait of a certain type of anti-social, cynical, intelligent, yet often distracted and unable to complete things, individual, which is often attracted to Lisp, because of its ability to allow single isolated individuals to be extremely productive by themselves, and its ability to be molded into the shape of the mind of the person using it, instead of them having to compromise and bend their mind to it.

I reread this essay often because I strongly see myself in it – even in the ultimate fate it describes, and I have complex feelings about that. I like who I am. My anti-social nature, my individualism, my ambitious but never-finished projects. I don't even mind that I may not ever work in the software industry – for someone who loves hacking as much as I do, perhaps that's for the best. But it's useful to remember that this isn't the most productive outcome either. Something like the Cult of Done manifesto may help me to at least finish more things.

As a general critique of the Lisp community, the thing is that this sort of issue can – as I intend to do – be corrected for, and modern Common Lispers actually seem very good about trying to work together and build useful libraries for others and so on.

Eric S. Raymond's essays before his Hoppean turn are quite excellent in many ways. Erudite, playful, widely-read, and unusual examinations of hacker and open source culture often laced with references to anarchist ideas and works and immersed in that lens. The bazaar, like Mob Software, is a utopian vision, but I think one worth aspiring to.

If you are a creater or a maker and your craft is your lifeblood, but you struggle to actually do it just the same, this is an excellent manifesto to keep in mind at all times to keep in your heart at all times.

"A cyberspace well of files, related to those aspects of being, formed by (post)modern life and culture."

An absolute fucking beautiful treasure trove of carefully curated, found, and organized texts from the era of the 2000s cyberpunk culture and the things that influenced it. Much of this is impossible to find anywhere but the place this is a mirror of, which is why I'm carefully and lovingly trying to keep a copy safe.

The Cyberpunk Project hosts a few texts that have been extremely influential on me:

This is the closest thing you'll find to an ethnography of the hacker culture and community as a whole, as well as a treasure trove dictionary of funny terms with curious historical baggage. I want to incorporate more of these terms into my language.

A short, punchy, and funny, but nevertheless somewhat insightful takedown of the UNIX Philosophy. Again, from Xah Lee, so take witha massive grain of salt.

Short, punchy, clear, envigorating, a call to action – all that a manifesto should be. And it very much aligns with my own commitment to repair being for individualist reasons.

A short essay explaining a form of organizing that is beyond mere decentralization, that is completely individual and distributed, yet still coordinates to get things done – the ultimate holy grail for individualist anachists. Talks about examples in nature, and in our society (has some overlap with The Cathedral and the Bazaar, but from the other side of the glass so to speak).

Not only is this an incredibly well-written, lyrical, and erudite paper written about a fascinating transition point in the history of programming, but it articulates a fundamental rift between how modern programming language theory (and computer science in general) views programming languages and tools, and how actual working programmers and system builders view them, a rift which I think articulates well the utter dissapointing lack I see in computer science as a whole.

A hilariously funny book with many accurate and trenchant criticisms of UNIX that still hold true today, and many silly, off the mark, or outdated ones, all presented in a hypertext form that's so strange it reaches performance art.

For all of their faults, Richard Stallman and the Free Software foundation fight for a cause that I believe is deeply just. Free (libre) software is the only software that can truly adhere to the essence and spirit of the core tenets of the programmer code of ethics that I believe in.

The core of free software is contained in the famous four freedoms:

• The freedom to run the program as you wish, for any purpose (freedom 0).
• The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
• The freedom to redistribute copies so you can help others (freedom 2).
• The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

As to their faults: while I applaud RMS for his technical abilities and staunch, unwavering support of his ideals, he has many other ideas (and behaviors) that are outright gross and unethical, and many others that just make him a bad spokesperson and figurehead for a movement. His conception of freedom is also somewhat compromised, in that he seems to think that restricting the freedom of users to use proprietary software or hardware, should they choose to do so, by making it more inconvenient, is somehow protecting their freedom – when in reality, freedom includes the freedom to fuck up or do suboptimal things if you have to, and taking such a hardline stance just makes operating systems that take free software principles harder (or impossible) to access and use for many people. He also has weird and arbitrary lines, such as thinking shoving proprietary code into firmware on secondary chips is better than it being at least a blob you can swap out attached to your main operating system. He also has paranoid ideas about the consequences of doing certain things, like opening up GCC so it can be used as a language server risking "companies building proprietary front ends to it," which they wouldn't do – they'd just use clang.

Likewise, at this point, the FSF is an impotent personality cult that cannot meaningfully reach out and address most people where they're at, and doesn't even use its funding to fund development of things like the GNU project, just largely ineffective activism. They also have a tendency to be extremely myopic and "apolitical" in a way that just further excludes diverse people.

But nevertheless, their ideals are good.

Many people over many decades have speculated as to what's "wrong" with Lisp, such that it hasn't reached widespread industry adoption despite its many technical merits. Most of them are superficial, ahistorical, and anti-intellectual. This article explains concisely why: that Lisp, being very different from the mainstream (but, to add my own component to the analysis, in a way that is not governed by a modernist narrative like languages such as Haskell), attracts people who want to justify their desire not to have to bother to learn it, who come up with post-hoc justifications for that framed as criticisms of the language, to shift the blame. This creates a mythology of Lisp being bad that scares people away. This, combined with TBLP phenomenon, seems accurate to me.

I hate Yarvin and everything he stands for. However, I agree with the thesis of this essay, and think this is probably one of the best statements of that thesis I've seen. Plus it's well-written and funny as hell.

His thesis is essentially that CS research spends all its time on naval gazing about type systems, mathematical formalisms, abstract algorithms, and non-interactive batch programs like compilers, as opposed to interesting and creative programming, analyzing things like programming languages as complete systems including what they're like to use, doing empirical work with programmers, etc, because mathematical formalism is an easy way to generate infinite work that looks "hard" in a way interesting creative programming doesn't. Essentially, similar critiques to Richard P. Gabriel's paper and part of the feminism in PLT paper.

It does, however, have very serious problems as an argument for the thesis, which are indicitive I believe of the wider problems with Yarvin's reasoning in his other work. In this sense, the primary interest of this article was that it was a very interesting test-case for understanding this "philosopher" who is now the power behind the throne, in some ways, in the US: the article is about a field I know some amount about, so I wasn't likely to suffer from Gell-Mann amnesia and just believe him, but on the other hand, he's arguing for a thesis I actually agree with, so I'm not likely to apply overmuch scrutiny or dismiss what he's saying out of hand, as I might be accused of doing for his more outright evil theses.

What I learned is that, tldr, he's a very good writer, and very good at researching and marshalling many erudite minutiae to his aims, but that does not a good argument make – it just makes him seem very smart.

The general problems I saw with this essay qua argument were:

• Circular reasoning to ensure there is no nuance in his analysis (the Guy Steele thing).
• Totally unevidenced and kind of weird typologies used to structure his whole point.
• A ton of very erudite and detailed and obscure examples but not high level data to draw general conclusions with.
• Very strained shift to a foregone conclusion (acadamia bad) that isn't justified by his criticisms (all organizations could fall into these problems, not just public ones, and many of the best think tanks doing amazing creative programming were in acadamia, such as the MIT AI Lab).
• Very funny, very well-written, very well-spoken, but as shown by the previous points, not really with that much underneath.

Looking at the problem discussed in The Bipolar Lisp Programmer from another angle: that the individualism, and invidual productivity, of Lisp is good, and it is the incentives of corporations, who want programmers who are individually easier to replace or do without, and individually less productive and influential, so less risk is invested into them, they're cheaper, and easier to keep in line with the proper workings of the system, that makes the sort of people Lisp enables unable to find jobs.

The UNIX philosophy has reached the level of a religion in open source circles, so that when violations of it occur, they are viewed as sins to be eradicated, not as having real technical reasons. This article outlines one of those solid technical reasons.

A very good explanation of why we can't just layer shoddy half-implementations of better things on top of old bullshit and expect to eventually reach what we could have reached had we started with better foundations. A direct response to 'Worse is Better' and the idea that "the good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++."

A bedrock abstraction is an abstraction past which no recoverable error can happen – when a system breaks, it will always break down into whatever component parts are its bedrock abstraction, so they can be reassembled, and if it breaks past that, it just needs to be replaced wholesale.

The key idea of this blog post is that the bedrock abstractions we've chosen for modern-day computers, thanks to what's convenient to design and manufacture, and the fact that they're descendant from the systemically underpowered and designed-to-be-cheap original microcomputers, is insufficiently powerful, because it means that when software systems break or need to be modified, you're often dumped down to a level that's just too low to be useful to a human being – we need to raise the level of our bedrock abstractions to a point where we don't need to be afraid of them anymore.