4 ms·

I'm normally a fan of Dan Luu's posts but I felt this one missed the mark. The LCP/CPU table is a good one, but from there the article turns into a bit on armch

I'm normally a fan of Dan Luu's posts but I felt this one missed the mark. The LCP/CPU table is a good one, but from there the article turns into a bit on armchair psychology. From some random comments coming from Discourse's founder, readers are asked to build up an idea of what attitudes software engineers supposedly have. Even Knuth gets dragged into the mud based on comments he made about single vs multi-core performance and comments about the Itanium (which is a long standing point of academic contention.) This article just felt too soft, too couched in internet fights, to really stand up.

troupo 3y ago
> readers are asked to build up an idea of what attitudes software engineers supposedly have. But they do, don't they. Discourse's founder's words are just very illustrative. Have you used the web recently? I have. It's bloated beyond any imagination to the point that Google now says that 2.4 seconds to Largest Contentful Paint is fast now: https://blog.chromium.org/2020/05/the-science-behind-web-vitals.html https://blog.chromium.org/2020/05/the-science-behind-web-vit... (this is from 4 years ago, it's probably worse now). You don't have to go far to see either Youtube loading 2.5 megabytes of CSS on desktop to the founder of Vercel boasting its super fast sites that take 20 seconds to load the moment you throttle it just a tiny bit: https://x.com/dmitriid/status/1735338533303259571 https://x.com/dmitriid/status/1735338533303259571
- Karrot_Kream 3y ago
  You're making the same mistake the post did. It depends on the reader already having sympathy for the idea that bloat is bad in order to make its case. I can read nerd site comments all day that lament bloat. For an article to stand on its own on this point it has to make the case to people who don't already believe this. Dan's articles have usually been very good at that. The keyboard latency one for example makes few assumptions and mostly relies on data to tell its story. My point is that this article is different. It's an elevated rant. It relies on an audience that already agrees to land its point, hence my criticism that it's too couched in internet fights.
  - B56b 3y ago
    I think the article makes a pretty good case for bloat being bad for low-end users actually. His analysis demonstrates how many websites become genuinely unusable on cheaper devices, not just to techie standards, but for anyone trying to actually interact with the page at all.
  - liveoneggs 3y ago
    State your case that bloat is good. I currently have a client who will do literally anything except delete a single javascript library so I'd like to understand them better.
    - jodrellblank 3y ago
      Joel Spolsky on Excel bloat, 2001: https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv-bloatware-and-the-8020-myth/ https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...
      - jiggawatts 3y ago
        The latest version of Excel loads faster on my laptop than most websites do. I’ve timed this. I can load the entire MS Office suite and open a Visual Studio 2022 project in less time then it takes to open a blank Jira web form. What’s your point?
        jodrellblank 3y ago
        My point is to reply to "State your case that bloat is good" with a famous blog stating a case that bloat is good. Bloat makes the company more money by allowing them to develop and ship faster, bloat makes the company more money by being able to offer more features to more customers (including the advertisers and marketers and etc. side of things), and - well, read the article. I, too, dislike slow websites and web apps, but I don't think they are some mystery - natural selection isn't selecting for idiot developers, market selection is selecting for tickbox features and with first-mover-advantage they are selecting against "fast but not available for another year and has fewer features and cost more to develop".
- bitwize 3y ago
  Usually the directive "don't worry about bloat" comes from above, or outside, the software engineering team. I'm a software engineer and I would love to fix performance problems so that everything runs Amiga smooth. But that takes time and effort to find, analyze, and fix performance issues... and once The Business sees something in more or less working order, implementing the next feature takes priority over removing bloat. "Premature optimization is the root of all evil" and that. I know that's not what Knuth meant, he meant don't be penny-wise and pound-foolish when you do optimize. But much like "GO TO considered harmful", something approaching the stupidest possible interpretation of the maxim has become the canonical interpretation. And that's before getting into when The Business wants that sweet, sweet analytics data, or those sweet, sweet ad dollars.
