7 ms·

> a little sluggish > surprised by how quick it felt Aren't these properties of the (G)UI rather than of the processor? I've been using systems 20 years ago

> a little sluggish > surprised by how quick it felt Aren't these properties of the (G)UI rather than of the processor? I've been using systems 20 years ago that were super snappy. The same software would still be snappy today obviously. But the software has become bloated to the point that you need to run the latest generation of CPUs such that things are not sluggish. In principle you don't need 32-core GHz CPUs to move a window around on a screen without it feeling sluggish.

hnsr 1mo ago
Yeah, I think they can be a combination of processor, GPU, memory architecture, and G(UI) software. But I too have ran a super snappy XFCE desktop for ages on pretty old hardware. I only recently switched to KDE+Wayland on much newer hardware and felt like it was snappy enough to not bother me. I also remember there were times were my much more powerful dedicated GPU was outperformed by my CPU integrated GPU, which I think has something to do how shared memory can be faster for UI rendering (or maybe it was just driver-related)
amelius 1mo ago
> Aren't these properties of the (G)UI rather than of the processor? They are a result of all of them.
pjmlp 1mo ago
This applies to the whole stack, even ignoring the GUI, you would not find systems with a gazillion of processes, doing OS IPC all over the place, because the hardware could not accommodate it. But hey, microservices and static linking are the future. /s
- flohofwoe 1mo ago
  > But hey, microservices and static linking are the future. /s Aren't those two things contradicting each other? ;) I think macOS getting more sluggish in each release (which is objectively true) is just plain old bad software engineering and prioritising the wrong things. E.g. it's just Apple's version of "What Andy giveth, Bill taketh away.".
  - teiferer 1mo ago
    It's maybe a combination of incentives. Give the devs the latest shiniest model, give them a list of barely manageable feature requests , and nobody will spend the time to consider performance issues that you'd get on hardware from 10 years ago if you take approach X, Y, Z if you don't notice a difference on your formula 1 setup.
  - pjmlp 1mo ago
    Not at all, how do you think The Network is the Computer was achieved before dynamic linking became widespread?
Folcon 1mo ago
I keep thinking this and maybe I'm missing something, but I'd love to be able to opt for something in this direction, some old school constraints, I feel like we should be able to do something pretty magical these days For example, is there a version of linux that I'm missing? I've not run a desktop linux box in over a decade, any suggestions would be great, or is everyone happily running ubuntu / fedora?
- Gabrys1 1mo ago
  Use Debian. It's matured perfectly as a graphical distro IMO
  - kopirgan 1mo ago
    Yeah mine is Debian + xfce although my laptop is fairly powerful 32Gb gen 12 Intel. It's fast, light and pleasure to use. Apt any day over all those fancy flat pack etc
- gyomu 1mo ago
  Just run debian + xfce, that’ll feel super snappy on 4GB of RAM, maybe even 2 (but then of course you’re bound by whatever other apps you use)
- screamingninja 1mo ago
  Atomic OS images. I moved away from individual package management once I discovered the alternates. Currently on Bluefin (Fedora-based) - not affiliated with the project but just a happy user. https://projectbluefin.io/ https://projectbluefin.io/
- d3Xt3r 1mo ago
  No one uses Ubuntu any more (besides corporations), it's possibly the worst distro of the whole lot due to several bad decisions from Canonical (snap etc). Fedora is a decent alternative, but if you're really after performance, CachyOS is the way to go as they provide highly optimised (PGO/LTC etc) and CPU-family specific kernel, custom scheduler (BORE) and optimised binary packages (catering to x86-64-v3, x86-64-v4 and znver4+ architectures). PorteuX is also an interesting performance-optimised distro that takes a different approach - which is that of extreme minimalism (aggressive binary stripping, minimal packages) and its "Copy to RAM" feature (basically the OS runs 100% from RAM, so storage I/O bottlenecks are completely eliminated). I've tested both on a 128GB Strix Halo laptop and haven't found much of a difference in terms of snappiness, but if you have older, more humble machine, I reckon PorteuX would definitely feel more snappy. Finally in terms of snappiness, the DE you use also makes a huge difference. The PorteuX guys have just put together an interesting benchmark comparing various DEs and Wayland to X11 which is worth checking out: https://www.phoronix.com/news/Wayland-X11-Performance-PorteuX https://www.phoronix.com/news/Wayland-X11-Performance-Porteu...
