Totally irrelevant questions IMO. Real software bloat are unused bytes that can be thrown out without compromising any of the end results.
No company will ever invest millions of $ for 20-30% in code reduction, they invest in the next thing. Why ? Because new things have a ROI, while code reductions and cleaning only costs money.
Not fully agree with the last statement, that code reductions/cleaning only cost money.
Most managers nowadays get rated by short term objectives. Time periods of 1 yr max. I never saw a manager that would get a bonus if their software stack would be improved over 5 years time.
And in my work experience the last 8 years in a SAFe wow it was always what can you demonstrate us you did the last sprints or PI ? It is very difficult to demonstrate you cleaned up the software bloat or architecture and then show the product behaves exactly the same way.
They think engineers always want to make things more perfect than necessary,
because with efficient software a 10 year old computer can still do everything users need it to even after many years of use
Moore's law says computing power increases exponentially. But without a matching increase in bloat the computer industry would soon be reduced to the same status as toilet paper. Actually worse, because with efficient software a 10 year old computer can still do everything users need it to even after many years of use, whereas toilet paper can only be used once.
They think engineers always want to make things more perfect than necessary,Which is true. This thread is proof of that.
People who complain about bloat wasting resources and reducing performance don't understand the goal of the system.
People who complain about bloat wasting resources and reducing performance don't understand the goal of the system
Our capitalist society is based on convincing others to pay you for the goods and services you produce.
People who complain about bloat wasting resources and reducing performance don't understand the goal of the system
Our capitalist society is based on convincing others to pay you for the goods and services you produce.
Yes, tell us about bad capitalist "system". Perhaps also mention a good communist / socialist "system"? How lovely, careful and tender it is, with no consumerism and careful to the people and the planet.
Yes, tell us about bad capitalist "system". Perhaps also mention a good communist / socialist "system"? How lovely, careful and tender it is, with no consumerism and careful to the people and the planet.
Oooh politics. You don't look good by assuming that engineers won't spot the fallacy in
- X is bad
- therefore Y must be good
- where Y isn't not(X)
private ownership of resources and land (*including* endangered environments and habitats) is the best way to preserve them.
Voluntary exchange is the best way to organise an economy, and widely-distributed private ownership of resources and land (*including* endangered environments and habitats) is the best way to preserve them.
At best you are a temporary caretaker of the land.
Oooh politics. You don't look good by assuming that engineers won't spot the fallacy in
- X is bad
- therefore Y must be good
- where Y isn't not(X)
Law of Excluded Middle.
You decide for yourself what to do with your time and your property, or someone else tells you what to do with them. There are literally no other options.
The label placed on the "someone else" and their central planning is irrelevant.
Some projects are just so complex that implementing a lot of it yourself would take too much time. The developers of the library probably also put a lot of work and knowledge in that library to make it perform well. You don't want to reinvent the wheel after all.
module.exports = leftpad;
function leftpad(str, len, ch) {
str = String(str);
var i = -1;
if (!ch && ch != 0) ch = ' ';
len = len - str.length;
while (++i < len) {
str = ch + str;
}
return str
}
Some projects are just so complex that implementing a lot of it yourself would take too much time. The developers of the library probably also put a lot of work and knowledge in that library to make it perform well. You don't want to reinvent the wheel after all.
Also it is hard to tell how good a library is when you come across it. You only truly see how usable or performant it is once you tried using it
Yeah, such as this library in node.js's NPM repository:
In that case, you should support the library, however.
If you work on a commercial product, it is an investment into your own business.
If you work on a noncommercial product, show your support by letting the upstream know you're happy for the work they do, and when you find a problem (or one of your downstream users reports a problem), you filter and check the bug report and pass it upstream –– or better yet, investigate it and provide suggested patches with full problem description upstream.
This is just enlightened self-interest, in my opinion.
I could see the management being furious about someone submitting a git pull request for a library fix that there employee developed during work hours that they are paying for. Reasons ranging from "Why should we be paying to fix bugs in some guys crappy library" to "This is company property, what is this GPL you are whining about" to "We don't want the competition to use OUR fix". This is probably part of the same reason of why service manuals don't have schematics anymore.
I could see the management being furious about someone submitting a git pull request for a library fix that there employee developed during work hours that they are paying for. Reasons ranging from "Why should we be paying to fix bugs in some guys crappy library" to "This is company property, what is this GPL you are whining about" to "We don't want the competition to use OUR fix".
I am not that much about Open Source i use Windows even. But i do provide feedback to open source projects when i have something valuable to share. If i fixed a bug or added a feature to an open source project i share it with the developers. It doesn't cost me anything to share it and the developers are pretty much always happy to see it.