19 ms·

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

by 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.
    - boomlinde 3y ago
      > We tried that in the Windows 9x days. 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.
    - 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.
      - dale_glass 3y ago
        As somebody who actually works on a pretty large program, no, I'm absolutely not going to use your 700 LOC TTF renderer. I'm going to use the 128K LOC FreeType. 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.
        vidarh 3y ago
        I'm not suggesting you should. I'm pointing out that these things can be done with a whole lot less code. And a lot of the time so much less code that it is less of a liability to learn a smaller option. Put another way, I've had to dig into large font renderers to figure out problems before because they didn't work as expected and it became my problem, and I'd much prefer that to be the case with 700LOC I can be intimately familiar with than a large project. (I'm old enough to have had to figure out why Adobe's Type1 font renderer was an awful bloated mess, and in retrospect I should have just rewritten it from scratch, because it was shit; that it was used by others did not help us at all) 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.
vidarh 3y ago
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.
- jillesvangurp 3y ago
  It's a bit theoretical because no editors exist that are smaller that do all of what vs code does. And a lot of what it does relies heavily on the notion that it's running in a browser. So, just tossing that out won't fly since you kind of need it for at least some of the features. 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.
  - bigstrat2003 3y ago
    My time is free. I'm not going to see a dime for any time I save by using this tool or that tool on my computer. Hardware, on the other hand, is not free, so I prefer to sacrifice time for being able to use less expensive hardware (within reason). 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.
amszmidt 3y ago
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.
- xcdzvyn 3y ago
  > Smalltalk and Lisp machines Lest we mention Plan 9!
  - pjmlp 3y ago
    And Inferno as well.
wolvesechoes 3y ago
> 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.

by nox101 3y ago

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.
  - boomlinde 3y ago
    > We tried that in the Windows 9x days. 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.
  - 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.
    - dale_glass 3y ago
      As somebody who actually works on a pretty large program, no, I'm absolutely not going to use your 700 LOC TTF renderer. I'm going to use the 128K LOC FreeType. 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.
      - vidarh 3y ago
        I'm not suggesting you should. I'm pointing out that these things can be done with a whole lot less code. And a lot of the time so much less code that it is less of a liability to learn a smaller option. Put another way, I've had to dig into large font renderers to figure out problems before because they didn't work as expected and it became my problem, and I'd much prefer that to be the case with 700LOC I can be intimately familiar with than a large project. (I'm old enough to have had to figure out why Adobe's Type1 font renderer was an awful bloated mess, and in retrospect I should have just rewritten it from scratch, because it was shit; that it was used by others did not help us at all) 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.

vidarh 3y ago

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.

jillesvangurp 3y ago
It's a bit theoretical because no editors exist that are smaller that do all of what vs code does. And a lot of what it does relies heavily on the notion that it's running in a browser. So, just tossing that out won't fly since you kind of need it for at least some of the features. 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.
- bigstrat2003 3y ago
  My time is free. I'm not going to see a dime for any time I save by using this tool or that tool on my computer. Hardware, on the other hand, is not free, so I prefer to sacrifice time for being able to use less expensive hardware (within reason). 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.

amszmidt 3y ago

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.

xcdzvyn 3y ago
> Smalltalk and Lisp machines Lest we mention Plan 9!
- pjmlp 3y ago
  And Inferno as well.

wolvesechoes 3y ago

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