Closi 1mo ago
> In principle you don't need 32-core GHz CPUs to move a window around on a screen without it feeling sluggish I think the snappiness is less this, and more about the speed to open a file, how quickly chrome pops open when you open it etc. I assume this is a combination of hardware and how fast SSD->RAM is due to the SOC, but software will certinaly play a big part too.
- teiferer 1mo ago
  > I assume this is a combination of hardware and how fast SSD->RAM is due to the SOC, but software will certinaly play a big part too. That is exactly what I'm talking about. Sorry, you are completely off. My machine 20 years ago was not an SOC and didn't have an SSD either. It was fast as lightning to open a window. What does this have to do with SSD? Or an SOC? It's all because the software is incredibly bloated, and as your comment indicates, the young generation doesn't even know this and thinks the hardware is to blame because it's 2 gens behind state of the art (so, 3.5 years old). This is very sad and exactly why things are the way they are.
  - topato 1mo ago
    “Old man yells at cloud” lol, but seriously, you’re definitely correct. Bloated binaries and unnecessary frameworks (electron and soon, tauri). Everything is built for the web, then forced into a broken and bloated mobile app and desktop binary. Zero platform optimization anymore. I keep my chromium and chromium profile loaded into a ram drive, and it’s still slow and sluggish. Tech debt and a growing monorepo has damaged it beyond recovery. I really hope those two new browser engines reach a usable state soon. Chromium, WebKit, gecko have been doing for too long without a full foundational overhaul.
  - simiones 1mo ago
    > My machine 20 years ago was not an SOC and didn't have an SSD either. It was fast as lightning to open a window. I never understand what people exactly mean by claims like this. I very vividly remember double clicking some executable, and then immediately hearing the HDD start to spin, and waiting with baited breath to see if it will spawn a window or silently fail, as programs on Windows 98 (the only option for personal computers at the time) often did. So what exactly was snappy? Nothing that runs off a HDD is ever snappy.
ahoka 1mo ago
It's the property of the display refresh rate.
- flohofwoe 1mo ago
  A high refresh rate is only a crutch/workaround to reduce latency caused by too many pipeline stages until an input action shows up on the screen. A better fix is too reduce complexity in the involved software layers.
- teiferer 1mo ago
  Yeah tell that to the chrome instance that takes 3.5 seconds to open an new tab. Because it needs to suspend one of the other tabs that are taking 5 GB of ram each.
TrainedMonkey 1mo ago
> But the software has become bloated to the point that you need to run the latest generation of CPUs such that things are not sluggish. As the old saying goes what Intel giveth the Microsoft taketh away.
- branko_d 1mo ago
  What Andy (Grove) giveth, Bill (Gates) taketh away.
- deleted 1mo ago
  [deleted]
