3 ms·

Contrary to popular belief, performance is always a factor. Every cycle your app wastes is a cycle another app can't use. It's a fraction of a watt that adds u

Contrary to popular belief, performance is always a factor. Every cycle your app wastes is a cycle another app can't use. It's a fraction of a watt that adds up over time, draining batteries faster, drawing electricity from the power grid and burning carbon fuels. Each individual cycle may be cheap, but when we have a culture of development that doesn't respect performance, the waste adds up and has a real impact on the world. Just like all other resources, in aggregate, waste is harmful. Even on the spectrum of "developer productivity", you have to seriously consider if the operational cost of needing beefier servers to run slow-language-X is less than the operational cost of hiring fast-language-Y developers. I doubt anyone has done a serious study of the issue. Say C++ is 15x faster than Python. You might be able to say that a C++ dev is 2x the cost of a Python dev. Is the ratio of development cost to server cost more than 7.5x? What about other languages that aren't quite so fast, but aren't quite so expensive? You might find that C# is 10x faster than Python, but devs are only 1.25x the cost. Now your ratio of dev cost to server cost needs to be at least 8x to come ahead. And honestly, good developers are expensive, no matter what language they're working in. Choosing a programming language to be able to optimize for cheap developers could be optimizing for bad developers who can't create the features you need. They might be half the price, but can they get the job done--after all the reworks and defect fixes and other learning curves--in less than 2x the time? I've never seen a programming language on its own have that kind of impact on development. The point is not that "Language X is universally better than language Y". My point is more that "some languages are so incredibly wasteful that you seriously have to start considering whether or not you're saving money".

flmontpetit 7y ago
It's simply not possible to quantify performance in this way, when comparing language implementations. Performance can also be constrained by environment and/or context on top of the expensive abstractions the compiler or interpreter are required to make. But I'm honestly just being pedantic. You make a good argument about the potential costs abstractions when they are applied at a very large scale. You are however ignoring the cost of things that may be prevented with high-level language features, like for instance errors in memory management which in my opinion are far worse than wasted cycles. I'd wager most would choose a marginally higher power bill over Heartbleed.
- moron4hire 7y ago
  Though I didn't call it out specifically, I wasn't ignoring it, hence the mention of C#. Again, some languages are unnecessarily wasteful of cycles.
ryacko 7y ago
I don’t think a serious study of the issue can be done. Code review is the most difficult part of the development process (and a major advantage of open source), and businesses want to code the MVP as fast as possible without the competition copying them. The ideal language isn’t the most efficient language but one that is fast to develop, and leaves a possibility to optimize later. I would think languages like Nim and Rust are best in that regard, and more recently JavaScript.
- moron4hire 7y ago
  I agree on your comment about "most efficient language". And I agree that the business-interest is micro-focused on monthly-cost versus yearly- or even multi-yearly-cost. I think those two things are at odds with each other. I think a lot of technical decisions are being made on a short-sighted business level. And I think a lot of people on the technology side have inculcated too much of the business message. I'm not arguing against ever using languages like Python or Ruby or PHP or whatever. But I think a lot of people make assumptions that their language choice doesn't matter. In a lot of the same ways that building an entire economy on carbon fuels was "easy", it only worked because of externalities. As a profession, we need to be taking a longer view of our craft. I don't think that it is true that it's impossible to make C++ secure. I don't think that it's true that--say--Java and C# are less productive than--say--Python or Ruby. On a surface level, certain things are easier, but once you start digging into real problems, there isn't much difference. And experienced developers in any language will be far beyond that surface syntax. I just think that, as a profession, we have our priorities way out of whack.
  - ryacko 7y ago
    Maybe your comment is based on thinking about a recent conversation instead of replying to my comment. You make a few good points, but keep in mind that software development is both a centralization and planning problem. And exercising planning requires having accurate feedbacks.

flmontpetit 7y ago

It's simply not possible to quantify performance in this way, when comparing language implementations. Performance can also be constrained by environment and/or context on top of the expensive abstractions the compiler or interpreter are required to make. But I'm honestly just being pedantic. You make a good argument about the potential costs abstractions when they are applied at a very large scale. You are however ignoring the cost of things that may be prevented with high-level language features, like for instance errors in memory management which in my opinion are far worse than wasted cycles. I'd wager most would choose a marginally higher power bill over Heartbleed.

moron4hire 7y ago
Though I didn't call it out specifically, I wasn't ignoring it, hence the mention of C#. Again, some languages are unnecessarily wasteful of cycles.

ryacko 7y ago

I don’t think a serious study of the issue can be done. Code review is the most difficult part of the development process (and a major advantage of open source), and businesses want to code the MVP as fast as possible without the competition copying them. The ideal language isn’t the most efficient language but one that is fast to develop, and leaves a possibility to optimize later. I would think languages like Nim and Rust are best in that regard, and more recently JavaScript.

moron4hire 7y ago
I agree on your comment about "most efficient language". And I agree that the business-interest is micro-focused on monthly-cost versus yearly- or even multi-yearly-cost. I think those two things are at odds with each other. I think a lot of technical decisions are being made on a short-sighted business level. And I think a lot of people on the technology side have inculcated too much of the business message. I'm not arguing against ever using languages like Python or Ruby or PHP or whatever. But I think a lot of people make assumptions that their language choice doesn't matter. In a lot of the same ways that building an entire economy on carbon fuels was "easy", it only worked because of externalities. As a profession, we need to be taking a longer view of our craft. I don't think that it is true that it's impossible to make C++ secure. I don't think that it's true that--say--Java and C# are less productive than--say--Python or Ruby. On a surface level, certain things are easier, but once you start digging into real problems, there isn't much difference. And experienced developers in any language will be far beyond that surface syntax. I just think that, as a profession, we have our priorities way out of whack.
- ryacko 7y ago
  Maybe your comment is based on thinking about a recent conversation instead of replying to my comment. You make a few good points, but keep in mind that software development is both a centralization and planning problem. And exercising planning requires having accurate feedbacks.