7 ms·

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, b

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.

Qwertious 3y ago
>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 3y ago
  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/ https://pavelfatin.com/typing-with-pleasure/) about typing latency and his work around implementing this in IntelliJ, well worth a read.
nox101 3y ago
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.
- dale_glass 3y ago
  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.
  - xipix 3y ago
    That's data size, not code. There's no fundamental reason that a program that can smoothly render unicode at 4k needs a GB download when kB could suffice.
    - dale_glass 3y ago
      We tried that in the Windows 9x days. We called that "DLL hell". 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.
      - vidarh 3y ago
        You presume one option when the other option is a bundled but smaller renderer. The truetype renderer my terminal uses is about 700 lines of code. The C it's a translation of is about 1500. There's a sweet spot that might well be a bit higher to e.g. handle ligatures etc., but the payoff from going from that to some huge monstrosity is very small.
bluetomcat 3y ago
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 :-)
- zozbot234 3y ago
  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.
- vidarh 3y ago
  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)
vidarh 3y ago
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 3y ago
  > 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.
  - vidarh 3y ago
    Yes, but because it was an issue, even now decades later a lot of compilers still use file IO instead of just reading a file in one go even when you gain benefits (e.g. no "ungetting" or building a token buffer - just keep the index of the start and end). I'm guilty of that myself. 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.
ben_w 3y ago
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…)
glenstein 3y ago
>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 3y ago
  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.
  - funcDropShadow 3y ago
    > But the dissatisfaction of older generation is constant for thousands of years. 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?

Qwertious 3y ago

>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 3y ago
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/ https://pavelfatin.com/typing-with-pleasure/) about typing latency and his work around implementing this in IntelliJ, well worth a read.

nox101 3y ago

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.

dale_glass 3y ago
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.
- xipix 3y ago
  That's data size, not code. There's no fundamental reason that a program that can smoothly render unicode at 4k needs a GB download when kB could suffice.
  - dale_glass 3y ago
    We tried that in the Windows 9x days. We called that "DLL hell". 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.
    - vidarh 3y ago
      You presume one option when the other option is a bundled but smaller renderer. The truetype renderer my terminal uses is about 700 lines of code. The C it's a translation of is about 1500. There's a sweet spot that might well be a bit higher to e.g. handle ligatures etc., but the payoff from going from that to some huge monstrosity is very small.

bluetomcat 3y ago

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 :-)

zozbot234 3y ago
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.
vidarh 3y ago
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)

vidarh 3y ago

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 3y ago
> 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.
- vidarh 3y ago
  Yes, but because it was an issue, even now decades later a lot of compilers still use file IO instead of just reading a file in one go even when you gain benefits (e.g. no "ungetting" or building a token buffer - just keep the index of the start and end). I'm guilty of that myself. 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.

ben_w 3y ago

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…)

glenstein 3y ago

>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 3y ago
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.
- funcDropShadow 3y ago
  > But the dissatisfaction of older generation is constant for thousands of years. 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?