MiroslavPokorny 1mo ago
Graphics on all o/s are single threaded, so you are correct the cpu count doesnt matter.
noduerme 1mo ago
Yeah... my solution for the last 3 decades (with a grain of salt) has been to buy the most expensive decked out Apple laptop every 6 years and never, ever update the OS. This is in line with my philosophy about shoes: I only own 5 copies of one pair (4 in boxes in my closet until I wear the current ones out). Rolling everything over to a new dev environment every 6 years is annoying but manageable. This way I took a Powerbook 3400 into the intel age, took a titanium macbook into the air age, took two airs for almost a decade from 10.4 to 10.10 or something, then an M1. Which I'm still using. The 3400 still boots into OS 9 or something. I feel like I'm forgetting one. But the point is this: Apple software usually suits the hardware it's released with, and taking their updates is always a bad idea. Just get comfy with homebrew and settle down for your 30s or 40s until you've broken all the keys and the fan stops working. A $3-4k investment in the best performing machine they have will be great essentially until the machine itself breaks as long as you scrupulously block all apple ip addresses and rip all their update shit out as soon as you get your hands on it. Also, the m5 mac mini impulse buy as a home server has been fantastic to just login to remotely, but I'm so glad I'm still using Monterey on my M1 for daily coding.
- mjochim 1mo ago
  > never, ever update the OS. > took two airs for almost a decade from 10.4 to 10.10 or something I’m curious, did macOS 10.4->10.10 not constitute an OS update? Or was this a time when you applied your rule differently?
  - noduerme 1mo ago
    I'd have to check em, it was just a guess, but I have two airs from the last decade (2009 and 2015 I think) with their original operating systems and I think one is around 10.4 and the other 10.10ish. Maybe I misunderstood your question... I never updated the OS on either of them. Or on any Mac I've owned since the mid 90s.
    - mjochim 1mo ago
      Oh I see, it was two different laptops, one with 10.4 and the other with 10.10. I thought that both started at 10.4 and then had all version updates up until 10.10.
jodrellblank 1mo ago
> "the software has become bloated" Casey Muratori has a 20 minute talk on YouTube called "Clean code, horrible performance"[1]. Using an oft-repeated example in C++ he rewrites it uncleanly and then benchmarks. Removing Classes/subclasses/polymorphism: 1.5x faster. That overhead was like reducing an iPhone 14 to an iPhone 11 performance. Replacing Encapsulation with a table-driven calculation: 10x faster. That overhead was like reverting an average desktop CPU from 2023 back to 2010 performance. Adding basic SIMD: 20x faster. His position is that the principles of Clean Code wiped out 15 - 20 years of hardware progress, for a subjective ideal of maintainability, and even if they deliver on that, the cost is too high. It shouldn't/cannot cost a decade of hardware performance to make programmer's lives easier. [1] https://www.youtube.com/watch?v=tD5NrevFtbU https://www.youtube.com/watch?v=tD5NrevFtbU
- temporallobe 1mo ago
  I have found these same principles to be true in my own projects. More modern, “cleaner” implementations usually end up with a larger code base but a noticeable reduction in performance. Bloat ruins everything.
- the_sleaze_ 1mo ago
  I write clean code with lots of encapsulation. Not C++ just an ecomm webapp but our business hinges heavily on time to load and we do great there. Clean code or messy code the thing that all fast code has in common - including your example is this: YOU FOCUSED ON IT. You measured it, then improved against the benchmark. You spent time and effort on it so it improved. That's it. That's the secret.
  - jodrellblank 1mo ago
    I object on a few fronts. One is that the rewrite has 'mechanical sympathy' with the machine e.g. arrays without pointer chasing can fit more data in CPU cache with fewer stalls while it reads over the main memory bus and waits after every item. That should not be a surprise, it's knowable in advance. Why deliberately ignore knowledge about the machine when designing the code, then come back and use that knowledge? Another objection is to the idea of "measure then improve". Imagine a delivery truck which loads parcels without checking their weight first, then drives the truck onto a weigh machine (profiling), then if the truck is overweight they unload each parcel, weigh them individually, find the one heavy one filled with lead weights, then repack the truck without it. That would be silly and inefficient, right? Now imagine they unload the truck and there's no single parcel which is surprisingly heavy and instead the goods have been packed with 'lead foam'. Who could forsee that would cause problems with the weight on the delivery truck? (Anyone!). Now what's the fix? Unpack and repack every parcel, rewrite the whole code. There's no accidentally quadratic here to remove, instead every tiny piece takes a few more microseconds than it needs to and those add up. Another objection is "YOU FOCUSED ON IT' - this implies that there is some way you can design and write code that doesn't need any focus. Part of the point of the video is that the faster code is not harder to write, there's no complex algorithms, no compiler intrinsics, no deep knowledge; it doesn't take a focused performance expert to write a switch(){} instead of a subclass. Another objection is your implication that performance shouldn't be a consideration until you measure it and find a problem, and prove that it is. Which is like saying that aeroplane design weight doesn't matter until after you build it and measure it and prove that it matters. Computers are finite and limited, why have we got to the stage of assuming they are infinite and unlimited, and then demanding proof that they aren't, over and over on a case-by-case basis? A 3D game can render a virtual world at 100 frames per second. Does a program which takes 3 seconds to show a username/password login prompt need enough resources for 300 frames of game until proven otherwise? Another objection is that you are defaulting to 'clean code is the default, performant code needs measuring and benchmarking to justify itself in every individual case. Why isn't that the other way around? Less resource-wasting code as the default, and 'clean code' only when maintainability has been measured and proved to be a problem, and only in the parts of the codebase which have the highest maintainability problems? If all the clean code, encapsulation, isolation, abstraction layers, are providing the developer benefits that are claimed - why aren't programs better? If it's now so clean and easy to refactor, why doesn't that translate to software that gets better instead of software that gets worse? Casey's example is that Visual Studio debugger updated the watch window in realtime while stepping through code, on single core Pentium 4 with 512MB RAM, and now on a modern multicore machine with 64GB RAM and an M2 SSD it can't do that. (RemedyBG can, so it's not impossible).
