Hacker News new | ask | show | jobs
by coldtea 4012 days ago
Do people believe that having access to packages and add-ons makes an editor (or whatever else) "bloated and slow"?

First, whatever you don't use, it's not even loaded in memory.

Second, bloated is all about having tons of options you don't need or use. Not about adding stuff you DO need piecemeal.

Third, bloat is mostly a UI thing, not a "number of add-ons" or "too many lines of code" thing. Programs don't get slow because they are "bloated" with extra code (if it doesn't run, then it has 0 effect on their speed). They get slow because they are badly programmed (e.g. loading one big text file all at once in memory instead of having a paging system).

The availability of tens of thousands of packages hasn't made Emacs "bloated", much less Vim or ST. Or even installing those packages doesn't make those editors feel bloated.

Whereas something like Eclipse was bloated from the start -- because it was a very heavy design with tons of abstractions layers, ton of built-in options and visual clutter etc, created on a GCed language with frequent stops on larger codebases etc. That's even without any third party plugin added, just the Eclipse Java SE core packages.

4 comments

"Do people believe that having access to packages and add-ons makes an editor (or whatever else) "bloated and slow"?"

... no? Hate to dismiss your entire message that way (I mean that seriously), but...

People appear to be assuming a great deal more universality than I could possibly have implied, since I don't believe it's a universal problem anyhow, and never addressed scope. It's just a cycle that definitely exists in some domains.

It's gotten to when I see something described as "minimal" I tend to just roll my eyes and move on. Especially when combined with accusations, veiled or otherwise, that something else is "bloated", which at this point I tend to just assume is a meaningless feeling word with no real technical content. Yes, that includes when used in the context of "cycle of bloat"; this is a cycle endlessly recurring, yet has very little technical content. Mature text editors are, to a first approximation, all the same. (Yeah, there's some differences, but, meh.)

Well I hate to also semi-dismiss your message, BUT when certain add-ons are essential to using a tool like Atom it makes it slow and bloated.

For example I use vim, and when I tried Atom I threw on two Haskel add-ons and my system was unusable. Then I removed the add ons and my 7 year old desktop on OpenSUSE just lagged away. I than went to my other old desktop all in one and that lagged away just at typing (This was a month ago) and adding anything to Atom slowed down so much that typing was lagging let alone any feature.

The parent did not say that plugins caused bloat, instead that resolving common problems with plugins (stability, quality, conflicts etc.) by pulling them into core is what causes bloat (slowness, complexity etc.) and that trying to resolve the tension between flaky plug-in based systems and bloated monolithic systems is cyclical.
Still: is anyone complaining of Emacs or Vim or ST3 being slow/complex because they have installed plugins to the core?

What's an example in the wild of this "cycle of bloat" in which people complain about it?

> Still: is anyone complaining of Emacs or Vim or ST3 being slow/complex because they have installed plugins to the core?

Emacs? Yes. Absolutely. Emacs once stood, humorously, for “Eight Megabytes And Constantly Swapping”. That is a valid complaint that people have made.

That comment would make sense in the 1990s when we had 32 MB of ram, but you probably haven't used it since then. I type `e` and I'm instantly in an emacs client frame running on top a server and using a modern package manager that loads plugins and different modes in on the fly. I restart and kill the entire server after editing my init.el file and it takes takes a few seconds. Emacs itself takes up so little of a memory footprint I don't even care about it. And do you seriously think that a text editor that is older than most people on HN would be wasteful about allocating resources?
> Emacs itself takes up so little of a memory footprint I don't even care about it

First it was lean. Then it grew and became bloated. Then people complained. And then available resources grew so fast that it didn't matter.

I didn't say emacs is too bloated to use, so your entire comment is a little off base. I said people have complained about emacs getting bloated in this same way for the same reasons. And they have. Historical fact.

Yes, it's quite easy to get vim to a point where it's mysteriously slow at mysterious times due to random plugins installed. The lack of async makes this all the easier since everything blocks UI to begin with.
If it is slow, use vim --startuptime to check for slow plugins on startup.
I can't speak for the parent but I would say the most commonly seen effect of complexity is stagnation. Change becomes harder, promised features take forever, the developers lose motivation and significant new releases grind to a halt.

Atom exists because ST3 was seen to stagnate, ST3 exists because TextMate was seen to stagnate etc. They start as simple but incomplete tools that are moving fast and blah blah - its just the software circle of life.

TextMate 2 actually tried to solve the stagnation problem by open-sourcing. It has worked quite well and updates became much more frequent. Still though, it doesn't feel as easy to extend as Atom or VIM.
Except that neither ST3 or TextMate were open source.
TextMate 2 is, thankfully. Although the point still stands; one editor I'd love to see take off but doubt is Vico, a modern "Vim-esque" editor written in Nu :)
has anyone who has ever used Emacs not complained of it being bloated? Isn't that the de facto argument in the age-old Emacs vs. Vi flamewars?
Firefox: the initial design principle desired a browser that was simple, fast, pluggable, compared to the old Mozilla browser which had features out the ass
I must say, the same people that criticized Eclipse for its "bloat" that are now making excuses for the bloat in Atom is very amusing.

In terms of performance, stability and extensions this doesn't even hold a candle to Eclipse Mars.

Don't know about Eclipse, but NetBeans runs much faster than Atom on my Mac, with far fewer pauses. Unfortunately, Atom is built in a language with a much worse GC than NetBeans (or IntelliJ, or Eclipse).