4 ms·

I don't really buy the core premise that "Enhanced user convenience and functionality supposedly justify the increased size of software, but a closer look revea

I don't really buy the core premise that "Enhanced user convenience and functionality supposedly justify the increased size of software, but a closer look reveals these justifications to be shaky". Users can still choose to use vi, or emacs, or textpad, or whatever stripped-down, fast, minimalist software they prefer; the old stuff hasn't gone away. Meanwhile, my IDE re-compiles/re-parses my program as I type, and tells me immediately if there are errors. I choose to use the bigger, "slower" program because it makes me dramatically more productive. Sure, input latency might not be as good as a barebones editor, but that cost more than pays for itself (as always, for me -- YMMV). I can appreciate the aesthetic desire for a lean, minimal program, but to ignore the very real productivity benefits that come from tolerating larger programs is, I think, myopic. This comes up around here a lot in the context of slow web pages; a very important thing to note that I think is often overlooked is that it's not just the user's productivity that matters. If developers have to spend 2x the time optimizing their code to fit in a limited memory allocation, then that's 2x the cost to the consumer for the same amount of features (or 1/2 the features for the same price). If speed/performance is a feature that your customers want to pay for, they will let you know. If it's not, then your competitor will eat your lunch by building more features that users actually care about, while you optimize your existing feature-set. Programs are bounded by "feels slow" on one side, and "expensive to optimize further" on the other. If 99.9% of your users (i.e. the lay users, excluding the experts in the HN crowd) don't perceive your program/page to be slow, why would you optimize further? Sure, if you're Google, a few ms faster can equate to millions of dollars of revenue, but that's not the fitness landscape that most software evolves in.

minimuffins 6y ago
> "If speed/performance is a feature that your customers want to pay for, they will let you know. If it's not, then your competitor will eat your lunch" This doesn't really disagree with the argument from the piece. You could summarize this line of thinking this way: The pressures at work in the software market drive us to create slower and slower software. It seems like everyone actually agrees on that point. The only real disagreement seems to be how to respond to the fact. It's either, "Well shucks, that's just the way it is. At least I have auto-complete" or a feeling that, despite the pressures to just bloat and expand and slow down forever, it would be nice if we tried to combat it.
- theptip 6y ago
  I think that's a fair comment. My counterargument would be that if the new way of building software proposed in the OP was actually a significant improvement, someone would have built a new IDE with it, and eaten JetBrains' lunch. Instead, we got Atom; prioritizing pluggability/extensibility/hackability over footprint/latency. To be clear, I'm not arguing for a fatalistic position that "there's nothing we can do about it". We can, and do, optimize performance when required. I'm just arguing for a more nuanced appreciation of the cost/benefit calculation that's at play here. Either there's an explicit cost/benefit being done (e.g. a PM weighs the "go faster" story vs. the "add new widget" story) or an implicit one (app #1 prioritizes speed, app #2 prioritizes features, and customers vote with their dollars; market share reveals which is more valuable).
  - pjmlp 6y ago
    It is not possible to eat JetBrains and other's lunch, when only a subset of current generation is willing to pay for their tools, that is how Atom and Electron based GUIs get born.
ramzyo 6y ago
Thanks for your comment, as a VIM user who often turns up my nose at “slow” IDEs it helped me to understand a perspective that I would otherwise ignore, and reminded me that ultimately it’s what works for the individual that matters over any dogmatism that I may have. To offer an alternative perspective on this bit, > If 99.9% of your users (i.e. the lay users, excluding the experts in the HN crowd) don't perceive your program/page to be slow, why would you optimize further? For me personally as a practitioner of software engineering; because I can, and it’s meaningful to me to optimize in the broader context of designing and implementing a system, in part to see what’s possible in addition to the personal enjoyment of going through the process. That being said, for a company focusing on optimizing value to customers as a function of engineering resource allocation, I agree that it doesn’t make sense to optimize. You summed it up nicely with “...but that’s not the fitness landscape that most software evolves in.”
- cxr 6y ago
  > Thanks for your comment, as a VIM user who often turns up my nose at “slow” IDEs Note that the mention of Vim by the original commenter is a red herring arising out of lack of familiarity with Wirth. In Wirth's eyes, even Vim would appear monstrous. To appreciate Wirth's point requires realizing that his frame of reference is the Oberon (eco)system, which includes an OS, a mouse-driven graphical shell, a compiler, and the underlying CPU in an HDL all in a few tens of thousands of lines of code.
