5 ms·

Admittedly, I stopped reading just over half way, but the crux of the argument appeared to be that software should be fast, though I don't recall any justificat

Admittedly, I stopped reading just over half way, but the crux of the argument appeared to be that software should be fast, though I don't recall any justification for that philosophy other than suggesting that it is basically a truth. The article did acknowledge the counter point that in some cases the efficiency gains will never make up for the time spent chasing this efficiency, but it hand-waved that away without interacting with the argument. The other key trait of the article was cherry-picking data and over simplifying domains. Several times the article alluded to the emotional plea that "what could the software possibly be doing that takes up that time/space" (my paraphrase) but it didn't place any serious attempt to answer that question, using their lack of provided answer as if it were an indication of an invalid answer and comparing various bits of software that do not have feature parity looking as if their only practical difference were performance. (Edit: Updated wording of previous sentence to be more clear.) There's definitely alot to be said about how software could be more efficient as well as the social, environmental, and business costs of inefficiency, but there is also much to be said about how modern software empowers people that otherwise might not be able to write anything to write something "bad" that does what they need or to discuss how modern software developeres tend to aim to be "fast enough" in the way that an structural engineer would choose "strong enough." There's much rich debate to be had, but this article didn't include it, instead going for an emotional rant, and failing to engage with actual reason. There is, in my opinion, truth to parts of the argument, but the article made itself clear that it didn't want a discussion.

flohofwoe 3y ago
> to be that software should be fast, though I don't recall any justification for that philosophy other than suggesting that it is basically a truth The gist is that if your code takes just a couple of seconds to complete on your fancy M1 Mac, there will be a pretty big chunk of your potential audience who will have to wait for minutes (and there's that surprising character trait in many non-technical users that they simply accept such bullshit, because they don't know that performance could be drastically improved without them having to buy new hardware). But unless devs test their code also on low-end devices they will be completely oblivious to that problem. And the actual problem isn't even the technical aspects, but that some devs are getting awfully defensive when confronted with the ugly truth that their code is too slow and start arguing instead of sitting down with their product mangager and making time for some profiling and optimization sessions to see what can be done about the performance problems without having to start from scratch.
- throwawaysleep 3y ago
  What percentage of your target customers are going to have low end devices? And what is their estimated value compared to people who upgrade their tech (like most people with money would)? Is it a problem or are those people simply not worth serving?
  - sillysaurusx 3y ago
    Gamedev quantified this. The answer is: many more then you think. And sure, they’re not worth serving, as long as you’re not worth their money. Meanwhile a competitor will. Don’t be fooled by the browsers. Most products aren’t browsers. And if you don’t snap up the long tail, someone else will.
abhaynayar 3y ago
I didn't know how to put my thoughts about the article into words so decided not to, but thankfully this comment does it better than I could have. Really annoying how the author brings up counter points and comparisons but does not deeply engage with them, as if they're absolute truths and only rhetorical, when they're far from that.
- geodel 3y ago
  Huh, the author feels the pain with endless crappy and slow software. If you feel all his points either superficial or wrong you could easily come up with counter arguments better than author. But it seems all you are saying is I don't like it because I don't like it.
  - abhaynayar 3y ago
    > Huh, the author feels the pain with endless crappy and slow software. If that was all, it would've been fine... if he was only listing bugs and saying he's tired of crappy software. But he has framed the article in a way as if he's describing the "why" and how the problem can be solved. In fact I've been following the author and he has a place where he lists all bugs he finds in software, and that in my opinion is a great initiative, but this article just opens too many threads and tangents and only appears to explain the root cause. I could come up with a few examples like: - trying to compare cars, buildings, and planes with software and not diving deeper into how much different they are and why. - or saying everybody seems to be ok with inefficient software without diving deeper into why everyone's ok with it. - or mentioning a tweet about a guy who spent more time trying to make something faster than he will ever gain back without going further into if it's a good/bad thing and why. > If you feel all his points either superficial or wrong you could easily come up with counter arguments better than author. I never said his points were superficial or wrong, just that he does not deeply engage with the threads he opens up. For that reason, I have no counter arguments to come up with, since he is just complaining about his issues and also does not come up with a good solution as such. Of course everyone would like nicer software, that's not new. Why is software different than other industries in the first place? Is it worth improving it? What are the trade-offs? What is the effort required at scale? What would we lose if we made software more like manufacturing? What would we gain? If he knows a path forward, does he have a better way to express it than the last "manifesto" paragraph? Etc.
