7 ms·

Yes, this 450 line program could have been written in whatever native language you want with probably 3x the code and time spent, but why would you? Developer t

Yes, this 450 line program could have been written in whatever native language you want with probably 3x the code and time spent, but why would you? Developer time has been more expensive than hardware for a decade now. Everyone here loves to virtue signal about how horrible programs that take 0.01% of the space of a normal SSD and 1% of the RAM are, but the fact is that it does not matter at all, and you wouldn't even have noticed if you hadn't intentionally looked at the size of it.

lazyjones 8y ago
> Developer time has been more expensive than hardware for a decade now. How about developer time of 1 person vs. hardware (and electricity, CO2 emissions...) of 1 million users?
- MaulingMonkey 8y ago
  > vs. hardware (and electricity, CO2 emissions...) of 1 million users? Do you actually have a million users? Can that developer time be spent saving even more hardware or human costs elsewhere?
  - lazyjones 8y ago
    > Do you actually have a million users? Everybody who works on a cross-platform version of a generic utility has potentially many millions of users. > Can that developer time be spent saving even more hardware or human costs elsewhere? Nobody knows. But it's obvious that wasting resources like this is going to scale with every user - even non-users who just download out of curiosity.
    - MaulingMonkey 8y ago
      > Everybody who works on a cross-platform version of a generic utility has potentially many millions of users. Not the same thing. And other threads have established there are already popular color pickers this would be competing with if rewritten in a native lean style, that this would first need to take mindshare away from as well. I'm going to assume the answer is "no, this does not currently have a million users". > Nobody knows. We can make reasonable guesses. For one, I bet the author can get hired to work on a codebase that actually has a million users, not any of this "potentially maybe in the future" stuff. For another, I know for a fact that many of those codebases - even the native ones - have bigger perf problems, and a lot more room to optimize towards the ideal. I'm going to assume the answer is "yes, that developer time can be more efficiently used." > But it's obvious that wasting resources like this is going to scale with every user. This we can agree on. But there's an opportunity cost[1] to fixing that. Going to the root of the hosting site, it clearly states the author is a webdev, so "fixing" that in the "let's not use electron" sense might involve learning Rust or some other native language first. That's not insignificant. And then you're competing with other already existing perfectly functional native color pickers... so are you actually saving significant hardware costs? [1] https://en.wikipedia.org/wiki/Opportunity_cost https://en.wikipedia.org/wiki/Opportunity_cost
      - lazyjones 8y ago
        > I'm going to assume the answer is "no, this does not currently have a million users". You can spend all day asking irrelevant questions and answering them yourself, it won't get us anywhere. The point is that "developer time is more expensive than hardware" is not a valid argument from the user's perspective. As you can see from the complaints here, people already find the color picker less attractive because it uses wasteful Electron. It's not a good product, regardless of how cheap it was for the developer to produce and will be less successful as a result. You don't need justification for developing something that isn't good because of wrong or selfish priorities, but you'd better accept that success of your product and its environmental footprint depends on these priorities too.
        MaulingMonkey 8y ago
        > You can spend all day asking irrelevant questions We're discussing how dev time is best spent in service to the end user (and environment.) It's absolutely relevant. > The point is that "developer time is more expensive than hardware" is not a valid argument from the user's perspective. As you can see from the complaints here, people already find the color picker less attractive because it uses wasteful Electron. It's not a good product, regardless of how cheap it was for the developer to produce and will be less successful as a result. Things the end user does care about include features, price, and the actual existence of the end product, all things I see frequently sacrificed by the "maximum efficiency at any cost" crowd, because they're misallocating dev time. They aren't even optimizing the actual efficiency bottlenecks half the time, just micro-optimizing some unimportant edge case. You're right that the discussion doesn't matter to the end user, but that doesn't mean it's the wrong decision. As you can also see from the posts here, not everyone is convinced it's a big deal either. People are constructing strawman arguments "these devs and their 4k monitors and 32GB+ machines", but I'm using electron apps from an underpowered 8GB laptop just fine. Yes, if you're traveling and downloading it over a mobile connection, it'll take a hit. Yes, I'm sure you can find a worse laptop than mine, and if you search hard enough you'll even find one where the fact that it's an electron app will be a problem. Yes, you can spend more resources to make a better app - that's always true, the question is where diminishing returns make that no longer cost effective. Yes, if there's no outlets nearby, it won't stretch battery life as far. But no, I'm not convinced that calling it "not a good product" as a result of being an electron app is quite right either. Not the best product it possibly could be, but no product is. > You don't need justification for developing something that isn't good because of wrong or selfish priorities, Nor am I convinced there are wrong or selfish priorities in using electron. What, exactly, is wrong or selfish with saving dev time to work on something more important to the end user? Even if that's another product entirely?
  - fxfan 8y ago
    Slack probably does.
