[iLemming]

> object oriented programming languages are so successful for systems that have to be maintained for ages,

ehmmm.... excuse me.... erghmm... what about Emacs? I'm sure, it absolutely can be count for a "successful system that have to be maintained for ages". For far, far longer than any Java-based project that ever existed.

Even though Elisp lacks:

- static typing

- OOP class system (until relatively recently)

- Modern package management (until ELPA/MELPA)

- Multi-threading model

- JIT compilation

Perhaps "the secret sauce" of successful software is in simplicity? Maybe some programmers just get it, and for others, it is such an obscure and mysterious entity. Some programmers write "programs to program computers", and some may have realized that they are not trying to solve purely technological problems, but they are, in fact, tackling socio-technological problems, and they write programs to communicate their ideas to fellow human beings, not machines.

[IceDane]

I've been using emacs for over 10 years. Maybe close to 15. I can't get rid of it, because even for all its faults, I love it. I'm hopelessly stuck with it.

However, emacs is a fucking mess, and there is a reason "init.el bankruptcy" is a thing and why the most popular way to use emacs is through various frameworks such as doom or spacemacs.

In emacs, nearly everything can(and often does) mess with everything else. It is serious integration hell to actually get things to work together, and the work that goes into e.g. doom is basically all about managing that complexity through good abstractions and more rigid ways to configure and install things.

Emacs is also objectively dogshit in a lot of ways compared to most modern editors. LSP is ridiculously slow and a constant source of performance issues, many of which are probably directly related to emacs internals. Eglot seems to do better but it's a lot more limited(you can't use multiple language servers together, for example). Then there's things like the buffer being the data-structure for everything, which is sort of like modeling nearly everything as one long string. Things that would be trivial to do in most other languages or contexts are difficult and error-prone in emacs.

[iLemming]

> Emacs is also objectively dogshit in a lot of ways compared to most modern editors

Yet not a single modern editor can even come close to it when it comes to extensibility and customization; self-documenting; complete programmability; malleability; ability to perform virtually any computing task without leaving the editor. Modern editors excel at being user-friendly out of the box. Emacs excels at becoming exactly what each user needs it to be. While you find yours to be "objectively dogshit" in comparison, I can probably easily demonstrate to you how mine eats their "modern" shit without even chocking.

> LSP is ridiculously slow

Have you tried to get to the bottom of it? Sometimes it just the lsp-server implementation that is slow. Have you tried https://github.com/blahgeek/emacs-lsp-booster? Did you build Emacs --with-native-comp flag? Have you tried using plists for deserialization https://emacs-lsp.github.io/lsp-mode/page/performance/#use-p...? Have you used Emacs' built-in profiler? Sometimes the issue might be somewhere else, e.g., some fancy modeline settings.

> Things that would be trivial to do in most other languages or contexts

Sure, that's why we see so many "Emacs killers" built in Java, because replicating Org-mode is so trivial in it. /s

[IceDane]

Yes, I've wasted a considerable amount of time trying to get to the bottom of the performance problems. So have multiple other avid emacs users I know that regularly have to deal with these problems. One of them is trying to live with eglot because it feels a lot faster - now they are also trying to use a sidecar process multiplexer to support multiple language servers. This is like the emacs experience in a nutshell.

My conclusion is basically: some language servers are slow, which doesn't help, and some are also very noisy. Both scenarios are handled extremely poorly by emacs, i.e. locked ui when parsing or waiting sometimes, stuff like that.

You really have to be a special kind of oblivious to argue so vehemently while literally suggesting I run a separate program on the side to get what most would consider to be a basic, functioning editing environment.

Re the org-mode argument: I really think you mistake lack of interest for insurmountable complexity. Emacs is not a magic machine that can do things no other software can do. You can probably count the number of people who genuinely care about org-mode in the world on 10 sets of hands.

[iLemming]

> I've wasted a considerable amount of time

Okay, I'm just trying to help. I, for one, don't experience extremely vexing problems with performance like you're describing. But of course, I'm not going to pretend that I'm unaware that Emacs needs to improve on that front, and over the years there have been numerous improvements, so it's not a completely hopeless situation.

> basic, functioning editing environment

Different priorities. For me, "basic, functioning editing environment" means stuff like indirect buffers - which not a single other modern, popular editor offers.

> Emacs is not a magic machine that can do things no other software can do.

In some cases, it literally feels exactly like that. So while not literally magical, Emacs enables workflows and capabilities that can feel transformative and, yes, almost magical to its users. The "magic" comes from its architecture and philosophy. I can easily list dozens of use cases I've adopted in my workflow that are simply impractical to even try to replicate in other editors.

One can criticize pretty much any software product. Yet Emacs still falls in the category of "successful systems that have been maintained for ages". Anyway, we're getting sidetracked. My main point in the comment wasn't about Emacs, the main point is in the last paragraph. Maybe you just didn't even get to it.

[brabel]

It's embarassing to have to even say this , but a counterexample, or even a few, does not invalidate the argument. You would need some sort of representative sample of successful projects, and then figure out which paradigm was used for each one and see if there's any statistically significant pattern. Good luck doing that reliably though.

[iLemming]

While focusing on the first part of my comment it seems you completely ignored the [main] point in the last paragraph.

All programming languages are man-made, human constructs and not a single one is the most ideal for the task of programming - just like not a single spoken language can claim absolute superiority for communication. The nature of programming often eludes clear categorization, challenging us to define whether it belongs to the domains of art, business, or engineering. Maybe it's all of these? Maybe it's none of it? We, programmers endlessly engage in passionate debates about language superiority, constructing complex arguments to defend our preferences. I'm not a musician, but can you imagine guitar players vehemently arguing with drummers that guitars are ultimately better instruments because, I dunno, one never can perform Für Elise using drums. And then some experienced drummer comes and performs it in way no one ever imagined. I think, the beauty of programming, like music, lies in its diversity. Instead of engaging in futile debates about superiority, we should celebrate how different languages and paradigms enrich our craft, each bringing its own unique perspective and elegance to the art of problem-solving.

One of the things I feel grateful for after learning Clojure is that many, perhaps most people in the community are genuinely experienced, seasoned software developers, driven to Clojure by curiosity after many years spent in other programming languages. Clojure allowed me to fall in love with my trade once again. The combined malleability of Lisp that can emulate (almost) any known programming paradigm and the simplicity and data-centric design in Clojure helped me (truly) understand the core principles of programming. Ironically, after using numerous different languages for many years, spending years of grokking their syntactic features and idiosyncrasies, many stackoverflow threads and tutorials later, only after switching to Clojure did I feel like I understood those languages better. One peculiar aspect about Clojurians, that they don't typically engage in general debates about programming languages without specific context, subtly breaking the famous Perlis quote about Lispers knowing the value of everything and cost of nothing. Clojurians known for their grounded perspective and non-dogmatic approach to problem-solving. So, they typically don't bash on someone else's favorite language, instead they'd try to learn and steal some good ideas from it.