Xeamek 3y ago
>Admittedly, I stopped reading just over half way, but the crux of the argument appeared to be that software should be fast, though I don't recall any justification for that philosophy other than suggesting that it is basically a truth. But it is the truth, and all we have to do is simply look at software from the point of users. What device did You use to write this comment? Iphone4, or 14? What device do You use as your workstation, some pentium with 4gbs of ram? Heck, even going outside the software itself, but to related branch - What network did your device talked to servers? 5G/fiber counted in hundreds of Mbps or 2g counted in few kbs? At the end of the day, actions speak louder then words. And you can pretend all You want that "wanting faster software" is unproven axiom, but if the axiom is followed by literally all of society, it might as well be taken as truth. ...especially since it originates from the exact same place as the "developer time is worth more" one. Only difference is who's time we are saving
- developer93 3y ago
  Especially since there's 1 developer and thousands to millions of users..
- IggleSniggle 3y ago
  It's only truth because no great alternative is provided. My best devices are ones from the past. I gave them up only because software rendered them obsolete, not because I wanted the newer model. If half of society is speaking a new language AND an old language, it doesn't really matter if the old language is superior. You need to be able to speak the new dialect just to navigate society, even if the new language only exists as a mechanism to differentiate the new generation from the old.
- wredue 3y ago
  For the record - There is no evidence what-so-ever that “performance trades with developer time”. 99% of the time, reasonable performance is a skill issue, not a developer time issue. In actual fact, if you look at “clean abstractions” and other nonsense, you can see that higher developer time actually seems to equate to lower performance. As we all also know, the best indicator of bug count is lines of code, so adding in all these abstractions that adds lines of code not only make code slower, but also results in more bugs. That is to say, all current evidence points to the exact opposite of their claim: Higher dev time = lower performance and more bugs (assuming higher dev time is coming from trying to abstract)
cstrahan 3y ago
> Admittedly, I stopped reading just over half way, but the crux of the argument appeared to be that software should be fast, though I don't recall any justification for that philosophy other than suggesting that it is basically a truth. Are you suggesting that maybe users (including you and me) should have to put up with painfully slow, stuttering software? I don’t see why his claim requires any justification - to my mind, it should be just as self evident as the fact that inflicting physical pain upon others should be avoided. > […] modern software developeres tend to aim to be "fast enough" in the way that an structural engineer would choose "strong enough." But they don’t aim to make software fast enough. My experience last week: Windows 10 file Explorer took ~2.5 seconds to open. Close it and re-open it: same thing. Open it, right mouse click another folder to open a new Explorer window: same thing. Fresh install of Windows 10 on a top of the line workstation-type laptop with 64gb of RAM. Not all, but a frustratingly large proportion of modern software is dog shit slow. The reason doesn’t need to spelled out in the article: if the developers of these slow apps cared, they could figure it out. From my experience, it usually looks something like this: Some developer has an emotional attachment to Protocol Buffers, and will stop at nothing to see its adoption within the org. But their software is pretty heavily invested in JSON. So they rewrite the software to read the existing JSON files from disk (or REST web service response bodies, whatever), and reserialize them to protobuf in memory. Tada! Now we’re using protobufs, great. Of course, nothing meaningful was actually achieved here - they already had a perfectly fine, ready to use, deserialized, in-memory data structure before they added protobuf to the mix. Oh, and that plain struct in memory was faster than traversing a protobuf: the former had small substructures laid out in the same allocation as the parent, whereas substructures in protobuf involves multiple allocations and chasing pointers. Next step: realize that REST is lame, and gRPC is hip. But it’ll be practically impossible to rewrite everything from REST to gRPC, so they do the only reasonable thing: create proxies that sit between the client and server that translate REST requests/responses to/from gRPC! Now that we have that in place, we can add an additional proxy to the mix: Envoy. Envoy is a super popular layer 7 proxy, so it’s gotta be good. What functionality will be used? Any load balancing? RBAC policies? TLS termination? Nope. None of it. But because Envoy is “good”, adding it to the stack with no justification must also be intrinsically “good”, right? Right! (Edit: do you see how long winded and boring this example is? This is precisely why the author shouldn’t expound on the “why” - anyone involved in the development of needlessly slow software (who isn’t blind to the problem because they are part of it) can recount similar craziness. Adding this to their blog would make for boring reading, and distract from the aim of their article.) Buzzword/resume driven development, unwarranted layers of indirection (for no gain), absolution of responsibility via appeal to authority (if the top 10 software companies created and/or use some software, then surely we can blindly use that software too and enjoy the same success, despite not giving any consideration to whether it’s even remotely the right tool for the problem at hand), cargo culting, etc. The reason software is painfully slow usually boils down to lack of critical, rational thought: either out of laziness and/or deferral of responsibility, or because of some emotional attachment to some type of software component.
blitz_skull 3y ago
I liked the emotional rant. Sometimes data just obscures what you know to be true. I don't need data to tell me that I should try my best to make the best software, and that's what this article reminded me.
crabbone 3y ago
> how modern software empowers people that otherwise might not be able to write anything to write something "bad" What's so special in the modern software? How do you tell if software is modern? Few points to illustrate the difficulties with your descriptions: BASIC and SQL were meant to empower people ... to write something "bad" a very long time ago. So did Fortran, as well as some other languages / technologies that didn't survive to the present day. Python or Java can be called "conservative" if you are very generous, but, really, in truth, should be called "anachronistic" considering programming language development that happened in the 70. Languages like J or Prolog are conceptually a lot more advanced than Rust or Go, but have been created much earlier. Many languages are actually collections of languages that have been created over time, eg. C89 through C23 -- does this make C a modern language? Only the C23? Is there really that much of a difference between C89 and C23? Is there some other way to define modernity? I.e. not based on time of creation nor based on some imaginary evolutionary tree?
- JoshuaRogers 3y ago
  I’ll be honest here, time got away from me. I had Node and Python in mind simply having forgot how old Python was (And Node not exactly being the new guy anymore.) :p