goalieca 3y ago
> what attitudes software engineers supposedly have I don’t think I’ve ever seen a company take performance seriously. No one scoffs when a simple API service for frontend has 500ms response time! How many engineers even know or care how much their cloud bill is?
- nolist_policy 3y ago
  I'm sure Google invests a lot of resources in making Google Search load fast. AFAIK they serve a specialized version for each user agent out there.
  - maigret 3y ago
    One the best counter examples to the rule. I tried running Lighthouse on a few Google services that are less prominent and had a few good laughs.
yawaramin 3y ago
> ...which is a long standing point of academic contention. What contention? If anything, Luu is being rather generous–Knuth was just whining that the decades-long free lunch program was being cancelled.
- moonchild 3y ago
  VLIW (Itanium is a VLIW arch) is what's contentious, not multiprocessing.
  - deleted 3y ago
    [deleted]
  - yawaramin 3y ago
    OK I missed that. Thanks. But it looks like Itanium was only tangential to this discussion, in that Knuth thinks multicore programming may be an even worse mistake than Itanium.
ksec 3y ago
I thought he summarised it pretty well. Jeff Atwood was only picked as example. But there are LOTS of high profile, huge followers web developments thought leaders constantly pump out similar views. And a lot of their followers just blindly accept what they were told.
torginus 3y ago
Knuth is kinda right imo - parallelism as we have it now is unused by 90% of software outside of specialist use cases and running the same single-threaded program on multiple data items. Programming languages and hardware both offer poor support for fine-grained parallelism and it's very hard to speed up classical software using parallel approaches.
- acdha 3y ago
  This felt more true a decade ago but there’s been a lot of improvement in both languages (e.g. Rust) and libraries - I routinely see most of the cores on my Macs fully loaded for things like working with media files which used to be single-threaded.
  - Karrot_Kream 3y ago
    Languages are getting there but based on how much heartburn Rust's async causes, I still find it to be a very hard problem to give programmers a real multicore abstraction. And it starts from the ground up with operating systems designed around single core ideas. When I first read about the multi core vs single core debate in college, I thought it was silly and that multi core would be just fine. But over the years I've developed a more nuanced view. The average user is mostly doing things that involve IO, so that makes multi core useful in that you can use multiple cores to wait for IO, but for actual computation single core performance continues to be the bottleneck.
    - acdha 3y ago
      async isn’t the only option: threading scales well and is often much easier to write and make production-ready (e.g. reasoning about peak memory usage can be hard in an async model).

troupo 3y ago

> readers are asked to build up an idea of what attitudes software engineers supposedly have. But they do, don't they. Discourse's founder's words are just very illustrative. Have you used the web recently? I have. It's bloated beyond any imagination to the point that Google now says that 2.4 seconds to Largest Contentful Paint is fast now: https://blog.chromium.org/2020/05/the-science-behind-web-vitals.html https://blog.chromium.org/2020/05/the-science-behind-web-vit... (this is from 4 years ago, it's probably worse now). You don't have to go far to see either Youtube loading 2.5 megabytes of CSS on desktop to the founder of Vercel boasting its super fast sites that take 20 seconds to load the moment you throttle it just a tiny bit: https://x.com/dmitriid/status/1735338533303259571 https://x.com/dmitriid/status/1735338533303259571

Karrot_Kream 3y ago
You're making the same mistake the post did. It depends on the reader already having sympathy for the idea that bloat is bad in order to make its case. I can read nerd site comments all day that lament bloat. For an article to stand on its own on this point it has to make the case to people who don't already believe this. Dan's articles have usually been very good at that. The keyboard latency one for example makes few assumptions and mostly relies on data to tell its story. My point is that this article is different. It's an elevated rant. It relies on an audience that already agrees to land its point, hence my criticism that it's too couched in internet fights.
- B56b 3y ago
  I think the article makes a pretty good case for bloat being bad for low-end users actually. His analysis demonstrates how many websites become genuinely unusable on cheaper devices, not just to techie standards, but for anyone trying to actually interact with the page at all.
