ignirtoq

joined 1 year ago
[–] ignirtoq@kbin.social 2 points 7 months ago

Yeah, and the article is wrong, though only slightly. They seem to be confusing watts (power, energy over time) with Joules (energy, power times a duration of time). They give a passable definition in the beginning ("energy transfer"), but they seem to misunderstand what the "transfer" part means exactly.

If you find-replace all instances of "watt" with "watt-hour" after that starting definition, it would be more accurate. That's why I say it's only slightly wrong.

[–] ignirtoq@kbin.social 16 points 1 year ago (2 children)

Here I thought they meant women in domestic abuse situations who are still trying to get out. Like discussed here.

[–] ignirtoq@kbin.social 1 points 1 year ago

I think you are right that optimising engineering cost is the goal of these practices, but I believe it is a bad thing.
In the end the only people that benefit from this are the owners of the product [...]

Yes, that's exactly how the for-profit software industry (and really any for-profit industry) is run. The owners maximize their benefit. If you want to change that, that's a much different problem on a much larger scale, but you will not see a for-profit company do anything but that.

[–] ignirtoq@kbin.social 6 points 1 year ago (3 children)

I thought the point of "clean code" was to make a software source code base comprehensible and maintainable by the people who are in charge of working with and deploying the code. When you optimize for people reading the code rather than some kind of performance metrics, I would expect performance improvements when you switch to performance optimization. The trade-off here is now code that's more performant, but that's more difficult to read, with interdependence and convolution between use cases. It's harder to update, which means it's slower and more costly (in engineering resources) to upgrade.

In a lot of modern software, you don't need extreme performance. In the fields that do, you'll find guidelines and other resources that explain what paradigms to avoid and what are outright forbidden. For example, I have heard of C++ exceptions and object-oriented features being forbidden in aircraft control software, for many of the reasons outlined in this article. But not everyone writes aircraft control code, so rather than saying clean code is "good" or clean code is "bad," like a lot of things this should be "it depends on your needs."