4 ms·

...this might save megawatts of power world wide... Since when saved megawatts bothered programmers? If that was the case we would see far smaller usage of scr

• marmada 7y ago
  It takes effort to not use electron. It doesn't take effort to have your library update its dependencies to use a faster utf-8 validator
  • F-0X 7y ago
    > It takes effort to not use electron. Why do you believe this? I don't think it is quite that ubiquitous.
    • jimsmart 7y ago
      Let's say I want to build a cross-platform app. I could use Electron (it's somewhat of a known quantity), or I could start doing some research into what else is available, and then evaluate the various offerings - not only to ensure they do what I need, but to also ensure that they use less power/resources than Electron. The effort here is (at least some kind of) unavoidable up-front cost/time. To switch existing code to use some particular UTF-8 decoding library should be as simple as changing some imports, and perhaps some other (search/replace) code tweaks or implementing a quick shim/adapter. If it doesn't work out, rollback or abandon the branch. On most codebases, even larger ones, this whole process is probably an easier thing to do, requiring less effort than finding a decent (and more power efficient) alternative to Electron — seems to be the GP's gist. And personally I'd agree.
      • FpUser 7y ago
        "Let's say I want to build a cross-platform app. I could use Electron (it's somewhat of a known quantity), or I could start doing some research into what else is available, and then evaluate the various offerings - not only to ensure they do what I need, but to also ensure that they use less power/resources than Electron. The effort here is (at least some kind of) unavoidable up-front cost/time." Yup that's right. Any sign of inconvenience and efficiency be damned. Why do we even bother trying to fix environment. This cost money and inconveniences so many people. Also it depends on your background. I have no problem doing without Electron. I would have to apply your exact logic to even look at it.
        • dwild 7y ago
          You are clearly someone seeing in black and white. There's shade of grays too, you know? > Any sign of inconvenience and efficiency be damned. Nope, not any signs... just that if you can build more with less time, in exchange of a bit of CPU efficiency, it's not so bad. > Why do we even bother trying to fix environment. For the future. You see, my program using a bit more RAM or CPU won't change much. Not eating that meat, that will change quite a bit, thus that's one of the things I do. A software can allow people to be many orders in magnitudes more efficient, if I can build more of them, it allows even more people to be a few orders of magnitude more efficient. The power usage afterward, fit in the error margin quite well.
• kbenson 7y ago
  It's not quite that simple. A different algorithm and/or some well placed caching can easily outweigh the difference between a fast compiled (i.e. probably more efficient) language and slower interpreted one. Obviously, a more efficient language with a better algorithm and good caching is best, but often we don't have the resources (whether it be time or money or whatever) to engineer the best solution, so we need to choose where to focus carefully. Sometimes that means faster prototyping in a language that may not be quite as efficient, and then using the extra time to iterate on algorithmic changes that may yield major benefits or put a caching layer in place.
• LeoPanthera 7y ago
  "programmers" are not a single uniform homogeneous group and it is dismissive to consider them as such.
• adrianN 7y ago
  I'm a programmer and I care.
  • FpUser 7y ago
    Me too ;) But I think we are in minority here