theon144 8y ago
Ah yes, the good ol' "Efficiency doesn't matter on my hardware in my situation" argument. Brought to you by the same culture that ends up with devs being surprised most of their users in fact don't have 8-core 32G machines with 4k screens, unlike all of their colleagues and immediate peers. For that matter, I did notice the size, as I'm browsing on a mobile connection (travelling) and the 55M color picker utility would take a bit over 2 minutes to download.
- phiresky 8y ago
  I would in fact argue that until we are at a point of diminishing return of improving hardware that it is good that software is becoming more and more "bloated", because that's the only incentive to keep researching more efficient hardware. Phones for example have basically been unchanged for 5 years regarding performance, because while hardware has drastically improved the apps have become heavier in proportion for superficial new features. Same goes for internet connections. As another example I'd say that the recent resurgence of deep learning has mostly come from (or at least was catalysed by) cheap, affordable GPUs, which only exist because gamers wanted better and better graphics.
  - aseipp 8y ago
    > we are at a point of diminishing return of improving hardware We're already at the point where hardware is marginally increasing in efficiency year-over-year for most purposes. We've been there for like, 4-5 years now. Chips created on high-end processes are already expensive to the point there's no immediate cost-savings to be had from them, only power savings. Twice as dense, twice as expensive, marginal performance improvements. Years of development. That's due to physical laws of nature, not because we suddenly started writing way, way better software and therefore hardware engineers decided to slack off for the past 8-5 years or whatever, after year-over-year doubling in the prior decades. Your lunch was never actually free, it's just that Bill down the hall has finally stopped paying for you every day, because he's starting to go broke and has to tighten his belt. > that it is good that software is becoming more and more "bloated" No it isn't, you only think that (and justify it with a speculative argument) because it lets you justify externalizing the costs of bloat onto someone else, ignoring any other concerns -- your users, your cloud provider, your hardware vendors, etc who all pay for the energy and time you wasted on their behalf. > that's the only incentive to keep researching more efficient hardware. No it isn't, this is just more baseless speculation to support your point.
tenryuu 8y ago
We choose to code so people with lower spec machines should also be able to run the program without having to worry about it running like trash. Short thread on the matter: https://twitter.com/Wunkolo/status/1091572380315439104 https://twitter.com/Wunkolo/status/1091572380315439104
svdree 8y ago
Why is everybody always so concerned with developer time, but never with user time? The author of this tool even complains about the startup time of photoshop, but somehow has no problem with building a tiny tool on Electron. The irony is quite strong here.

lazyjones 8y ago

> Developer time has been more expensive than hardware for a decade now. How about developer time of 1 person vs. hardware (and electricity, CO2 emissions...) of 1 million users?