koonsolo 3y ago
There is one paragraph at the start where I thought "yep, the author just answered his own question here": Only in software, it’s fine if a program runs at 1% or even 0.01% of the possible performance. Everybody just seems to be ok with it. So yeah, everybody is ok with it. Move on.
- majewsky 3y ago
  This thread is ample evidence that not everybody is ok with it. Also, note that "being ok with it" and "seeming to be ok with it" are two extremely different things.
  - koonsolo 3y ago
    I'll leave you with this link, the top IDE index: https://pypl.github.io/IDE.html https://pypl.github.io/IDE.html Surely you can see that this top list is optimized for features, not for speed. So yeah, people can complain here on HN all they want, in the end the 'evidence' of which software is preferred is pretty clear, even in the programmer demographic.
    - majewsky 3y ago
      Going by number of search queries is such an obviously flawed assessment method. These results could just as well mean that the users of VS Code experience the most problems with their IDE and thus need to search for answers more often. I don't know when I last searched for Vim on a search engine; stuff just works for me. :)

flohofwoe 3y ago

> to be that software should be fast, though I don't recall any justification for that philosophy other than suggesting that it is basically a truth The gist is that if your code takes just a couple of seconds to complete on your fancy M1 Mac, there will be a pretty big chunk of your potential audience who will have to wait for minutes (and there's that surprising character trait in many non-technical users that they simply accept such bullshit, because they don't know that performance could be drastically improved without them having to buy new hardware). But unless devs test their code also on low-end devices they will be completely oblivious to that problem. And the actual problem isn't even the technical aspects, but that some devs are getting awfully defensive when confronted with the ugly truth that their code is too slow and start arguing instead of sitting down with their product mangager and making time for some profiling and optimization sessions to see what can be done about the performance problems without having to start from scratch.

throwawaysleep 3y ago
What percentage of your target customers are going to have low end devices? And what is their estimated value compared to people who upgrade their tech (like most people with money would)? Is it a problem or are those people simply not worth serving?
- sillysaurusx 3y ago
  Gamedev quantified this. The answer is: many more then you think. And sure, they’re not worth serving, as long as you’re not worth their money. Meanwhile a competitor will. Don’t be fooled by the browsers. Most products aren’t browsers. And if you don’t snap up the long tail, someone else will.

abhaynayar 3y ago

I didn't know how to put my thoughts about the article into words so decided not to, but thankfully this comment does it better than I could have. Really annoying how the author brings up counter points and comparisons but does not deeply engage with them, as if they're absolute truths and only rhetorical, when they're far from that.

