Every time I see someone write "sorry for my bad english" their writing is several times better than many of the native speakers I interact with on a daily basis.

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.

Oh what do you know? It's almost as if representation in government has a purpose! Not so easy to target people when they're not just a faceless boogeyman now is it?

Love to see it, we need more of this everywhere.

Gotta pad those CEO bonuses somehow!

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

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.

You can now review reviews

What a surprising turn of events! Who could've possibly predicted this? Are you telling me that the party founded on hate for anyone who isn't a rich white guy is making things harder for whoever isn't a rich white guy? Preposterous!

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

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.

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.

Impressive, but we should stop trying to fit a square peg into a round hole. If there's one thing the world doesn't need is JavaScript in more places.

You didn't need to post this.

Yeah they've been doing that for a while

I've found working with Rust and Bevy to be quite pleasant. If you're used to working with ECS, I suggest you at least give it a go.
Rust is as functional as C++ 20 with ranges and views is, which is to say it isn't. Not sure where you got that impression from, but while it does borrow some ideas from functional languages, it's still very much a procedural one.

Zig doesn't have headers, nor inheritance. Again, not sure where you got that from, but Zig is basically a modern C, so there's no OOP anywhere, let alone multiple inheritance.

As for what to use, I think they're both viable alternatives. I lean more towards Rust, but that's just due to familiarity. Odin also looks like a viable option, if you don't mind a smaller ecosystem.
If you want a garbage collected language, then I'd go for C#. Despite its historic reputation as a Windows only language, it's been cross platform and open source for roughly a decade at this point. I find it great to work with.

No it just makes me even more frustrated. The amount of incompetence and neglect I see and have to deal with on a daily basis, even with software developed by multi-million dollar corporations, is astonishing.

Why is modern webdev such a clusterfuck? Why does VisualStudio take multiple seconds to open an empty project? Why does Nvidia's control panel have multiple seconds long pauses to switch between settings categories or loading lists? Why does this game run like garbage on a 4090 when it has mostly static environments and the graphics aren't even that good?

I could go on but I'd be here all day. All of those things, with the exception of webdev (because god there's so much shit in there...), could be easily fixed* or should've never gotten that bad in the first place.

*Provided the entire architecture isn't garbage, otherwise see the rest of the sentence...

They aren't, and the reason is that if you look at videos of those moments, instead of a very carefully picked still frame, you'll see that they were all quite clearly doing something else, either waving or starting to wave, pointing to something, and so on.

But I won't argue with brainwashed idiots, there is no point. I come from a country where fascism has destroyed the lives of so many people. You have no idea what a totalitarian government is and cannot recognize it, but you'll soon find out. In time, you'll see what a bunch of imbeciles you all are once it starts biting you in the ass as well.

No that's the issue: it's too permissive. It allows corporations or individuals to redistribute and modify the code as closed source, which isn't desirable for this kind of project.

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.

BREAKING NEWS: GNOME developer cannot accept people doing things differently than the GNOME team. More at eleven.