alerighi 1mo ago
I have in my basement a PC with Windows 98 that feels way faster using it than a modern Windows 11 full of vibecoded AI slop features.
- NetMageSCW 1mo ago
  Windows 11 isn’t full of vibe coded AI slop because that hasn’t existed long enough to affect it much. It is full of poor decisions and poor programming the old fashioned hand made way.
arendtio 1mo ago
Yes, even my 2013 Haswell-based Arch Linux KDE Desktop feels more responsive than my M4 MacBook. And I think the MacBook has so much more power under the hood, but somehow the animation settings or whatever are just not that good. To be completely fair, I use the Desktop via DisplayPort at 144 Hz, while the MacBook uses HDMI + USB-C, and I believe it's just at 60 Hz, which is also a factor, but I honestly think that this is not the primary reason.

hnsr 1mo ago

Yeah, I think they can be a combination of processor, GPU, memory architecture, and G(UI) software. But I too have ran a super snappy XFCE desktop for ages on pretty old hardware. I only recently switched to KDE+Wayland on much newer hardware and felt like it was snappy enough to not bother me. I also remember there were times were my much more powerful dedicated GPU was outperformed by my CPU integrated GPU, which I think has something to do how shared memory can be faster for UI rendering (or maybe it was just driver-related)

amelius 1mo ago

> Aren't these properties of the (G)UI rather than of the processor? They are a result of all of them.

pjmlp 1mo ago

This applies to the whole stack, even ignoring the GUI, you would not find systems with a gazillion of processes, doing OS IPC all over the place, because the hardware could not accommodate it. But hey, microservices and static linking are the future. /s

flohofwoe 1mo ago
> But hey, microservices and static linking are the future. /s Aren't those two things contradicting each other? ;) I think macOS getting more sluggish in each release (which is objectively true) is just plain old bad software engineering and prioritising the wrong things. E.g. it's just Apple's version of "What Andy giveth, Bill taketh away.".
- teiferer 1mo ago
  It's maybe a combination of incentives. Give the devs the latest shiniest model, give them a list of barely manageable feature requests , and nobody will spend the time to consider performance issues that you'd get on hardware from 10 years ago if you take approach X, Y, Z if you don't notice a difference on your formula 1 setup.
- pjmlp 1mo ago
  Not at all, how do you think The Network is the Computer was achieved before dynamic linking became widespread?

Folcon 1mo ago

