[hugryhoop]

He was calling 1995 text editors which used 4 MB of RAM incredibly bloated compared to the lean software of his youth which ran in 32 KB.

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.

[nox101]

That 1995 text editor didn't handle unicode. Didn't edit all the languages of the world. Didn't handle emoji. Didn't do auto-complete. Didn't replace colors in CSS with their actual color and popup an inline editor to edit them. They didn't edit remotely (editing remotely is not the same as tmux + vim). VSCode not only edits the files. When you're in a terminal on the remote machine and type 'code somefile', somefile opens on your local machine. When you start a web server in the VSCode terminal, VSCode auto forwards it to your local machine.

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.

[amszmidt]

I know that this is becoming a trope, but Smalltalk and Lisp Machines did all those things far before 1995. Similarly, GNU Emacs today is capable of all of the above and has been managing for multiple decades at this point in a more modern take of the world...

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.

[vidarh]

None of what you describe requires a lot of resources. Remote editing stubs are decades older than VS code, but also, many of us used X - for many years I did all my work over the network because there was no reason not to.

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.

[dale_glass]

People drastically underestimate the cost of things we now expect.

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.

[wolvesechoes]

> Didn't handle emoji

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.

[vidarh]

There is waste that is fine, and there's waste that doesn't really come with an upside.

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.

[zozbot234]

> in "waste" that is fine, I'd categorise AmigaE's choice to read the entire source file into memory, instead of doing IO

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.

[glenstein]

>Things never change, the old generation fights the new one and calls it stupid.

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.

[scotty79]

There is real thing happening. But the dissatisfaction from that thing happening is what's the criticism is all about. And those are two separate things. Things changing might be real or not. But the dissatisfaction of older generation is constant for thousands of years.

[dist-epoch]

You are focusing on the generational trends, I was focusing on the individual.

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.

[eropple]

> 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.

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.

[Qwertious]

>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.

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.

[thejosh]

I don't care about memory usage for editors as much I care about input latency and responsiveness.

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.

[bluetomcat]

1995 text editors didn't use a "layout engine" that executes JavaScript, attempting to JIT fragments of code. They were an event loop that processes native OS events and responds with repainting areas of the window. They also weren't able to automatically recognise language syntax and didn't have Git integration :-)

[vidarh]

One of my favourite editors from the 1990's was FrexxEd, co-authored by the author of Curl, whose main event loop processed Arexx commands and events for every internal command, so you could rebind every event to a script in their own scripting language (FPL; C-like), and access every internal function from it. (It incidentally also came with FPL scripts that provided some degree of syntax highlighting for a few languages, and you could add more, though not as expansive as most modern editors).

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)

[zozbot234]

CSS grid exists now, so it should be easy enough to achieve the same "repaint small areas of the window, don't do global layout" workflow in a web-based app.

[ben_w]

BBEdit was first released in 1992; I'm not sure what that version was like, but I'm still using it now. That said, the version on my disk right now (30.3 MB) wouldn't have fitted into the RAM of the Performa 5200 I had in the 90s (8 MB initially, can't remember what I upgraded it too in the end, 24 or 32…)