Yeah but if the class changes you need to update everything, you got all that boilerplate taking up space for no real reason, etc...

The Rust way's just a lot cleaner imo.

A great piece of advice in general, not just for the holiday season.

Ah yes, closed source, such a dealbreaker, as if 99% of the other games weren't.

Don't get me wrong, I have nothing against open source games, it's just not a viable monetization strategy for most projects, and people gotta eat. There's reason why most open source games are either passion projects or old games that have been open sourced simply as an act of kindness towards the community since they generate pretty much no revenue.

I'm not happy about it, but it makes sense.
They're trying to avoid polarizing issues so as to not alienate undecided voters. Either way a democratic presidency would be better for LGBTQ people than a MAGA presidency, so I'm not too upset about our issues being put on hold for a few days to achieve that. I imagine they'll become a little more vocal about them once they're actually in the White House, and if not we'll still be better off regardless.

Transgender people are a minority amongst minorities, catering to them while potentially alienating so many more voters is not a wise strategy. Reasonable trans voters will already vote for Harris because they know what's at stake.

I don't like it, but if it means keeping fascists out of the office, I can live with it.

I've found it's mostly two things: readability (ironically) and performance. I'll describe a few crude examples, but I won't get too much into specifics, otherwise I might as well write another book myself.

The performance part is simple: its excessive reliance on polymorphism and the presence of several levels of abstraction just doesn't allow for good code generation. I've seen 10x+ performance improvements by dropping all of the above, with often minimal loss in readability; on the contrary, oftentimes the code became more readable as well.

The readability part is harder to explain; not only because it depends on the codebase and the problem at hand, but also on the coding style each programmer has (though in my opinion, in that particular case it's the programmer's problem, not the codebase's).
I like to think of codebases as puzzles. To understand a codebase, you need to piece together said puzzle. What I've found with Clean Code codebases is that each piece of the puzzle is itself a smaller puzzle to piece together, which isn't ideal.

Functions

They should be small and do one thing

I generally disagree, not because those ideas are wrong, but because they're often too limiting.
What often happens by following those principles is you end up with a slew of tiny functions scattered around your codebase (or a single file), and you are forced to piece together the behaviour they exhibit when called together. Your code loses locality and, much like with CPU cache locality, your brain has to do extra work to retrieve the information it needs every time it needs to jump somewhere else.
It may work for describing what the code does at a high level, but understanding how it works to make meaningful changes will require a lot more work as a result.

Don't repeat yourself

Once again, it makes sense in principle, but in practice it often creates more problems. I agree that having massive chunks of repeated code is bad, no questions about it, but for smaller chunks it may actually be desirable in some circumstances.
By never repeating code, you end up with functions that are over-parameterized to account for all possible uses and combinations that particular code snippet needs to work with. As a result, that code becomes more complex, and the code that calls it does too, because it requires you to know all the right parameters to pass for it to do the right thing.

Exceptions

Exceptions are just bad. They are a separate, hidden control flow that you constantly need to be wary of.
The name itself is a misnomer in my opinion, because they're rarely exceptional: errors are not just common, but an integral part of software development, and they should be treated as such.
Errors as values are much clearer, because they explicitly show that a function may return an error and that it should be handled.

Classes, interfaces and polymorphism

I have lots of gripes with object orientation. Not everything needs to be an object, not everything needs to be polymorphic. There's no need to have a Base64Decoder, much less an IBase64Decoder or an AbstractBase64Decoder. Base64 only works one way, there are no alternative implementations, a function is enough.

I'm a lot more on the data oriented side of the isle than the OO one, but I digress.
Object orientation can be good in certain contexts, but it's not a silver bullet.

Encapsulation for the sake of it

Let's say you have something like this:

class Point {
	public float X, Y;
}

With the Clean Code approach, it magically becomes:

class Point {
	private float x, y;
	
	public float get_x() {
		return this.x;
	}
	public float get_y() {
		return this.y;
	}
	public void set_x(float x) {
		this.x = x;
	}
	public void set_y(float y) {
		this.y = y;
	}
}

Why? Who the hell knows. It makes absolutely no tangible difference, it only makes your code longer and more verbose. Now, if a value needs validation, sure, but oftentimes this is just done regardless and it drives me insane.

Abstract classes for everything!

• "You'll never know when you'll need to add another implementation, right?"
• "You don't need to know the underlying implementation"

The problem with wanting to create the most generalized code in advance is that you end up stuck in abstraction hell.
You may as well not need the ability to have arbitrary implementations, but now you need to plan for that.

Not only that, but it also makes reasoning about your code harder: how many times have you had to step through your code just to figure out what was being executed | just to figure out what particular concrete class was hiding behind an abstract class reference?
I myself, way too many, and there was often no reason for that.

Also, the idea that you shouldn't know about the implementation is crazy to me. Completely encapsulating data and behaviour not only makes you miss out on important optimizations, but often leads to code bloat.

There's more but I'm tired of typing :)

Take a look at these if you want more info or someone else's view on the matter, I wholeheartedly recommend both:

• It's probably time to stop recommending Clean Code
• "Clean" Code, Horrible Performance

You can now review reviews

Gotta pad those CEO bonuses somehow!

I'm of the opinion that Uncle Bob did some massive damage to software development as a whole with that book.
With that said, this is genuinely funny.

Hey there's a word for that! It's called "Child prostitution"!
Doesn't sound quite as reasonable, does it? Not that it ever did.

People dislike JS because it's packed full of moronic footguns and technical debt. The "standard library" is full of baffling decisions and, much like the language, rarely does what you expect. Even its creator agrees it's a terrible language and should have been replaced by now.

TypeScript is better, but at the end of the day it's just an illusion. Add an any anywhere, which will happen, and you're back to square one. It also still inherits some of the weirdness of JS, because it is just JS with fake types bolted on. Plus, the amount of work one has to do to create a proper library with TypeScript support completely undermines the few advantage of JavaScript. Might as well use a real statically typed language at that point, at least you'd be sure your types are actually enforced.

Also, the whole web ecosystem is ass. The hoops one has to jump through nowadays to do web development are absolutely batshit crazy. And no, having a create-whatever that sets things up for you is not a real solution.

I think what it boils down to is: if you could instantly become a woman, would you?

I'm in a situation similar to yours. Getting laser (the beard's already gone though >:3), long hair, trying to present more androgynous, but otherwise male presenting at the moment... regrettably...

I consider myself trans because I'm actively trying to rectify that and if I was given the opportunity to magically switch, I would without even thinking about it.

I would say expertiment a bit and see if something clicks in you. If it doesn't, that's fine too. You may be gender non-confirming, which by what you described would be perfectly reasonable.

Or it could be that you're just not ready yet. I myself had to remove a ton of mental barriers to accept this part of me, but when I did, it felt extremely liberating and obvious. But trust me, I struggled a lot getting there, thinking it couldn't possibly be the case.

So experiment, really think about it, and see where you land. If you're not sure yet, repeat. You'll eventually find your sweetspot, and it'll be fine, whichever it is.

Feel free to ask if you have questions.

You didn't need to post this.