emacs and software monoliths

Software monoliths are sort of an older way of building software, and making things small and single purpose has been ~~Linux wisdom~~ the [Unix Philosophy](https://en.wikipedia.org/wiki/Unix_philosophy) that is usually right. Emacs is the biggest threat to hypocrisy here, since it can itself be considered a huge monolith that does everything. Aside from that, however, there are other remarkable monoliths (giant pieces of software with huge code-bases and broad functionality) in the emacs ecosystem, some of which are so big and established and useful that they are hard to replace. What are some of your favorites, and what do they do that is hard to replace for you? Here are some of mine: * Org-mode. It's breadth is actually part of its value-proposition with literate programming in many languages, publication to a plethora of outputs, and rich note-taking (code notebook-style) to an extent unreached by any other tool of which I'm aware. Plus it's really good for actually taking tech/class notes. * Gnus. Letting me easily\* do email across many addresses in emacs, and integrating well with the related monolith... * BBDB. It has great support for all manner of contacts and, apparently, all sorts of exports, with prevalent and rich interfaces. * Helm. Really a swiss-army knife of completion, but there have been a plethora of lighter more specific altervatives in the past few years. Nonetheless, my students loved the ease and "do it all" made possible by Helm.

>Emacs is the biggest threat to hypocrisy here, since it can itself be considered a huge monolith that does everything That's like accusing the shell to be humongous, because people have written elaborate shell scripts of hundreds of screenfuls of code and considering most of /usr/bin to be part of the shell :D I know it's supposed to be a joke when people call emacs a nice operating system with a mediocre editor, but there is some truth to it.

Yeah. I'm just covering my bases, because I rejoice in using emacs for everything -- but BESIDES emacs, what are emacs monoliths... etc?

I think, most emacs packages are doing more or less one thing.. It's only that the things nowadays have become tremendously complex :D Try creating a web page that looks slightly nicer than the bland HTTP 500 pages and you could spend days doing that.. And that monstrosity of HTML+CSS has replaced text-based emails nowadays :D But enough of me ranting, back to the studio :D

I have to complain about your introductory words. > Software monoliths are sort of an older way of building software, That is [another design philosophy](https://en.wikipedia.org/wiki/Worse_is_better) have you ever heard of ["worse is better"](https://www.dreamsongs.com/WorseIsBetter.html)? > and making things small and single purpose has been the "Linux" wisdom that is usually right. Do you mean "Unix philosophy" instead of "Linux wisdom"? Because the Linux kernel is regarded a [monolithic kernel](https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate). > Emacs is the biggest threat to hypocrisy here, since it can itself be considered a huge monolith that does everything. Emacs is a Elisp interpreter/environment (but with a global namespace), compareable to something like Python. What is your definition of monolithic software? Would [Orgzly](http://www.orgzly.com/] be monolithic software because it sort of reimplements org-mode features? Why, and if not why not? What about Emacs dependency on Unix tools? like `fzf`, or `ls` for `dired`s listings, or all this `LSP` stuff, or ispell/aspell for spellchecking?

Thank you for the comments with links! You are right -- I said Linux Philosophy when actually meaning Unix philosophy (https://en.wikipedia.org/wiki/Unix_philosophy). I think a useful distinction of monolithic vs non- is whether there are boundaries maintained on the design/function space. I was inspired by this comment on a library, "[competing library] is doing too much" https://github.com/AmaiKinono/puni/issues/17#issuecomment-1022242805 I was not aware of the Torvalds-Tanenbaum debate; I need to read up on whether Linus' argument actually won or whether Linux out-paced Minix for other reasons. I also look forward to reading Less is More. I haven't followed orgzly so I only have first impressions, but if it is trying to clone orgmode into the mobile space, I suppose it would have to qualify as monolithic (that is, without strong boundaries on design goals).

>Software monoliths are sort of an older way of building software, and making things small and single purpose has been the "Linux" wisdom that is usually right. I mean...none of that is really true. Ok, monolithic software may be *slightly* older than modular, but both have been around since the 1960s! The modular design of *Unix* (this has nothing to do with Linux, which merely inherited Unix's design) did provide *some* advantages over older OSes, but also some *disadvantages!* Also, Unix's success had more to do with portability than modularity. Until Unix came along, OSes were normally written in assembler, for performance and flexibility. Unix proved that a low-level close-to-the-hardware portable language (C) could provide the necessary performance, and vendors found it *much* easier to recompile Unix for new hardware than to bring up a whole new OS from scratch. In fact, Linux *itself* (the kernel) is generally considered an example of *monolithic* design, and was widely criticized as such back in the nineties! But all of its more modular competitors (Plan9, Minix, Hurd) failed for various reasons. Turns out that modular systems tend to be both slower and more fragile than monolithic ones! Modular is great in theory, but in practice, it's much less so! Now Emacs! Emacs is one of the first examples of what is now, really, the dominant approach: *programmable* apps! Turns out that bolting a general-purpose programming language to the side of your system provides the flexibility of modularity *without* most of the disadvantages! Much of the world's most popular software now works this way: MS Office has Basic, browsers have JS, etc., etc. And Emacs led the way! :)

You are right that it's difficult to build good stuff without dependencies these days, but there is certainly an order of difference between something like Helm (https://emacs-helm.github.io/helm/) and something like Vertico (https://github.com/minad/vertico). I'm with you on the text email matter.

And still, both of them plug neatly into emacs.. For quite a few things, there is a choice of packages to use.. I'm just a user, I can't really tell if it's just good API design on emacs' side or if the package programmers do such a great job to find the right places to hook into emacs, because more often than not, things just work without explicitly calling a package's functions(again: a nice example are the different mail agents in emacs that just work.. but another one are the various completion frameworks). In any case, they don't make things feel too monolithic, but rather flexible..

None of these, including emacs, are "software monoliths".

You fool! You think the Emacs is a Text Editor. It’s not. It’s not he final result of the long waited, ever delayed GNU Operating System. Yes! You all have been tricked by Stallman! It has _always on plain sight_! 😂

GNU Hyperbole is certainly a large package but it is specifically designed to have minimal dependencies on anything outside of base Emacs. It installs and activates with single commands and then gives you automatic recognition of 'link-like' things in all sorts of Emacs modes, ability to create hyperlinks easily across all major modes, a hierarchical record and contact manager, the only fully, hierarchical auto-numbered outliner for Emacs, easy selection of completions and the output of 'ls' commands, as well as advanced control and scripting of your windows and frame layouts using Hyperbole's {key series}, arbitrary sequences of keystrokes (in-buffer keyboard macros). You can learn one piece at a time but you don't have to keep discovering and adding these single use packages; instead get all of this integrated into a uniform design and easily accessible from keyboard-driven minibuffer menus. And of course it's highly compatible and complementary to Org mode.

Emacs does one thing, and does it well: emacs is a lisp interpreter.

> the Unix Philosophy that is usually right I wouldn't be so sure > Emacs is the biggest threat to hypocrisy here, since it can itself be considered a huge monolith that does everything. Emacs is not a monolith, `bash` is.

Emacs is [malleable software](https://malleable.systems/blog/2020/04/01/the-most-successful-malleable-system-in-history/). I will quote [a comment](https://irreal.org/blog/?p=8790) from a post: > Emacs succeeds because of the minimalism of Lisp. The syntax. The flat namespace. The GPL. The mindset these precipitate. It's like chess.

Excellent thoughts!

_Not again_. Even the Unix creators think Unix is a lost cause. If that is what they thought back in the 1980s or somesuch, the current ecosystem is certainly not upto their standards. TL;DR there's little to no value in discussing this topic.

Agree. “Everything is a file” is kind of a lie and has been a long time. Plan 9 gets us closer to that but it’s hard to see it balancing simplicity with often needed performance. If everything was truly a file we wouldn’t need so many syscalls. The interface to the kernel is huge. So it seems monoliths have won.

I felt like I was being lied to when I learnt that I needed to use socat instead of the regular Unix tools to speak with a socket. Plan 9 is the logical conclusion of "everything is a file" which is pragmatic and works very well when you consider the rest of the system. Though, as you say, performance can be a question.

You can’t “win” design arguments. Linux was right and Tanenbaum was right. Same with monolithic software. It’s neither old nor new, it’s just a design parameter where one time you do one thing, the other time another.

Minix hardly “failed” (if intel stashes it in their ME firmware, hardly a failure), and afaik MacOS is still based on Mach. And microkernels aren’t necessarily slower, a lot of the systems you mention were academic research projects rather than attempts to corner the market - these systems hardly ever break through themselves, they rather inspire next generations. They are widely in use in embedded/proprietary systems though.

>Software monoliths are sort of an older way of building software, and making things small and single purpose has been Linux wisdom the Unix Philosophy that is usually right. Emacs is the biggest threat to hypocrisy here, since it can itself be considered a huge monolith that does everything. No. It always irks me a bit when people say this. I've been working on a series of articles for the past 3 months explaining why this is wrong. I finally just published it. Emacs is not an "editor that does everything," it is a Lisp interpreter, and an app platform where apps are programmed in Lisp. More importantly, Lisp is a functional programming (FP) language, UNIX shell programming is not FP, even if you considering using shell pipes a form of function composition. You can read the full article here: [Emacs fulfills the UNIX Philosophy](https://tilde.town/~ramin_hal9001/articles/emacs-fulfills-the-unix-philosophy.html) ([Here is the Reddit thread](https://www.reddit.com/r/emacs/comments/wo6uwa/unpopular_opinion_actually_emacs_does_fulfill_the/) on this article.)

Well, that does it. I need to learn Hyperbole!

Where does Plan 9 exist? Is it a distro?

I should clarify monolith by design vs monolith by praxis. Excellent points here: emacs itself is certainly not monolithic, but extensible. However, making it into a do-everything patchwork is so seductive as the be almost idiomatic. MY setup of emacs (including EXWM) has certainly became monolithic, with a vast network of dependencies, for better and worse. I appreciate the discussion happening here considering where that is a good thing and where foolish.

Thanks! Thought on your comment, though: with the exception of Clojure, what Lisp is predominantly functional? Certainly not elisp, or Common Lisp, and maybe not scheme, right?

>what Lisp is predominantly functional Oh boy, this means I have to define what "functional programming" means, doesn't it? This is such a difficult question. My short answer is: 1. functions are first-class values, 2. you have the ability to define higher-order functions (like function composition, or monadic bind), and 3. the language somehow makes it easy to use higher-order functions to construct programs. So Python and JavaScript do not satisfy the last requirement -- you can define higher-order functions, but the language syntax does not make it easy to use higher-order functions, and you can end up writing very slow, inefficient code when trying to use higher-order functions. This is not "functional." I would argue that Scheme and Common Lisp do satisfy my definition of "functional," and Clojure too, like you said. I think Haskell has set a new standard for "functional programming" in the minds of many, so people tend to expect immutable data structures, tail recursion, and strict separation of effectful and pure code, as features of "functional programming" as well. But these are not *necessary* features of functional programming, just *desirable* features.

http://fqa.9front.org/fqa0.html#0.2.2

Okay. I can see that if we take immutability and purity out of the definition, Lisps can definitely foot the bill.

Wow! Much hate!

[deleted]

If specific metrics can be devised, "win" can be had in terms of maintainability, effect, quantity or resilience of bugs (eg, do they bring the whole system down?), etc. I guess one thing in favor of the modular approach is that it is inherently more amenable to metrics.

I think you’re mixing up monolithic construction and modularity here.

I probably am. Can you have monolithic software that is also modular? I thought that was a contradiction of terms

Modularity (of code) is how your source code is organized, and pretty much everything since 1975 or so has been written in that fashion. Separate modules with reasonably clean interfaces between them so you can be sure that changes can be localized, etc. A monolith says something about how things are _deployed_, namely in one (large) executable that take care of all the functions needed to execute whatever the software is supposed to be doing. Even though it is a single executable (I use the word broadly here by the way), the source code that created the executable (or the source code that comprises the executable, in the case of "scripting" languages like Python or Ruby) is normally organized in a modular fashion. They're actually pretty orthogonal. You can have many modules across many source code repositories form a single monolithic deployment, or you can have "monolithic" code in a single repository create a lot of microservices.