Bloat

I want all of you JavaScript#++.NET 4.5 SP3 shitheads to understand what "bloat" is.  I know that you think that you know what bloat is, but you don't.  You think that it's when a program takes up a lot of disk space or a lot of RAM while running.  WRONG.

Bloat is specifically what happens when you are lazy.  If you're lazy, you decide that you don't need to understand pointers and you don't need to understand memory management and you don't need to understand the difference between compiling, linking, and interpreting.  If you're lazy, you don't learn any low-level concepts.

Even after reading that paragraph, you still don't understand bloat.  You're thinking "this is just going to be another GC is shit thread."  WRONG.

The real problem with bloat is that you make the world shittier.  Yes, your program uses more memory than it should.  Yes, it's slower and more non-deterministic than it should be because you have no control over the GC.  Yes, "Hello World" is a hundred megabytes.  But all of that would be tolerable.  What makes your program (and you) a pile of shit is that now the user has to be redirected to Microsoft's website to download another hundred megabytes of .NET installer, and he has to decide whether or not he wants the "full" version or the "client" version, and he has to decide whether he wants version 4.0 or 4.0.1 or 4.0.2 or 4.0.33019 SP1 or whether he should just set his computer on fire and buy a new one and pray that it already has all the right "frameworks" installed.

What you could have done, instead, was write a C program.  For bonus points, you could even do it without linking to the standard C runtime, so that there is absolutely no bloat whatsoever.  You won't, though.  You'll just keep trying to implement a Y-combinator in PHP because that's really valuable to the world and we all need that far more than we need programs that just fucking run correctly and efficiently.

I want all of you C/C++ shitheads to understand what "premature optimization" is.  I know that you think that you know what premature optimization is, but you don't.  You think that it's when a program takes up a lot of bad assumptions and a locked and flawed design. WRONG.

Premature optimization is specifically what happens when you are a optimization monkey.  If you're an optimization monkey, you decide that you don't need to understand compilers and you don't need to understand automatic memory management and you don't need to understand the difference between hand coded optimizations, and compiler optimizations.  If you're an optimization monkey, you don't learn any high-level concepts.

Even after reading that paragraph, you still don't understand premature optimization.  You're thinking "this is just going to be another C++ is shit thread."  [b][i][u]WRONG[u][/i][/b].

The real problem with premature optimization is that you make the world shittier.  Yes, your program is a little more inflexible than it should be.  Yes, extending it is slower and more non-deterministic than it should be because you have no control over the other prematurely optimizing programmers.  Yes, "Hello World" has a hundred dependencies on the current memory layout.  But all of that would be tolerable.  What makes your program (and you) a pile of shit is that now the user has to be redirected from a segmentation fault to your repository to download another hundred pages of missing documentation, and he has to decide whether or not he wants the to extend the "fully hand optimized and obfuscated" version or the "incomplete skeleton from the first check in" version, and he has to decide whether he wants the version 4.0, which requires the access library version 2.3, or version 4.0.1, which requires the rendering engine to be version 5.4, or 4.0.2, which requires the miner module to make copies of all arguments passed to the network builder, which then modifies in place the mesh passed to the surface distorter, which requires the miner module in version 4.0.33019 SP1 or whether he should just set his computer on fire and start from scratch and pray that it already has all the right "inline functions" installed.

What you could have done, instead, was write a program.  For bonus points, you could even do it without self combusting the design, so that there is absolutely no premature optimization whatsoever.  You won't, though.  You'll just keep trying to reimplement your program in assembly because that's really valuable to the world and we all need that far more than we need finished programs.