141–150 of 173 posts
New world, same old problems. Fascinating to see how this parallels the way Emacs tackled this problem long ago. - https://lwn.net/Articles/673724/ - https://news.ycombinator.com/item?id=11001796
Earlier quoted context omitted.
And here's a relevant explanation from drfuchs. https://news.ycombinator.com/item?id=13076098 I quote it in full, here: OK, if you promise to stay off my lawn, I'll explain the history behind undump. Back in the 70's, the big CS departments typically had DEC 36-bit mainframes (PDP-10, PDP-20) running the Tops10/Tops20/Tenex/Waits/Sail family of operating systems. These are what Knuth used to do all of TeX, McCarthy L…
Hey! I don't get the karma points?!
What a compliment to the VSC team that after all this work, Atom still doesn't seem to match startup time, or more importantly perceived performance while editing.
It's a more interesting comparison since they're both bound by similar constraints, and building cross platform apps.
In the bad old days I once worked for a MS competitor where there were often complaints of unfair competition. Most often around how knowledge of closed sourced OS internals allowed optimization insights unavailable to others.
Not all MS devs are great for sure, but I'm inferring two things here. The VSC team is pretty damn good, and that IP and institutional knowledge from decades of investment in dev tools probably helps a bit.
I love it when new problems can be solved in old ways. In physics we say there aren't 10,000 problems there are just 10,000 manifestations of 5. And it really seems like that's true here. Maybe we should stop laying off people for being old lol.
The industry is doing fine without the old workers with outdated skillsets. Correctness does not matter as much as velocity to release.
90% of the "innovation" in application programming is just an exercise in combinatorial virtualization.
(That said, it's not all bad. The browser has had a remarkable and wonderful effect on GUI application architecture that probably wouldn't have happened elsewhere.)
Is there any way not to conclude they have just been out designed/architected/optimized by Microsoft? What a compliment to the VSC team that after all this work, Atom still doesn't seem to match startup time, or more importantly perceived performance while editing. It's a more interesting comparison since they're both bound by similar constraints, and building cross platform apps. In the bad old days I once worked fo…
Speed is only one of the issues–I'm actually quite happy with Atom in that regard. VSCode has a much more restricted API, and a more robust extension system. With Atom, I always felt like extensions started interfering with each other, and with the 'vanilla' experience. OTOH, I was exploring a few ideas, such as inline rendering of comments in markdown, and that's really only possible in Atom.
I'm way more worried about memory issues while running. Atom take up 1 gig+ with very little open. It pushes all my other tools out of RAM and into swap. Switching to the browser to see documentation takes a few seconds if I'm lucky. Compiling a few more seconds to page in. Ssh a few more. Everything on my laptop slows to a crawl as they fight for RAM with Atom taking up the way more than it should. I know the answer…
I'd say buy some more RAM, it IS cheap and you never have too much.
I'm way more worried about memory issues while running. Atom take up 1 gig+ with very little open. It pushes all my other tools out of RAM and into swap. Switching to the browser to see documentation takes a few seconds if I'm lucky. Compiling a few more seconds to page in. Ssh a few more. Everything on my laptop slows to a crawl as they fight for RAM with Atom taking up the way more than it should. I know the answer…
Earlier quoted context omitted.
About 10 seconds of startup opening a directory, from terminal to loaded workspace. I'm on a MacBook Pro (Retina, 13-inch, Early 2015). I have 76 community plugins installed.
76? Daaam. I thought I was overdoing it at 53. (If anyone wants to check: ls ~/.atom/packages | wc -l # minus 1 for the README Have you checked Timecop? (cmd-shift-p, "timecop") Might be a few you can do without.
I'm way more worried about memory issues while running. Atom take up 1 gig+ with very little open. It pushes all my other tools out of RAM and into swap. Switching to the browser to see documentation takes a few seconds if I'm lucky. Compiling a few more seconds to page in. Ssh a few more. Everything on my laptop slows to a crawl as they fight for RAM with Atom taking up the way more than it should. I know the answer…
What is cheaper, more memory or a SublimeText license?
I'll take the license.
New world, same old problems. Fascinating to see how this parallels the way Emacs tackled this problem long ago. - https://lwn.net/Articles/673724/ - https://news.ycombinator.com/item?id=11001796
I don't recall overcoming long startup times in vi and vim . Did I miss something?