MaulingMonkey 8y ago
> vs. hardware (and electricity, CO2 emissions...) of 1 million users? Do you actually have a million users? Can that developer time be spent saving even more hardware or human costs elsewhere?
- lazyjones 8y ago
  > Do you actually have a million users? Everybody who works on a cross-platform version of a generic utility has potentially many millions of users. > Can that developer time be spent saving even more hardware or human costs elsewhere? Nobody knows. But it's obvious that wasting resources like this is going to scale with every user - even non-users who just download out of curiosity.
  - MaulingMonkey 8y ago
    > Everybody who works on a cross-platform version of a generic utility has potentially many millions of users. Not the same thing. And other threads have established there are already popular color pickers this would be competing with if rewritten in a native lean style, that this would first need to take mindshare away from as well. I'm going to assume the answer is "no, this does not currently have a million users". > Nobody knows. We can make reasonable guesses. For one, I bet the author can get hired to work on a codebase that actually has a million users, not any of this "potentially maybe in the future" stuff. For another, I know for a fact that many of those codebases - even the native ones - have bigger perf problems, and a lot more room to optimize towards the ideal. I'm going to assume the answer is "yes, that developer time can be more efficiently used." > But it's obvious that wasting resources like this is going to scale with every user. This we can agree on. But there's an opportunity cost[1] to fixing that. Going to the root of the hosting site, it clearly states the author is a webdev, so "fixing" that in the "let's not use electron" sense might involve learning Rust or some other native language first. That's not insignificant. And then you're competing with other already existing perfectly functional native color pickers... so are you actually saving significant hardware costs? [1] https://en.wikipedia.org/wiki/Opportunity_cost https://en.wikipedia.org/wiki/Opportunity_cost
    - lazyjones 8y ago
      > I'm going to assume the answer is "no, this does not currently have a million users". You can spend all day asking irrelevant questions and answering them yourself, it won't get us anywhere. The point is that "developer time is more expensive than hardware" is not a valid argument from the user's perspective. As you can see from the complaints here, people already find the color picker less attractive because it uses wasteful Electron. It's not a good product, regardless of how cheap it was for the developer to produce and will be less successful as a result. You don't need justification for developing something that isn't good because of wrong or selfish priorities, but you'd better accept that success of your product and its environmental footprint depends on these priorities too.
      - MaulingMonkey 8y ago
        > You can spend all day asking irrelevant questions We're discussing how dev time is best spent in service to the end user (and environment.) It's absolutely relevant. > The point is that "developer time is more expensive than hardware" is not a valid argument from the user's perspective. As you can see from the complaints here, people already find the color picker less attractive because it uses wasteful Electron. It's not a good product, regardless of how cheap it was for the developer to produce and will be less successful as a result. Things the end user does care about include features, price, and the actual existence of the end product, all things I see frequently sacrificed by the "maximum efficiency at any cost" crowd, because they're misallocating dev time. They aren't even optimizing the actual efficiency bottlenecks half the time, just micro-optimizing some unimportant edge case. You're right that the discussion doesn't matter to the end user, but that doesn't mean it's the wrong decision. As you can also see from the posts here, not everyone is convinced it's a big deal either. People are constructing strawman arguments "these devs and their 4k monitors and 32GB+ machines", but I'm using electron apps from an underpowered 8GB laptop just fine. Yes, if you're traveling and downloading it over a mobile connection, it'll take a hit. Yes, I'm sure you can find a worse laptop than mine, and if you search hard enough you'll even find one where the fact that it's an electron app will be a problem. Yes, you can spend more resources to make a better app - that's always true, the question is where diminishing returns make that no longer cost effective. Yes, if there's no outlets nearby, it won't stretch battery life as far. But no, I'm not convinced that calling it "not a good product" as a result of being an electron app is quite right either. Not the best product it possibly could be, but no product is. > You don't need justification for developing something that isn't good because of wrong or selfish priorities, Nor am I convinced there are wrong or selfish priorities in using electron. What, exactly, is wrong or selfish with saving dev time to work on something more important to the end user? Even if that's another product entirely?
- fxfan 8y ago
  Slack probably does.

theon144 8y ago

Ah yes, the good ol' "Efficiency doesn't matter on my hardware in my situation" argument. Brought to you by the same culture that ends up with devs being surprised most of their users in fact don't have 8-core 32G machines with 4k screens, unlike all of their colleagues and immediate peers. For that matter, I did notice the size, as I'm browsing on a mobile connection (travelling) and the 55M color picker utility would take a bit over 2 minutes to download.

phiresky 8y ago
I would in fact argue that until we are at a point of diminishing return of improving hardware that it is good that software is becoming more and more "bloated", because that's the only incentive to keep researching more efficient hardware. Phones for example have basically been unchanged for 5 years regarding performance, because while hardware has drastically improved the apps have become heavier in proportion for superficial new features. Same goes for internet connections. As another example I'd say that the recent resurgence of deep learning has mostly come from (or at least was catalysed by) cheap, affordable GPUs, which only exist because gamers wanted better and better graphics.
- aseipp 8y ago
  > we are at a point of diminishing return of improving hardware We're already at the point where hardware is marginally increasing in efficiency year-over-year for most purposes. We've been there for like, 4-5 years now. Chips created on high-end processes are already expensive to the point there's no immediate cost-savings to be had from them, only power savings. Twice as dense, twice as expensive, marginal performance improvements. Years of development. That's due to physical laws of nature, not because we suddenly started writing way, way better software and therefore hardware engineers decided to slack off for the past 8-5 years or whatever, after year-over-year doubling in the prior decades. Your lunch was never actually free, it's just that Bill down the hall has finally stopped paying for you every day, because he's starting to go broke and has to tighten his belt. > that it is good that software is becoming more and more "bloated" No it isn't, you only think that (and justify it with a speculative argument) because it lets you justify externalizing the costs of bloat onto someone else, ignoring any other concerns -- your users, your cloud provider, your hardware vendors, etc who all pay for the energy and time you wasted on their behalf. > that's the only incentive to keep researching more efficient hardware. No it isn't, this is just more baseless speculation to support your point.

tenryuu 8y ago

We choose to code so people with lower spec machines should also be able to run the program without having to worry about it running like trash. Short thread on the matter: https://twitter.com/Wunkolo/status/1091572380315439104 https://twitter.com/Wunkolo/status/1091572380315439104

svdree 8y ago

Why is everybody always so concerned with developer time, but never with user time? The author of this tool even complains about the startup time of photoshop, but somehow has no problem with building a tiny tool on Electron. The irony is quite strong here.