geodel 3y ago
Huh, the author feels the pain with endless crappy and slow software. If you feel all his points either superficial or wrong you could easily come up with counter arguments better than author. But it seems all you are saying is I don't like it because I don't like it.
- abhaynayar 3y ago
  > Huh, the author feels the pain with endless crappy and slow software. If that was all, it would've been fine... if he was only listing bugs and saying he's tired of crappy software. But he has framed the article in a way as if he's describing the "why" and how the problem can be solved. In fact I've been following the author and he has a place where he lists all bugs he finds in software, and that in my opinion is a great initiative, but this article just opens too many threads and tangents and only appears to explain the root cause. I could come up with a few examples like: - trying to compare cars, buildings, and planes with software and not diving deeper into how much different they are and why. - or saying everybody seems to be ok with inefficient software without diving deeper into why everyone's ok with it. - or mentioning a tweet about a guy who spent more time trying to make something faster than he will ever gain back without going further into if it's a good/bad thing and why. > If you feel all his points either superficial or wrong you could easily come up with counter arguments better than author. I never said his points were superficial or wrong, just that he does not deeply engage with the threads he opens up. For that reason, I have no counter arguments to come up with, since he is just complaining about his issues and also does not come up with a good solution as such. Of course everyone would like nicer software, that's not new. Why is software different than other industries in the first place? Is it worth improving it? What are the trade-offs? What is the effort required at scale? What would we lose if we made software more like manufacturing? What would we gain? If he knows a path forward, does he have a better way to express it than the last "manifesto" paragraph? Etc.

Xeamek 3y ago

>Admittedly, I stopped reading just over half way, but the crux of the argument appeared to be that software should be fast, though I don't recall any justification for that philosophy other than suggesting that it is basically a truth. But it is the truth, and all we have to do is simply look at software from the point of users. What device did You use to write this comment? Iphone4, or 14? What device do You use as your workstation, some pentium with 4gbs of ram? Heck, even going outside the software itself, but to related branch - What network did your device talked to servers? 5G/fiber counted in hundreds of Mbps or 2g counted in few kbs? At the end of the day, actions speak louder then words. And you can pretend all You want that "wanting faster software" is unproven axiom, but if the axiom is followed by literally all of society, it might as well be taken as truth. ...especially since it originates from the exact same place as the "developer time is worth more" one. Only difference is who's time we are saving

developer93 3y ago
Especially since there's 1 developer and thousands to millions of users..
IggleSniggle 3y ago
It's only truth because no great alternative is provided. My best devices are ones from the past. I gave them up only because software rendered them obsolete, not because I wanted the newer model. If half of society is speaking a new language AND an old language, it doesn't really matter if the old language is superior. You need to be able to speak the new dialect just to navigate society, even if the new language only exists as a mechanism to differentiate the new generation from the old.
wredue 3y ago
For the record - There is no evidence what-so-ever that “performance trades with developer time”. 99% of the time, reasonable performance is a skill issue, not a developer time issue. In actual fact, if you look at “clean abstractions” and other nonsense, you can see that higher developer time actually seems to equate to lower performance. As we all also know, the best indicator of bug count is lines of code, so adding in all these abstractions that adds lines of code not only make code slower, but also results in more bugs. That is to say, all current evidence points to the exact opposite of their claim: Higher dev time = lower performance and more bugs (assuming higher dev time is coming from trying to abstract)

cstrahan 3y ago