I keep thinking this and maybe I'm missing something, but I'd love to be able to opt for something in this direction, some old school constraints, I feel like we should be able to do something pretty magical these days For example, is there a version of linux that I'm missing? I've not run a desktop linux box in over a decade, any suggestions would be great, or is everyone happily running ubuntu / fedora?

Gabrys1 1mo ago
Use Debian. It's matured perfectly as a graphical distro IMO
- kopirgan 1mo ago
  Yeah mine is Debian + xfce although my laptop is fairly powerful 32Gb gen 12 Intel. It's fast, light and pleasure to use. Apt any day over all those fancy flat pack etc
gyomu 1mo ago
Just run debian + xfce, that’ll feel super snappy on 4GB of RAM, maybe even 2 (but then of course you’re bound by whatever other apps you use)
screamingninja 1mo ago
Atomic OS images. I moved away from individual package management once I discovered the alternates. Currently on Bluefin (Fedora-based) - not affiliated with the project but just a happy user. https://projectbluefin.io/ https://projectbluefin.io/
d3Xt3r 1mo ago
No one uses Ubuntu any more (besides corporations), it's possibly the worst distro of the whole lot due to several bad decisions from Canonical (snap etc). Fedora is a decent alternative, but if you're really after performance, CachyOS is the way to go as they provide highly optimised (PGO/LTC etc) and CPU-family specific kernel, custom scheduler (BORE) and optimised binary packages (catering to x86-64-v3, x86-64-v4 and znver4+ architectures). PorteuX is also an interesting performance-optimised distro that takes a different approach - which is that of extreme minimalism (aggressive binary stripping, minimal packages) and its "Copy to RAM" feature (basically the OS runs 100% from RAM, so storage I/O bottlenecks are completely eliminated). I've tested both on a 128GB Strix Halo laptop and haven't found much of a difference in terms of snappiness, but if you have older, more humble machine, I reckon PorteuX would definitely feel more snappy. Finally in terms of snappiness, the DE you use also makes a huge difference. The PorteuX guys have just put together an interesting benchmark comparing various DEs and Wayland to X11 which is worth checking out: https://www.phoronix.com/news/Wayland-X11-Performance-PorteuX https://www.phoronix.com/news/Wayland-X11-Performance-Porteu...

Closi 1mo ago

> In principle you don't need 32-core GHz CPUs to move a window around on a screen without it feeling sluggish I think the snappiness is less this, and more about the speed to open a file, how quickly chrome pops open when you open it etc. I assume this is a combination of hardware and how fast SSD->RAM is due to the SOC, but software will certinaly play a big part too.

teiferer 1mo ago
> I assume this is a combination of hardware and how fast SSD->RAM is due to the SOC, but software will certinaly play a big part too. That is exactly what I'm talking about. Sorry, you are completely off. My machine 20 years ago was not an SOC and didn't have an SSD either. It was fast as lightning to open a window. What does this have to do with SSD? Or an SOC? It's all because the software is incredibly bloated, and as your comment indicates, the young generation doesn't even know this and thinks the hardware is to blame because it's 2 gens behind state of the art (so, 3.5 years old). This is very sad and exactly why things are the way they are.
- topato 1mo ago
  “Old man yells at cloud” lol, but seriously, you’re definitely correct. Bloated binaries and unnecessary frameworks (electron and soon, tauri). Everything is built for the web, then forced into a broken and bloated mobile app and desktop binary. Zero platform optimization anymore. I keep my chromium and chromium profile loaded into a ram drive, and it’s still slow and sluggish. Tech debt and a growing monorepo has damaged it beyond recovery. I really hope those two new browser engines reach a usable state soon. Chromium, WebKit, gecko have been doing for too long without a full foundational overhaul.
- simiones 1mo ago
  > My machine 20 years ago was not an SOC and didn't have an SSD either. It was fast as lightning to open a window. I never understand what people exactly mean by claims like this. I very vividly remember double clicking some executable, and then immediately hearing the HDD start to spin, and waiting with baited breath to see if it will spawn a window or silently fail, as programs on Windows 98 (the only option for personal computers at the time) often did. So what exactly was snappy? Nothing that runs off a HDD is ever snappy.

