There is no reason to use std::endl in C++

https://youtu.be/GMqQOEZYVJQ

Check em

Bloated software has more value than non-bloated. Otherwise people would be buying non-bloated software.

>>40
You don't know that drawing is of a girl!

>>37
Every single term you use is shitty and objective. You are a failure with no argument. Get out of my fucking software industry and eat a shotgun, you piece of shit.

>>38

constraint

Subjective feelings bullshit. My constraint is that an IDE shouldn't take up more than 1GB.

What the fuck are you doing installing a

Why shouldn't I?

>>44
No, you.

>>42
People don't always have a choice. They often have to use what the company has bought.

>>46
Obviously, companies would buy software that makes their employees most productive with least demands on hardware. This is in their rational self-interest; companies who are bad at following their rational self-interest are outcompeted and replaced by companies who are good at it.

>>47
Nope, those are fairy tales. In the real world, companies often buy software as part of a large suite because it's cheaper that way. That's how Microsoft sells its bloatware: if a company buys Windows and Office, they throw in a Visual Studio as well and the company thinks it has saved money when in reality its employees are stuck with shitty bloatware that makes them unproductive.

>>47
Who the fuck cares about the demands on hardware? People are expensive. Giving every developer a latest & greatest decked out PC costs less than a quarter of a month's salary, and that developer's likely to be on for years.

It's only at the datacenter scale where you can spend all the optimization time to reduce real computational costs, and even in this situation the profit margin on hardware expenses is generally going to be acceptable.

You're microoptimizing things that don't matter, just to feed your own delusion that the small scope of things you know how to do are somehow important.

>>49
I used to think like this, then when I got to the real world I realized that speed still matters... a lot.

I'm not a programmer, I'm an ME. But even so the programming tasks I did required heavy optimization.

My first job out of college was at a test lab. Every once in a while I had to write software that processed data in some form. We collected a lot of data. It wasn't uncommon to be processing 20GB+ of data. Optimizations and using a sensible language can take your run time from days to hours.

My next job I was making consumer products. The products obviously had to be as cheap as possible which meant the cheapest MCU possible. Another case where memory had to optimized to painstaking measures.

So you're wrong. And not just a little bit. As computers get faster, we'll just work them harder. And we need to do this to squeeze out real productivity. Quit your damn whining and learn how to actually optimize shit.

>>50
I know how to optimize shit. And I know that optimization in general includes massive technical lock-in and prevents future modification, as well as assumes today's optimization tradeoffs when tomorrow's will change.

Speed optimization also almost always requires more hardware, for parallelization, caching, precalculation, analytics, and performance heuristics. That's the shit that makes things run fast, not some Cudderfag dicking around with deciding which asm instruction to best traverse an array. You want things running dramatically faster, it's an architectural fact that you will end up throwing much more hardware and software footprint at it as well.

>>50
Well there you go, you've experienced tasks that demand a tight account of the computing resources. The vast majority of programming tasks do not require the same level of tight accounting. Speed of processing matters but the cost of a programming team is normally more important than that. If the cost of running the software outweighs the cost of the extra time it costs to pay programmers to optimize the speed, then it's obvious that the programmer should be taking more consideration into writing the code.

>>51
Or you could just start using better languages and compilers.

>>51
Spoken like a true ENTERPRISE architecture astronaut.

>>52

the cost of running the software outweighs the cost of the extra time it costs to pay programmers to optimize the speed

Which it does for anything but trivial applications with a very limited lifespan and number of users.

User's time is more valuable than programmer's time. Especially when the user is themselves a programmer!

>>54
Dude, you said in >>50 that you work with cheap tinker toy controllers. Nobody else is actually constrained by hardware, and the software segment for those markets are tiny.

>>54

User's time is more valuable than programmer's time. Especially when the user is themselves a programmer!

More programmers should think this way.