> Admittedly, I stopped reading just over half way, but the crux of the argument appeared to be that software should be fast, though I don't recall any justification for that philosophy other than suggesting that it is basically a truth. Are you suggesting that maybe users (including you and me) should have to put up with painfully slow, stuttering software? I don’t see why his claim requires any justification - to my mind, it should be just as self evident as the fact that inflicting physical pain upon others should be avoided. > […] modern software developeres tend to aim to be "fast enough" in the way that an structural engineer would choose "strong enough." But they don’t aim to make software fast enough. My experience last week: Windows 10 file Explorer took ~2.5 seconds to open. Close it and re-open it: same thing. Open it, right mouse click another folder to open a new Explorer window: same thing. Fresh install of Windows 10 on a top of the line workstation-type laptop with 64gb of RAM. Not all, but a frustratingly large proportion of modern software is dog shit slow. The reason doesn’t need to spelled out in the article: if the developers of these slow apps cared, they could figure it out. From my experience, it usually looks something like this: Some developer has an emotional attachment to Protocol Buffers, and will stop at nothing to see its adoption within the org. But their software is pretty heavily invested in JSON. So they rewrite the software to read the existing JSON files from disk (or REST web service response bodies, whatever), and reserialize them to protobuf in memory. Tada! Now we’re using protobufs, great. Of course, nothing meaningful was actually achieved here - they already had a perfectly fine, ready to use, deserialized, in-memory data structure before they added protobuf to the mix. Oh, and that plain struct in memory was faster than traversing a protobuf: the former had small substructures laid out in the same allocation as the parent, whereas substructures in protobuf involves multiple allocations and chasing pointers. Next step: realize that REST is lame, and gRPC is hip. But it’ll be practically impossible to rewrite everything from REST to gRPC, so they do the only reasonable thing: create proxies that sit between the client and server that translate REST requests/responses to/from gRPC! Now that we have that in place, we can add an additional proxy to the mix: Envoy. Envoy is a super popular layer 7 proxy, so it’s gotta be good. What functionality will be used? Any load balancing? RBAC policies? TLS termination? Nope. None of it. But because Envoy is “good”, adding it to the stack with no justification must also be intrinsically “good”, right? Right! (Edit: do you see how long winded and boring this example is? This is precisely why the author shouldn’t expound on the “why” - anyone involved in the development of needlessly slow software (who isn’t blind to the problem because they are part of it) can recount similar craziness. Adding this to their blog would make for boring reading, and distract from the aim of their article.) Buzzword/resume driven development, unwarranted layers of indirection (for no gain), absolution of responsibility via appeal to authority (if the top 10 software companies created and/or use some software, then surely we can blindly use that software too and enjoy the same success, despite not giving any consideration to whether it’s even remotely the right tool for the problem at hand), cargo culting, etc. The reason software is painfully slow usually boils down to lack of critical, rational thought: either out of laziness and/or deferral of responsibility, or because of some emotional attachment to some type of software component.

blitz_skull 3y ago

I liked the emotional rant. Sometimes data just obscures what you know to be true. I don't need data to tell me that I should try my best to make the best software, and that's what this article reminded me.

crabbone 3y ago

> how modern software empowers people that otherwise might not be able to write anything to write something "bad" What's so special in the modern software? How do you tell if software is modern? Few points to illustrate the difficulties with your descriptions: BASIC and SQL were meant to empower people ... to write something "bad" a very long time ago. So did Fortran, as well as some other languages / technologies that didn't survive to the present day. Python or Java can be called "conservative" if you are very generous, but, really, in truth, should be called "anachronistic" considering programming language development that happened in the 70. Languages like J or Prolog are conceptually a lot more advanced than Rust or Go, but have been created much earlier. Many languages are actually collections of languages that have been created over time, eg. C89 through C23 -- does this make C a modern language? Only the C23? Is there really that much of a difference between C89 and C23? Is there some other way to define modernity? I.e. not based on time of creation nor based on some imaginary evolutionary tree?

JoshuaRogers 3y ago
I’ll be honest here, time got away from me. I had Node and Python in mind simply having forgot how old Python was (And Node not exactly being the new guy anymore.) :p

koonsolo 3y ago

There is one paragraph at the start where I thought "yep, the author just answered his own question here": Only in software, it’s fine if a program runs at 1% or even 0.01% of the possible performance. Everybody just seems to be ok with it. So yeah, everybody is ok with it. Move on.

majewsky 3y ago
This thread is ample evidence that not everybody is ok with it. Also, note that "being ok with it" and "seeming to be ok with it" are two extremely different things.
- koonsolo 3y ago
  I'll leave you with this link, the top IDE index: https://pypl.github.io/IDE.html https://pypl.github.io/IDE.html Surely you can see that this top list is optimized for features, not for speed. So yeah, people can complain here on HN all they want, in the end the 'evidence' of which software is preferred is pretty clear, even in the programmer demographic.
  - majewsky 3y ago
    Going by number of search queries is such an obviously flawed assessment method. These results could just as well mean that the users of VS Code experience the most problems with their IDE and thus need to search for answers more often. I don't know when I last searched for Vim on a search engine; stuff just works for me. :)