- liveoneggs 3y ago
  State your case that bloat is good. I currently have a client who will do literally anything except delete a single javascript library so I'd like to understand them better.
  - jodrellblank 3y ago
    Joel Spolsky on Excel bloat, 2001: https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv-bloatware-and-the-8020-myth/ https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...
    - jiggawatts 3y ago
      The latest version of Excel loads faster on my laptop than most websites do. I’ve timed this. I can load the entire MS Office suite and open a Visual Studio 2022 project in less time then it takes to open a blank Jira web form. What’s your point?
      - jodrellblank 3y ago
        My point is to reply to "State your case that bloat is good" with a famous blog stating a case that bloat is good. Bloat makes the company more money by allowing them to develop and ship faster, bloat makes the company more money by being able to offer more features to more customers (including the advertisers and marketers and etc. side of things), and - well, read the article. I, too, dislike slow websites and web apps, but I don't think they are some mystery - natural selection isn't selecting for idiot developers, market selection is selecting for tickbox features and with first-mover-advantage they are selecting against "fast but not available for another year and has fewer features and cost more to develop".
bitwize 3y ago
Usually the directive "don't worry about bloat" comes from above, or outside, the software engineering team. I'm a software engineer and I would love to fix performance problems so that everything runs Amiga smooth. But that takes time and effort to find, analyze, and fix performance issues... and once The Business sees something in more or less working order, implementing the next feature takes priority over removing bloat. "Premature optimization is the root of all evil" and that. I know that's not what Knuth meant, he meant don't be penny-wise and pound-foolish when you do optimize. But much like "GO TO considered harmful", something approaching the stupidest possible interpretation of the maxim has become the canonical interpretation. And that's before getting into when The Business wants that sweet, sweet analytics data, or those sweet, sweet ad dollars.

goalieca 3y ago

> what attitudes software engineers supposedly have I don’t think I’ve ever seen a company take performance seriously. No one scoffs when a simple API service for frontend has 500ms response time! How many engineers even know or care how much their cloud bill is?

nolist_policy 3y ago
I'm sure Google invests a lot of resources in making Google Search load fast. AFAIK they serve a specialized version for each user agent out there.
- maigret 3y ago
  One the best counter examples to the rule. I tried running Lighthouse on a few Google services that are less prominent and had a few good laughs.

yawaramin 3y ago

> ...which is a long standing point of academic contention. What contention? If anything, Luu is being rather generous–Knuth was just whining that the decades-long free lunch program was being cancelled.

moonchild 3y ago
VLIW (Itanium is a VLIW arch) is what's contentious, not multiprocessing.
- deleted 3y ago
  [deleted]
- yawaramin 3y ago
  OK I missed that. Thanks. But it looks like Itanium was only tangential to this discussion, in that Knuth thinks multicore programming may be an even worse mistake than Itanium.

ksec 3y ago

I thought he summarised it pretty well. Jeff Atwood was only picked as example. But there are LOTS of high profile, huge followers web developments thought leaders constantly pump out similar views. And a lot of their followers just blindly accept what they were told.

torginus 3y ago

Knuth is kinda right imo - parallelism as we have it now is unused by 90% of software outside of specialist use cases and running the same single-threaded program on multiple data items. Programming languages and hardware both offer poor support for fine-grained parallelism and it's very hard to speed up classical software using parallel approaches.

acdha 3y ago
This felt more true a decade ago but there’s been a lot of improvement in both languages (e.g. Rust) and libraries - I routinely see most of the cores on my Macs fully loaded for things like working with media files which used to be single-threaded.
- Karrot_Kream 3y ago
  Languages are getting there but based on how much heartburn Rust's async causes, I still find it to be a very hard problem to give programmers a real multicore abstraction. And it starts from the ground up with operating systems designed around single core ideas. When I first read about the multi core vs single core debate in college, I thought it was silly and that multi core would be just fine. But over the years I've developed a more nuanced view. The average user is mostly doing things that involve IO, so that makes multi core useful in that you can use multiple cores to wait for IO, but for actual computation single core performance continues to be the bottleneck.
  - acdha 3y ago
    async isn’t the only option: threading scales well and is often much easier to write and make production-ready (e.g. reasoning about peak memory usage can be hard in an async model).