I am told that in Visual Studio 2008, you could debug line by line, and it was smooth. Like there was zero lag. Then Microsoft rewrite VS from c++ into c# and it became much slower

Modern software is indeed slow especially when you consider how fast modern hardware is.

If you want to feel the difference, try highly optimised software against a popular one. For eg: linux vs windows, windows explorer vs filepilot, zed vs vscode.

▲

mustache_kimono 8 months ago | parent [-]

> I am told that in Visual Studio 2008, you could debug line by line, and it was smooth. Like there was zero lag. Then Microsoft rewrite VS from c++ into c# and it became much slower

Not exactly a surprise? Microsoft made a choice to move to C# and the code was slower? Says precious little about software in general and much more about the constraints of modern development.

> If you want to feel the difference, try highly optimised software against a popular one. For eg: linux vs windows, windows explorer vs filepilot, zed vs vscode.

This reasoning is bonkers. Compare vastly different software with a vastly different design center to something only in the same vague class of systems?

If the question is "Is software getting worse or better?", doesn't it make more sense to compare newer software to the same old software? Again -- do you remember what Windows and Linux and MacOS were like in 90s? Do you not believe they have improved?

▲

rk06 8 months ago | parent | next [-]

I have used windows since 20 years. I distinctly recall it becoming slower and painful over time despite using more powerful hardware.

But hey that could be nostalgia, right? We can't run win xp in today's world. Not is it recommend with lots of software ot being supported on win xp.

The same is case for Android. Android 4 has decent performance, then android 5 came and single handedly reduced performance and battery life. And again you can't go back due to newer apps no longer supporting old android version.

This is also seen with apple where newer os version is painful on older devices.

So, on what basis do you fairly say that "modern apps are slow"? That's why I say to use faster software as reference. I have linux and windows dual boot on same machine. An dthen difference in performance is night and day

▲

mustache_kimono 8 months ago | parent [-]

> So, on what basis do you fairly say that "modern apps are slow"? That's why I say to use faster software as reference. I have linux and windows dual boot on same machine. An dthen difference in performance is night and day

Then you're not comparing old and new software. You're comparing apples and oranges. Neovim is comparable to VS Code in only the most superficial terms.

▲

troupo 8 months ago | parent [-]

> Neovim is comparable to VS Code in only the most superficial terms.

Oh no. It can be compared in more than superficial terms. E.g. their team struggled to create a performant terminal in VS Code. Because the tech they chose (and the tech a lot of the world is using) is incapable of outputting text to the screen fast enough. Where "fast enough" is "with minimal acceptable speed which is still hundreds of times slower than a modern machine is capable of": https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...

	▲	mustache_kimono 8 months ago \| parent [-]
		> E.g. their team struggled to create a performant terminal in VS Code. WTF are you talking about? Neovim doesn't implement a terminal?

▲

troupo 8 months ago | parent | prev [-]

"our computers are thousands of times faster and more powerful than computers from the 90s and early 2000s, so of course it makes sense that 'constraints of development' make it impossible to make a working debugger on a modern supercomputer due to ... reasons. Doesn't mean this applies to all software ... which is written by same developers in same conditions on same machines in same languages for same OSes"

▲

mustache_kimono 8 months ago | parent [-]

> so of course it makes sense that 'constraints of development' make it impossible to make a working debugger

All of these examples are Microsoft is not building X as well as it used to, which is entirely possible. However, Microsoft choosing to move languages says something entirely different to me than simply -- software somehow got worse. It says to me that devs weren't using C++ effectively. It says to me that a tradeoff was made re: raw performance for more flexibility and features. No one sets out to make slow software. Microsoft made a choice. At least think about why that might be.

▲

troupo 8 months ago | parent [-]

> It says to me that a tradeoff was made re: raw performance for more flexibility and features.

It says that "our computers are thousands of times faster and more powerful than computers from the 90s and early 2000s" and yet somehow "flexibility and features" destroy all of those advancements.

And no, it's not just Microsoft.

	▲	mustache_kimono 8 months ago \| parent [-]
		> It says that "our computers are thousands of times faster and more powerful than computers from the 90s and early 2000s" and yet somehow "flexibility and features" destroy all of those advancements. This is the brain worm. I agree with Blow and Muratori, et al., re: design patterns which are slow (aggressive OOP), and both are right about the solution (DOD). I agree that GCed languages are slower than minimal runtime non-GCed languages. Blow and Muratori are entirely right about the particulars of these tradeoffs, re: video games, their own software domain. But that's also why it's so frustrating that they don't understand that other software has different tradeoffs. "Why is this new terminal not so fast?" is a fine question, but the answer is usually something like: Programming is an economic activity with tradeoffs, and, because that's true, perhaps the terminal didn't need to be that fast (by spending the marginal number of hours to make it faster)? In the past, John Carmack and Michael Abrash did amazing things with the Pentium chip and x86 assembly, because those were the constraints on their problem. But don't forget that they didn't have the kind of constraints software has now. Memory safety and security being one important constraint they didn't really worry about unless that memory unsafety crashed the program. They didn't have distributed systems problems. They didn't have to ship their product to the cloud or the web (although they later did with Quake Live). Games are super interesting and complex, but so are distributed databases. So -- I'd argue -- it is no less amazing to build the foundational software of the web. Don't kid yourself, these are incredibly hard problems, and it's perfectly okay that such software is not written in C/C++ for all the well known reasons C/C++ has problems in these domains. The reason this argument is such a muddle is because it may not have been reasonable to build some of things we've built without a GC, and that's okay. From my own experience, I am working on a fuzzy finder in Rust, and let me tell you `fzf`, written in golang, is really hairy competition, because it has loads of features people really want and it doesn't have to worry about half the things I still need to worry about. Is junegunn a "bad" programmer and fzf a "worse" program, because my program is faster in a few arbitrary benchmarks? No, not at all. `fzf` has dozens of features we don't have and is fast enough for its domain, even where the domain expectation is non-GCed tools.