wtetzner 6y ago
> If 99.9% of your users (i.e. the lay users, excluding the experts in the HN crowd) don't perceive your program/page to be slow, why would you optimize further? And how do you know if they perceive it to be slow? I suspect that if you did optimize it to be faster (e.g. lower latency interactions), they would notice the improvement, even if they weren't sure why it "felt" better. > If speed/performance is a feature that your customers want to pay for, they will let you know. I don't buy that. Customers often don't even know it's a possibility that their software could be faster. In my experience, often lay users don't think of individual programs as being fast or slow. They either assume the "internet" is being slow, or their computer is slow. However, I think they do notice when performance is better. They say it "works better" or "feels more reliable", but they don't necessarily know why.
- jayd16 6y ago
  After a threshold the business value drops off substantially. How often does a consumer pick between competitors and choose based on speed? I would assume that's vastly in the minority. You see some shakeups here and there. A large push to a new browser once a decade, etc. but features are king most of the time.
  - wtetzner 6y ago
    > After a threshold the business value drops off substantially. Sure, but I don't see any reason better tools couldn't get us closer. Instead of starting out with languages and tools that will almost guarantee slow software, maybe we work on designing languages that provide productivity while at the same time encouraging leaner software. I don't disagree that overall the environment software is developed in doesn't encourage lean software. But I do think it's worthwhile to see if there are ways to improve the situation. Also, faster software can often provide opportunities for new features that weren't possible before. For example, something that used to be a batch or background process can now become a real-time feature. That is something that customers likely would find useful.
    - theptip 6y ago
loup-vaillant 6y ago
https://www.youtube.com/watch?v=k8gIJOy0c2g https://www.youtube.com/watch?v=k8gIJOy0c2g It's not just developer writing a program for one user. It's a very small number of developers writing programs for many many users (unless you make custom software). The impact of what devs do is multiplied by the number of users. That includes the negative impacts of being slow or requiring more resources than necessary. Imagine Photoshop users having to buy more RAM not just because it is needed by some functionality, but because that functionality used more RAM than was actually necessary. The sheer waste, in money, carbon footprint, and pollution... Granted, optimising takes time. Time that would be taken to write features. There's a tradeoff there. But we should keep the competition in mind here: there's a difference between a feature being unavailable because you spent time optimizing, and a feature being available elsewhere instead. While it make sense for Photoshop devs to push features as fast as they can, it doesn't to users any good if Krita already offers those features. (I'm ignoring incompatibility here, but you get the idea.) The incentives are all wrong in my opinion. We should have fast, lean, correct programs to work with. They just don't happen in the current economic system.

minimuffins 6y ago

> "If speed/performance is a feature that your customers want to pay for, they will let you know. If it's not, then your competitor will eat your lunch" This doesn't really disagree with the argument from the piece. You could summarize this line of thinking this way: The pressures at work in the software market drive us to create slower and slower software. It seems like everyone actually agrees on that point. The only real disagreement seems to be how to respond to the fact. It's either, "Well shucks, that's just the way it is. At least I have auto-complete" or a feeling that, despite the pressures to just bloat and expand and slow down forever, it would be nice if we tried to combat it.

theptip 6y ago
I think that's a fair comment. My counterargument would be that if the new way of building software proposed in the OP was actually a significant improvement, someone would have built a new IDE with it, and eaten JetBrains' lunch. Instead, we got Atom; prioritizing pluggability/extensibility/hackability over footprint/latency. To be clear, I'm not arguing for a fatalistic position that "there's nothing we can do about it". We can, and do, optimize performance when required. I'm just arguing for a more nuanced appreciation of the cost/benefit calculation that's at play here. Either there's an explicit cost/benefit being done (e.g. a PM weighs the "go faster" story vs. the "add new widget" story) or an implicit one (app #1 prioritizes speed, app #2 prioritizes features, and customers vote with their dollars; market share reveals which is more valuable).
- pjmlp 6y ago
  It is not possible to eat JetBrains and other's lunch, when only a subset of current generation is willing to pay for their tools, that is how Atom and Electron based GUIs get born.