ahoka 1mo ago

It's the property of the display refresh rate.

flohofwoe 1mo ago
A high refresh rate is only a crutch/workaround to reduce latency caused by too many pipeline stages until an input action shows up on the screen. A better fix is too reduce complexity in the involved software layers.
teiferer 1mo ago
Yeah tell that to the chrome instance that takes 3.5 seconds to open an new tab. Because it needs to suspend one of the other tabs that are taking 5 GB of ram each.

TrainedMonkey 1mo ago

> But the software has become bloated to the point that you need to run the latest generation of CPUs such that things are not sluggish. As the old saying goes what Intel giveth the Microsoft taketh away.

branko_d 1mo ago
What Andy (Grove) giveth, Bill (Gates) taketh away.
deleted 1mo ago
[deleted]

MiroslavPokorny 1mo ago

Graphics on all o/s are single threaded, so you are correct the cpu count doesnt matter.

noduerme 1mo ago

Yeah... my solution for the last 3 decades (with a grain of salt) has been to buy the most expensive decked out Apple laptop every 6 years and never, ever update the OS. This is in line with my philosophy about shoes: I only own 5 copies of one pair (4 in boxes in my closet until I wear the current ones out). Rolling everything over to a new dev environment every 6 years is annoying but manageable. This way I took a Powerbook 3400 into the intel age, took a titanium macbook into the air age, took two airs for almost a decade from 10.4 to 10.10 or something, then an M1. Which I'm still using. The 3400 still boots into OS 9 or something. I feel like I'm forgetting one. But the point is this: Apple software usually suits the hardware it's released with, and taking their updates is always a bad idea. Just get comfy with homebrew and settle down for your 30s or 40s until you've broken all the keys and the fan stops working. A $3-4k investment in the best performing machine they have will be great essentially until the machine itself breaks as long as you scrupulously block all apple ip addresses and rip all their update shit out as soon as you get your hands on it. Also, the m5 mac mini impulse buy as a home server has been fantastic to just login to remotely, but I'm so glad I'm still using Monterey on my M1 for daily coding.

mjochim 1mo ago
> never, ever update the OS. > took two airs for almost a decade from 10.4 to 10.10 or something I’m curious, did macOS 10.4->10.10 not constitute an OS update? Or was this a time when you applied your rule differently?
- noduerme 1mo ago
  I'd have to check em, it was just a guess, but I have two airs from the last decade (2009 and 2015 I think) with their original operating systems and I think one is around 10.4 and the other 10.10ish. Maybe I misunderstood your question... I never updated the OS on either of them. Or on any Mac I've owned since the mid 90s.
  - mjochim 1mo ago
    Oh I see, it was two different laptops, one with 10.4 and the other with 10.10. I thought that both started at 10.4 and then had all version updates up until 10.10.

jodrellblank 1mo ago

> "the software has become bloated" Casey Muratori has a 20 minute talk on YouTube called "Clean code, horrible performance"[1]. Using an oft-repeated example in C++ he rewrites it uncleanly and then benchmarks. Removing Classes/subclasses/polymorphism: 1.5x faster. That overhead was like reducing an iPhone 14 to an iPhone 11 performance. Replacing Encapsulation with a table-driven calculation: 10x faster. That overhead was like reverting an average desktop CPU from 2023 back to 2010 performance. Adding basic SIMD: 20x faster. His position is that the principles of Clean Code wiped out 15 - 20 years of hardware progress, for a subjective ideal of maintainability, and even if they deliver on that, the cost is too high. It shouldn't/cannot cost a decade of hardware performance to make programmer's lives easier. [1] https://www.youtube.com/watch?v=tD5NrevFtbU https://www.youtube.com/watch?v=tD5NrevFtbU

