3 ms·

This attitude is very common and has clearly degraded software development particularly for users, and like most issues afflicting modern software it's not perc

This attitude is very common and has clearly degraded software development particularly for users, and like most issues afflicting modern software it's not perceived by developers so it "doesn't exist" to them. As the top reply to this mentioned, anyone can easily tell how much slower software is today even when computers and devices are so fast now! All in the name of "making code easy to reason about." I have news for you, all code is difficult to reason about at some level. Sure, certain abstracts can be easier to reason about than others if you take certain examples that I can generally argue are reductionist, but any reasonably well developed piece of code (read, actual useful code) will require a certain level of sophistication and complexity that will eventually make it difficult to reason about. I know this is a reach and a bit of a red-herring, but developers really really need to remember the allergy to "code being difficult to reason about" is a sometimes a useful intuition or heuristic to use, the heuristic being "easier to reason about is better," but it really is a heuristic at the end of the day. Abuse of this heuristic is often a motive behind all sorts of detrimental behaviors in tech, reinventing the wheel and NIH (I didn't write, it, so it's difficult to reason about!), rewrites from scratch (our "technical debt" is now hard to reason about, let's rewrite from scratch!) and the problem OP refers to (a solution that maps to the machine better is hard to reason about, let's use this less efficient solution instead!). And a big problem here is that these issues are often not issues to hackers because it just means more programming for them which they love! It just hurts users and customers.

8fGTBjZxBcHq 6y ago
I think other users in here are more on the right track about where the blame for this lies. As you alluded to, a lot of programmers are happy to tweak and refine for ages so it's probably not that. Is it just that programmers are lazy or need to care more or be better educated about optimization? Honestly I really doubt it. I fully agree with the other takes that companies have incentives to ship working software quickly. Features sell subscriptions not performance. If it comes down to choosing between functionality and performance leaders will ship the slow feature every time. I'm not even sure they're necessarily wrong most of the time. If you know where to look the internet is a graveyard of carefully engineered products that were beat to market and obliterated by three people with a shitty electron app.
- noobermin 6y ago
  You're probably right honestly that bean counters are mostly to blame. I will say the attitude of being afraid of difficult code is a problem in modern IT (IT of any generation really) and doesn't help but companies not caring about users being the primary cause of bad, unperformat code is the correct take. Conversely then, the handwaving of the OP comment is wrong too, so if we limit the discussion of what one ought to do, I still stand by my point.
reader_mode 6y ago
>As the top reply to this mentioned, anyone can easily tell how much slower software is today even when computers and devices are so fast now! All in the name of "making code easy to reason about." Yeah - it also doesn't crash my PC when an app segfaults, hell even video driver failing these days won't bring my system down. I don't need to restart my PC when I plug in a device. That's not really compatible with your childhood DOS games that enter kernel mode and talk to HW directly - you pay for abstractions - and it's a good tradeoff. I can also have files with more than 5 character file names, and my FS can revert file changes and create snapshots. These "good old days" people are just unrealistic, VIM is fast even today - but I prefer having a graphical representation of file tree with fancy icons and search. But that's just me and 99% of people out there. Performance is a feature - and it's not a feature most people rank high untill it becomes an issue. As much as a minority of people here are crying about electron and HTML - a huge number of developers use VSCode daily and enjoy the approachability of a JS/DOM plugin ecosystem. VIM is free and available for decades now, and it has such amazing UX that the one of the most upvoted questions on SO was how to exit from it... Slack is dog slow - and IRC has been freely available for decades, most people here use Slack daily. Who uses IRC anymore ? So keep using your Emacs integrated window manager and stop bothering the rest of us :D
- noobermin 6y ago
  My point really isn't about luddite vs. anti-luddite, I'm talking about performance and how it affects users. Also, you're right that less performant or less elegant tools win out sometimes (like the good old mac vs windows debates before macos and apple in general made a come back) and that is due to a variety of reasons. That's fine, life is complicated and many factors affect who wins in life, it doesn't mean we can't still ask for better things though. Still I don't know what bearing of all this has on the point I made above.

8fGTBjZxBcHq 6y ago

I think other users in here are more on the right track about where the blame for this lies. As you alluded to, a lot of programmers are happy to tweak and refine for ages so it's probably not that. Is it just that programmers are lazy or need to care more or be better educated about optimization? Honestly I really doubt it. I fully agree with the other takes that companies have incentives to ship working software quickly. Features sell subscriptions not performance. If it comes down to choosing between functionality and performance leaders will ship the slow feature every time. I'm not even sure they're necessarily wrong most of the time. If you know where to look the internet is a graveyard of carefully engineered products that were beat to market and obliterated by three people with a shitty electron app.

noobermin 6y ago
You're probably right honestly that bean counters are mostly to blame. I will say the attitude of being afraid of difficult code is a problem in modern IT (IT of any generation really) and doesn't help but companies not caring about users being the primary cause of bad, unperformat code is the correct take. Conversely then, the handwaving of the OP comment is wrong too, so if we limit the discussion of what one ought to do, I still stand by my point.

reader_mode 6y ago

>As the top reply to this mentioned, anyone can easily tell how much slower software is today even when computers and devices are so fast now! All in the name of "making code easy to reason about." Yeah - it also doesn't crash my PC when an app segfaults, hell even video driver failing these days won't bring my system down. I don't need to restart my PC when I plug in a device. That's not really compatible with your childhood DOS games that enter kernel mode and talk to HW directly - you pay for abstractions - and it's a good tradeoff. I can also have files with more than 5 character file names, and my FS can revert file changes and create snapshots. These "good old days" people are just unrealistic, VIM is fast even today - but I prefer having a graphical representation of file tree with fancy icons and search. But that's just me and 99% of people out there. Performance is a feature - and it's not a feature most people rank high untill it becomes an issue. As much as a minority of people here are crying about electron and HTML - a huge number of developers use VSCode daily and enjoy the approachability of a JS/DOM plugin ecosystem. VIM is free and available for decades now, and it has such amazing UX that the one of the most upvoted questions on SO was how to exit from it... Slack is dog slow - and IRC has been freely available for decades, most people here use Slack daily. Who uses IRC anymore ? So keep using your Emacs integrated window manager and stop bothering the rest of us :D

noobermin 6y ago
My point really isn't about luddite vs. anti-luddite, I'm talking about performance and how it affects users. Also, you're right that less performant or less elegant tools win out sometimes (like the good old mac vs windows debates before macos and apple in general made a come back) and that is due to a variety of reasons. That's fine, life is complicated and many factors affect who wins in life, it doesn't mean we can't still ask for better things though. Still I don't know what bearing of all this has on the point I made above.