Here is a Loud Announcement: Applied Language announces Applied Language
Or we might just be announcing the server. Oh well. In this announcement, we describe the purpose of Applied Language, and our newly-named design "philosophy".
What is Applied Language?
Applied Language is a collective of people who want to turn computing upside-down some way or another. We're probably only known for software like the Netfarm replicated object system, and a book.
Who is Applied Language?
The members of Applied Language are whoever we say they are, in honesty. Some of our friends who have contributed ideas to our projects may as well be in the cohort, even though, say, they have not written any code. It probably has Gnuxie Lulamoon and Hayley Patton though.
We are more interested in ideas than divining lines that are "us" and "not us" though. It is isn't a secret club; we'll work with anyone and aren't going to hide ideas from the world. Here is one such idea:
Maximalist computing
What is the smallest feature set you can use to implement as much as possible? Then, what do you need to add for users to want to attempt as much as possible?
We are not particuarly interested in keeping the system simple, because that tends to mean making stupid systems to many people. Overspecialising the system, by prescribing a use case to the system, such as presenting documents, or creating a chat application, is also not desirable.
– The Netfarm Book style guide
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. For example, certain aspects of
the Scheme programming language are maximalist: it attempted to subsume
Actors into the lambda calculus, and call/cc can simulate many control
structures (some better than others, and some with resource leaks, but
it can). But Scheme is also considered a minimalist programming
language. On the other hand, the Go programming language minimises too
much, (once) eschewing parametric polymorphism, and (still) exceptions
and discouraging higher-order functions, usually to the dismay of the
programmer, and sometimes to comedic effect.
The "philosophy" of maximalist computing is more of a mockery of reductive-minimalist computing than a serious philosphy; it materialises in quips and puns, not in design books or self-righteous Medium articles. We even found the term by inverting the name of a FOSDEM stream, inventing the "Imperative and maximalist computing" stream. Maybe we will run it some time…
Who would do such a thing?
Maximalism may be a disagreeable notion right now; many software designs are centered around the lie that "there should be only one way to do it", and acknowledging the existence of multiple approaches to a concept is a high sin to some people.1 It can come off as promoting "bloated" designs; but a small idea which has been forced to grow is more likely to accumulate cruft, as compared to an idea that already started large, so we are more likely to throw back accusations of "bloat". Doing everything, of course, is a lot of stuff to do!
Prior art of maximalism is already common in the sciences; attempting to find simple models of aspects of reality, while still being able to explain more complex phenomena, is generally a desirable concept in physics, chemistry and such. Another influence is the work of the Viewpoints Research Initiative, who had attempted to redesign a complete operating system and many "little languages" to implement a complete system with magnitudes fewer lines of code.2 They still managed to carry over the conveniences of large systems, such as graphical authoring tools, without hampering the simplicity of the system. This is in contrast to, say, the current "minimalist" trend of reducing anything to text and blocks of monospaced characters, a technique that Unix has used to rot the brains of many programmers. The VPRI system exhibits maximalism, whereas Unix exhibits assimilation; but, again, they are both minimalist in different ways.
What now?
What we must do in the next few years is to resist forms of minimalism which serve to reduce the ways in which we perform computing; be it with crappy programming languages which impede the creative process, mediums which condense expression to what can be done by a lousy analog device, so on and so forth. We further should expand the use-cases of the opposite; exposing expressive environments and tools to a wider audience, who hopefully won't see why they should be stuck with the same shit. If not, well, we'd at least have some nice things to use ourselves. Then external factors will make them as much of a joke as their projects are.
"We can ask only one thing of the free people of the future: to forgive us that it took so long, and that it was such a hard pull."
Footnotes:
c.f. the followers of the Lisp "Curse", who will not admit that fragmentation is desirable, and any attempt to minimise it is an attempt to minimise programmer freedom. Pages 24-26 of Software and Anarchy go into detail into why the assumption that one approach should suffice is a terrible one; I will refrain from elaborating here.