temporallobe 1mo ago
I have found these same principles to be true in my own projects. More modern, “cleaner” implementations usually end up with a larger code base but a noticeable reduction in performance. Bloat ruins everything.
the_sleaze_ 1mo ago
I write clean code with lots of encapsulation. Not C++ just an ecomm webapp but our business hinges heavily on time to load and we do great there. Clean code or messy code the thing that all fast code has in common - including your example is this: YOU FOCUSED ON IT. You measured it, then improved against the benchmark. You spent time and effort on it so it improved. That's it. That's the secret.
- jodrellblank 1mo ago
  I object on a few fronts. One is that the rewrite has 'mechanical sympathy' with the machine e.g. arrays without pointer chasing can fit more data in CPU cache with fewer stalls while it reads over the main memory bus and waits after every item. That should not be a surprise, it's knowable in advance. Why deliberately ignore knowledge about the machine when designing the code, then come back and use that knowledge? Another objection is to the idea of "measure then improve". Imagine a delivery truck which loads parcels without checking their weight first, then drives the truck onto a weigh machine (profiling), then if the truck is overweight they unload each parcel, weigh them individually, find the one heavy one filled with lead weights, then repack the truck without it. That would be silly and inefficient, right? Now imagine they unload the truck and there's no single parcel which is surprisingly heavy and instead the goods have been packed with 'lead foam'. Who could forsee that would cause problems with the weight on the delivery truck? (Anyone!). Now what's the fix? Unpack and repack every parcel, rewrite the whole code. There's no accidentally quadratic here to remove, instead every tiny piece takes a few more microseconds than it needs to and those add up. Another objection is "YOU FOCUSED ON IT' - this implies that there is some way you can design and write code that doesn't need any focus. Part of the point of the video is that the faster code is not harder to write, there's no complex algorithms, no compiler intrinsics, no deep knowledge; it doesn't take a focused performance expert to write a switch(){} instead of a subclass. Another objection is your implication that performance shouldn't be a consideration until you measure it and find a problem, and prove that it is. Which is like saying that aeroplane design weight doesn't matter until after you build it and measure it and prove that it matters. Computers are finite and limited, why have we got to the stage of assuming they are infinite and unlimited, and then demanding proof that they aren't, over and over on a case-by-case basis? A 3D game can render a virtual world at 100 frames per second. Does a program which takes 3 seconds to show a username/password login prompt need enough resources for 300 frames of game until proven otherwise? Another objection is that you are defaulting to 'clean code is the default, performant code needs measuring and benchmarking to justify itself in every individual case. Why isn't that the other way around? Less resource-wasting code as the default, and 'clean code' only when maintainability has been measured and proved to be a problem, and only in the parts of the codebase which have the highest maintainability problems? If all the clean code, encapsulation, isolation, abstraction layers, are providing the developer benefits that are claimed - why aren't programs better? If it's now so clean and easy to refactor, why doesn't that translate to software that gets better instead of software that gets worse? Casey's example is that Visual Studio debugger updated the watch window in realtime while stepping through code, on single core Pentium 4 with 512MB RAM, and now on a modern multicore machine with 64GB RAM and an M2 SSD it can't do that. (RemedyBG can, so it's not impossible).

alerighi 1mo ago

I have in my basement a PC with Windows 98 that feels way faster using it than a modern Windows 11 full of vibecoded AI slop features.

NetMageSCW 1mo ago
Windows 11 isn’t full of vibe coded AI slop because that hasn’t existed long enough to affect it much. It is full of poor decisions and poor programming the old fashioned hand made way.

arendtio 1mo ago

Yes, even my 2013 Haswell-based Arch Linux KDE Desktop feels more responsive than my M4 MacBook. And I think the MacBook has so much more power under the hood, but somehow the animation settings or whatever are just not that good. To be completely fair, I use the Desktop via DisplayPort at 144 Hz, while the MacBook uses HDMI + USB-C, and I believe it's just at 60 Hz, which is also a factor, but I honestly think that this is not the primary reason.