Now we do the same, but we look at the text editors of 1995 which used 4 MB of RAM as incredibly efficient and well made, paragons of craftsmanship.
Things never change, the old generation fights the new one and calls it stupid.
I'm not saying old editors weren't more efficient but the stuff editors handle today got more complex. LSP servers do way more analysis than any 1995 editor and they do it in an editor agnostic way. It costs more memory but it also lets us all jump into the future faster rather then every editor having to implement their own for every language.
An Unicode font is easily 15 mb in size. Let alone that you'll have several of those. And the code and memory that takes to do all the magic of rendering it, hinting, and subpixel antialiasing.
Then there's that a 4K framebuffer is 32MB in size.
Smooth compositing requires every running program to have a buffer it draws into. So there goes a couple hundred MB more just to make sure you don't see the screen repaint like in Windows 3.1.
Yeah, you can have compact software where your only requirement is that it uses ASCII, does it at 80x25 and doesn't do anything more fancy than editing text.
The idea was that programs would share libraries, and so why have a dozen identical frameworks on the same system? Install your libraries into system32. If it's already there but an earlier version, deploy your packaged one on top.
Turns out that nobody writes good installers, and binary level dependency requires too much discipline, and dependencies are a pain for users to deal with.
So shove the entire thing into a huge package, and things actually work at a cost of some disk space and memory.
Why? Well, because it's the one everyone else uses. It's what comes with everyone's Linux distro. Therefore, if there's something wrong with it, it's pretty much guaranteed it'll break other stuff and somebody else is going to have to fix that. Also it probably supports everything anyone might ever want.
If your 700 LOC TTF renderer doesn't perform as it should, it might become my problem to figure out why, and I don't really want that.
I ended up with this one in large part because it took less time to rewrite libschrift (the C option I mentioned) and trim it down for my use than figuring out how to make Freetype work for me. I now have a codebase that's trivially understandable in an hour or two of reading. That's what compact code buys you.
No, it won't do everything. That's fine. If I need Freetype for something where it actually saves me effort, I'll use Freetype. It's not about blindly rewriting things for the sake of it, but not lazily default to big, complex options whether or not they're the appropriate choice.
A lot of the time people pick the complex option because they assume their problem is complex, or because it's "the default", not on the merits.
There are tradeoffs, and plenty of times where the large, complex component is right, but far too often it is picked out of laziness and becomes a huge liability.
I have ~10 000 .exe files on this machine, if none of them shared code and/or data (or were written in a ``modern`` language with 50+ MB hello worlds), they would not fit on my 1TB disk.
What if you're working on something reasonably novel, like say, open source VR? Well, turns out you may want a quite eclectic mix of dependencies. Some you need the latest version, because it's state of the art stuff. Some is old because the new version is too incompatible. Some is dead.
Getting our work into a Linux distro is on my list, but even if dealing with all the dependencies works out, there's the issue of that we sometimes need to do protocol changes and upgrade on our own schedule, rather than whenever the new distro is released.
Distros are great for things that are supposed to integrate all together. They're less ideal for when you're working on something that is its own, separate thing like a game.
So for the time being, shoving it all into an AppImage it is.
You say that as if it was some kind of failed one-off experiment of the 90s. We tried it in the Multics days, it caught on and the design philosophy is still popular to this day. It works quite well in systems with centrally managed software repositories, even if it doesn't in a system where software is typically distributed on a 3rd party shareware collection CD or download.com.
A color dialog was tens of KB of code in the 1980s.
My own editor handles Unicode well enough for most users in a few dozen lines of code. RTL would take a bit more, but not much. LSP servers if anything reduce the need for the editor resource use to grow.
It's not that these justify no extra resources use because they do, but they don't need to significantly increase resources use.
A lot of apps get away with huge resource use simply because people aren't used to paying attention to it any more, because for most it affects them little enough in isolation, per app, that when it matters addressing the resources use of one hardly makes a difference.
It's only when you subjectively remove all the features that you don't care about that it becomes doable to make smaller editors. And that's fine. But you can't have your cake and eat it.
The reason most people don't care is because it simply doesn't matter. Not even a little bit. Laptops are cheap. Memory is cheap. CPU is cheap. Your time is not. And it takes investing your time to make this stuff more optimal and faster. And VS code just does a lot of nice things that make you more productive. I use Intellij myself which uses even more resources. But it's a bit smarter and saves me even more time. The point with both is that you lose more than you gain by replacing them with something faster. It's not worth it.
My first computer was a commodore 64, so I'm well aware what that thing could do (and couldn't do). I'm writing this on a M1 macbook. Orders of magnitudes faster, doing things I could not imagine back when I had a commodore 64, etc. You can have one second hand / refurbished for next to nothing. Basically below my day rate when I'm consulting.
Of course, Sublime Text exists and does everything I want from VSCode at a fraction of the hardware usage. So I don't have to choose one or the other, because actual good software exists.
It's not special. If anything it's one of the most clunky editor I've used because it tries to shoehorn everything into a convoluted UI. It's because my time matters to me I avoid VS Code as much as possible.
The problem with VS Code is not that it's too slow, or too memory hungry. It could use far less, sure. And it could do so without losing any of the things about it that makes me dislike it.
If you don't like it, use something else of course. But there are valid reasons for it being browser based and a lot of people choose to use it at this point.
A lot of people choosing to use it is besides the point being made, which is not that people won't use it, but that it could be a lot leaner without sacrificing functionality.
> It's a bit theoretical because no editors exist that are smaller that do all of what vs code does
You can't ever compare two things if you look for all features to match. Sublime is a pretty good comparison - it's wicked fast, has a bunch of the same features and language extensions. Emacs handles unicode just fine and has a huge extension surface area.
> The reason most people don't care is because it simply doesn't matter
Hard disagree here - the reason people don't care is because features sell, and as you said, the alternative option isn't there. I work in Unreal Engine most of the time, and about 3-4 years ago, there was an almost overnight exodus of game programmers who would live and die by Visual Studio who switched to Rider, primarily because it was faster than VS+VAX.
> Laptops are cheap. Memory is cheap. CPU is cheap. Your time is not
This only applies with one application. Now add Slack/Teams, Postman, Outlook, FF/Chrome, Spotify in the mix, and all of a sudden I'm running 6 full web browsers duplicated with all their resources isolated, using more menoey and CPU than Intellij does. I'm fine with Intellij pegging my 32 core thread ripper to index millions of lines of code. I'm less fine with Postman using more CPU than Intellij to display a json document.
> Im writing this on a M1 macbook
Depending on what software you're working on, your users aren't using M1 Macbookd. My partner's work machine is a5 year old i3 with 8GB of RAM. It's borderline unusable with teams and Outlook running IMO. But the person who benchmarks teams is doing so on the M1 MacBook.
Or your company should buy you a new 96 core Threadripper 1 TB RAM system so that when you use Spotify/Slack/Postman it doesn't impact your productivity.
You feel entitled to use a $10K machine to compensate for slow IntelliJ for maximum productivity and convenience, yet deny others (Postman/Slack/...) using the most productive and convenient technology for them (Electron). And while continuing to use their convenient products, you say they are bad. Use IRC, use curl instead of Postman.
The Postman programmers say the same thing: our users have $3K+ machines, no point in optimizing code to be fast, instead lets add more features since it's clearly working and our users are not switching. Obviously they love the iteration speed that Electron gives us.
I've been a paying slack customer for a decade at this point. I pulled up my email, my support ticket for "slack is using more ram than visual studio" was in February 2015. I don't have the political sway over Salesforce to makthem make these sorts of decisions.
> You feel entitled to use a $10K machine to compensate for slow...
Youre doing it again. I don't feel entitled. I don't have a choice in my chat app, my employer forces it on me. And even if I did, slack is on the whole the least worst option. As for postman. I did the same thing. I was a paying customer, I submitted support tickets, provided traces when asked and ultimately I did decide to change tool.
> while continuing to use their convenient products, you say they are bad.
Am I not allowed to have an opinion just because I have a fast machine? Am I not allowed to want my software to be better?
> The Postman programmers say the same thing:
No they say "performance is a top priority for us, we're sorry you're not happy with it. Please send us your hardware specs" and the ticket gets auto closed after 2 weeks.
> Obviously they love the iteration speed that Electron gives us.
It's not just electron - snappy electron apps exist. Startup time aside. VSCode is pretty damn good. Figma is an excellent example of how good it can be (and if you want to compare what it looks like when a company cares Vs a company doesn't, see figma and Miro).
$10/month is not what I meant by "paying them". I worked at a company where clients would routinely pay us $200K to implement a particular niche feature which was not on the roadmap. If they asked for a non-roadmap feature, yes, the ticket would be closed "not-planned".
> the alternative option isn't there
> I don't feel entitled. I don't have a choice in my chat app
Your responses are predicated on the option being there and the person you're responding to is just not taking it. This despite the fact that his or her responses strongly suggest they would take it if it were there, but it's simply not an option.
All this Electron app complaining reads like First-World Problems(TM).
Or one can go back complaining "how the world is cruel, people are mean and greedy, I'm a good and misunderstood person which writes the most efficient and user considering software, unlike the evil people at Slack"
Not GP, but they could buy me a 1024 core monster if it exists, it would still not solve the problem of Slack.
I still have to open it in the browser every once in a while, to search old threads or other stuff that is not supported. But day to day I can do everything in irc. There is also a weechat plugin afaik.
It's a bit annoying to configure the access but it seems the tokens never expire (or have not yet expired) so it shouldn't be too frequent for you either.
Anyway, end users care even less. The paying user variety typically has a newish computer (of the last five years or so). The rest are not a great revenue stream. But of course, if you develop for users stuck on really old crappy laptops, of course you are going to invest your precious time in making sure they get a great experience and make all sorts of compromises to ensure they do. But for the rest of the users, good enough is good enough. You'll see from your revenue/usage statistics what that is.
I find the people that whine the most about this topic are exactly those people you should expect to have decent hardware (i.e. developers). Either way, use things that are useful to you.
Spotify and Slack, Teams, etc. seem to be doing OK with user popularity for example and don't seem to be getting a lot of churn over their application performance. And of course a lot of this stuff is used on mobile as well. I've used both for the last ten years without much issues on modestly sized laptops. 16GB is more than enough for me running stuff like that, vs code, intellij, a bunch of docker things, and a few other bits and bobs.
People using MS Windows seem to get a particularly rough experience. That's why lots of developers prefer mac or linux based machines.
If those apps were PWAs instead, it would mean no extra browser copies are running. In my experience this only really accounts for 70-100 MB per app for the browser copy. No reason slack couldn't be a PWA, same with Spotify.
I'm not really sure how slack and others use so much RAM. I've built quite functional, complicated, and non trivial web apps. Mine typically use <50 MB with some coming in at 20-25 MB. When I'm deploying in electron I'm still in the 80-150 range.
The biggest performance questions for me are network latency vs local data and figuring out ways to mitigate network latency. The difference between 200 ms navigation and 5 ms navigation is pretty stark. Even if most people don't flinch at 200 ms.
Remote editing back in the 1980s was such a common thing on the Smalltalk and Lisp Machines that all system code was on another machine, more times than not you wouldn't even notice that it was a remote file!
One could do "emoji" just fine as well, and files would have WYSIWYG like look to them using "fat strings" -- that is 1980s technology. There is a dungeon crawler map using that feature to render the map as graphics, it is how you would implement chess pieces, or other "picture" like stuff.
Auto-complete was already standard, similar look up of "who calls" / "who uses" functionality to figure out where things are used, online documentation, etc etc etc...
So all this was perfectly possible, and already used and abused in 1995 -- VSCode isn't doing anything new in that regard.
Lest we mention Plan 9!
Behold! The peak of technological prowess! So many poor souls of the past died in misery and 4 MB of RAM. They could not taste those sweet fruits of progress.
E.g. in "waste" that is fine, I'd categorise AmigaE's choice to read the entire source file into memory, instead of doing IO character by character, or line by line from small buffers. It was a recognition that there was no compelling reason to not sacrifice that small amount of RAM for simplicity and speed. What you gain can differ, but as long as the benefit is proportionally good enough relative to the cost, that's fine.
But so much modern software pulls in huge dependencies for very little benefit, or try to be far too much, instead of being focused tools that interoperate well.
It's not so much that the new generation is stupid, as that a lot of people (of any generation) always choose the easy option instead of stopping to think. Sometimes that's the right tradeoff, often it's not.
And hardware advances mean you can get away with more and more. Sometimes that justifies more extravagant resource use. Often it doesn't.
This is only an issue if your OS doesn't have virtual memory and mmap. Modern OS's automatically prefetch files into free RAM (so there's no such thing as "free RAM is wasted RAM" either). I think newer versions of Amiga OS were supposed to be getting virtual memory support at some point, too.
It was an inspired choice, and about 30 years on it's still underutilized, on machines that typically have 3-4 orders of magnitude more RAM.
I was with you until here, which I think is the wrong take. That is, this gets it exactly backwards. It's not just that every generation gets upset at the previous generation so let's all shrug and move on, it's that this is really a thing that is unfolding from one generation to the next.
It seems like the reflex of oh well the previous generation said it so let's ignore it comes up a lot, to the point that I have this go to example that I use every time it does. I'm a baseball fan. And one thing you used to hear in the '80s, with a guy like, say, Rob Deer or Steve Balboni, was that they tried too hard to hit home runs and they struck out too much. Then you heard that in the '90s as well. Then you heard that in the 2000s, especially with money ball and guys like Jack Cust. Then it just kept getting even more extreme with guys Carlos Pena and now Joey Gallo.
So one thing you could say is, well, every generation says that there were less strikeouts in third day. But there's actually data on this and..... it's true! Almost every decade, from the 1800s through every decade of the 1900s through now, strikeouts really have been going up year to year. And so that intergenerational commentary, well, it's describing a real thing that really is happening.
The same can be said of other things, like people saying they always used to remember the environment being better. Or people saying attention spans are getting shorter. But, they are.
The instinct here I think is to dismiss these since every generation says it. But I think the conclusion should be opposite, that these are real things unfolding on a multi-generational level. So if you see it happening with software, maybe that's because there's really something to it.
And there is no dissatisfaction of the younger generation? There is no, this is the old way let's do it differently because we are more clever by the young generation?
The argument seems to imply that the dissatisfaction would be there regardless of the circumstances. But the point I'm making is that the dissatisfaction can be understood as meaningful and not as just a generalized disposition that's a natural consequence of getting old.
And whether or not I'm right on that, the devil is in the details there, and it's going to depend on a case-by-case basis. But it won't do just to say well the older generation is going to complain no matter what, because that doesn't credit them with the possibility of complaining for a legitimate reason.
I agree with the factual observations in your post, but there's an additional bit here, and that there's qualitative value being assigned to what The Youths don't mind and The Olds protest. In baseball, the guys who strike out a lot but hit a ton of home runs create more runs, and therefore create more wins, than most base-hit machines (obvious outliers exist, but you get the idea). On my computer, VS Code does more things that benefit me than vim does (and the outlier here, I guess, would be "a lovingly crafted vim monstrosity that uses all the LSPs etc. designed for VS Code et al in the first place"--doable but not the happy path, etc.).
There's also (and IMO this is more in code than baseball) some kind of bizarre moral valence assigned, and that I don't even pretend to understand, but that's a different story.
A few things here. I want the main center of gravity in the point that I'm making to be a way of approaching intergenerational reports of a given phenomenon, namely that they shouldn't just be dismissed as a function of old age or a function of changing perspective. After that point, pretty much any point you want to make is fair game as far as I'm concerned. In the case of baseball, there are positives and negatives. It clearly seems to be a positive trade-off for hitters who are choosing which style to take. I suppose there's another consideration at a higher level as to whether it benefits the game itself. So that can go either way in my opinion depending on what's important.
I tried at the end to throw in some other examples, shortening of attention spans, and environmental degradation. I think in those cases it's clear that there's something negative going on. But in general we don't have to agree with the value judgment if it's negative, but I think the positive or negative value judgments is an independent thing from the phenomenon of multiple generations attesting to some thing happening.
Tell a kid learning to program today "you should program in assembly because it's efficient, like I did back in my days".
Kid looks around and sees it would take him 3 days to implement a hello world in assembly, but only 3 seconds to do it in Python. He has a 16 core computer with 64 GB of RAM. Both hello worlds run instantly. So how does that advice make sense? Kid calls you a crazy old man out of touch with the times. Kid goes on running locally a 50 GB LLM to make it do a hello world and feels very excited about the future of programming.
For one, I think the accepted premise in this conversation up till now was that there is a real issue with software bloat. And you've switched that detail out for a different one where we assume no discernible bloat or difference in performance as time passes.
I also don't think that I understand what's going on in the pivot from generational examples to individual ones. I feel like at least the comment I replied to was pretty clearly about generational trends. But on another level I think that the upshot is the same regardless of whether your surveying that disagreement at a general level versus its equivalent manifestation at an individual level.
I think the upshot would be the same in each case as long as you keep all the details the same, and I think somewhere in the transposition from the general to the individual and agreed assumption about bloat and underperformance of software, as well as some implications about what that means about prevailing assumptions and practices surrounding software development, got lost in the translation from one to the other.
That's because the text editors don't exist in a vacuum; the 4MB-RAM text editor would be slow on a 1995 computer but blazingly-fast on a 2024 computer.
VS Code is slow and annoying to use, and RAM is just a more measurable symptom of that.
Jetbrains (IDEA IntelliJ, Pycharm, etcetc) put a lot of effort into making their IDE low latency as it was getting to a point of being almost ridiculous. Their editor is built in Java, and they run on their own runtime as they have so many hacks and tweaks to make it work as a desktop app as well (font rendering, etc).
Pavel Fatin has a [great article](https://pavelfatin.com/typing-with-pleasure/) about typing latency and his work around implementing this in IntelliJ, well worth a read.
Running a heavily scriptable editor with a GUI was entirely viable on a 7.16MHz Amiga with 1MB RAM, and more responsive than many modern editors.
Integration with other tooling, like RCS, compilers, or linkers was a given for Amiga apps at that time.
(FrexxEd was also notable for exposing internal buffers as files in a special filesystem, so you could e.g. lint or compile or call your revision control - limited as they were - directly on the buffers without any custom integration)