ramzyo 6y ago

Thanks for your comment, as a VIM user who often turns up my nose at “slow” IDEs it helped me to understand a perspective that I would otherwise ignore, and reminded me that ultimately it’s what works for the individual that matters over any dogmatism that I may have. To offer an alternative perspective on this bit, > If 99.9% of your users (i.e. the lay users, excluding the experts in the HN crowd) don't perceive your program/page to be slow, why would you optimize further? For me personally as a practitioner of software engineering; because I can, and it’s meaningful to me to optimize in the broader context of designing and implementing a system, in part to see what’s possible in addition to the personal enjoyment of going through the process. That being said, for a company focusing on optimizing value to customers as a function of engineering resource allocation, I agree that it doesn’t make sense to optimize. You summed it up nicely with “...but that’s not the fitness landscape that most software evolves in.”

cxr 6y ago
> Thanks for your comment, as a VIM user who often turns up my nose at “slow” IDEs Note that the mention of Vim by the original commenter is a red herring arising out of lack of familiarity with Wirth. In Wirth's eyes, even Vim would appear monstrous. To appreciate Wirth's point requires realizing that his frame of reference is the Oberon (eco)system, which includes an OS, a mouse-driven graphical shell, a compiler, and the underlying CPU in an HDL all in a few tens of thousands of lines of code.

wtetzner 6y ago

> If 99.9% of your users (i.e. the lay users, excluding the experts in the HN crowd) don't perceive your program/page to be slow, why would you optimize further? And how do you know if they perceive it to be slow? I suspect that if you did optimize it to be faster (e.g. lower latency interactions), they would notice the improvement, even if they weren't sure why it "felt" better. > If speed/performance is a feature that your customers want to pay for, they will let you know. I don't buy that. Customers often don't even know it's a possibility that their software could be faster. In my experience, often lay users don't think of individual programs as being fast or slow. They either assume the "internet" is being slow, or their computer is slow. However, I think they do notice when performance is better. They say it "works better" or "feels more reliable", but they don't necessarily know why.

jayd16 6y ago
After a threshold the business value drops off substantially. How often does a consumer pick between competitors and choose based on speed? I would assume that's vastly in the minority. You see some shakeups here and there. A large push to a new browser once a decade, etc. but features are king most of the time.
- wtetzner 6y ago
  > After a threshold the business value drops off substantially. Sure, but I don't see any reason better tools couldn't get us closer. Instead of starting out with languages and tools that will almost guarantee slow software, maybe we work on designing languages that provide productivity while at the same time encouraging leaner software. I don't disagree that overall the environment software is developed in doesn't encourage lean software. But I do think it's worthwhile to see if there are ways to improve the situation. Also, faster software can often provide opportunities for new features that weren't possible before. For example, something that used to be a batch or background process can now become a real-time feature. That is something that customers likely would find useful.
  - theptip 6y ago

loup-vaillant 6y ago

https://www.youtube.com/watch?v=k8gIJOy0c2g https://www.youtube.com/watch?v=k8gIJOy0c2g It's not just developer writing a program for one user. It's a very small number of developers writing programs for many many users (unless you make custom software). The impact of what devs do is multiplied by the number of users. That includes the negative impacts of being slow or requiring more resources than necessary. Imagine Photoshop users having to buy more RAM not just because it is needed by some functionality, but because that functionality used more RAM than was actually necessary. The sheer waste, in money, carbon footprint, and pollution... Granted, optimising takes time. Time that would be taken to write features. There's a tradeoff there. But we should keep the competition in mind here: there's a difference between a feature being unavailable because you spent time optimizing, and a feature being available elsewhere instead. While it make sense for Photoshop devs to push features as fast as they can, it doesn't to users any good if Krita already offers those features. (I'm ignoring incompatibility here, but you get the idea.) The incentives are all wrong in my opinion. We should have fast, lean, correct programs to work with. They just don't happen in the current economic system.