What's the choice here? Start saying "Russia will attack" and then see 20% of your population flee, while Putin sits and waits until your economy runs into the ground, and THEN attacks? There's no good choices here.
Reskin isn't quite right. Vivaldi offers a ton of amazing features that Chrome would never dream of having. For example, tab tiling is excellent and criminally underused.
The UX/UI of Windows 98 is far, far ahead of whatever Linux DWM we have today. It's nowhere near close. My KDE is usable but everything feels off, from icon shapes and sizes to mouse cursor icons, mouse cursor speed, the way settings are organised, almost everything. And it's not a matter of habit, as I've been on KDE for years, and I kept trying to make it work. Windows just clicks out of the box, it's more comfortable.
Microsoft, once upon a time, put an enormous amount of money into creating a user experience that makes sense for a maximum amount of people. Even though this experience suffered enormously over the last decade, it's still better than everything else, including OSX. And I'm not praising Microsoft, everyone else (including Canonical) is just that bad.
git is not "the fundamentals". It's a tool that's very difficult to learn but we are forced to use because "it won" at some point.
Git's difficulty is NOT intrinsic; it could be a much better tool if Torvalds were better at UX. In short, I don't blame people who don't want to "learn git". They shouldn't have to learn it anymore than one learns to use a browser or Google docs.
> Linux actually does have the flavour of problem the Clean Code is modelling here, and it does indeed solve it the way Clean Code recommends
Getting a bit desperate here, eh? On one hand, having tables of function pointers does not introduce any code constraints, you can switch to switches or anything else at a moment's notice; class hierarchies are much more rigid (some random Torvalds quote, "all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app"). On the other hand, Clean Code is fundamentally tied to OOP and classes. Here, straight from the horse's mouth [1]:
"This expectation of polymorphism is the essence of OO programming. It is the reductionist definition; and it is inextricable from OO. OO without polymorphism is not OO.
C and Pascal programmers (and to some extend even Fortran, and Cobol programmers) have always created systems of encapsulated functions and data structures. It does not require an OOPL to create and use such encapsulated structures. Encapsulation, and even simple inheritance, is obvious and natural in such languages. (More natural in C and Pascal than the others.)
So the thing that truly differentiates OO programs from non-OO programs is polymorphism.
You might complain about this by saying that polymorphism can be achieved by using switch statements or long if/else chains within f. This is true, so I must add one more constraint to OO.
The mechanism of polymorphism must not create a source code dependency from the caller to the callee."
In short, C is not OO because it doesn't do polymorphism (as understood in the context of Java-like OO languages rather than a mystic "it kinda looks and does the same as OO, thefore C is OO"). Furthermore:
"FP and OO work nicely together. Both attributes are desirable as part of modern systems. A system that is built on both OO and FP principles will maximize flexibility, maintainability, testability, simplicity, and robustness. Excluding one in favor of the other can only weaken the structure of a system".
Which is to say, if you don't do OO then you're not doing Clean Code. On a side note, Robert Martin obviously thinks he could write a Linux that's more flexible, maintainable, testable, simple and robust, but he's leaving it as an exercise to the reader.
> You're spending an unaffordable amount of your finite engineering resource on handling other people's problems in all of your code if you insist on peering inside everything
It's not quite so dramatic, you don't need access to STL's internals, just the structures you're working with anyway. To simplify: if you have an algorithm that deals with shapes then don't abstract away the concrete types, don't try to impose a taxonomy, don't pretend there's a magic shape interface that generalizes everything, don't try to fit the square box in a round hole. Instead, allow the algorithm to deal with concrete types. This is in fact the most flexible approach - you won't find yourself having to rethink your class hierarchy when one of your classes doesn't neatly fit into the general picture. I've been in the situation where at the end of a project it becomes very obvious that the chosen class hierarchy is actually unsuitable for easily adding more features and improving performance, but by that point the effort to restructure the hierarchy is equivalent to a rewrite. But hey, we had Clean Code.
The key point is that Casey's approach allows you to easily optimize for performance if needed; Clean Code does not.
> Casey and Jonathan Blow are too slow to deliver products
Fine, take Mike Acton. Same ideas, except he had to ship games on demand. You won't catch him doing Clean Code.
> You'd like to pay money to be assured that you're right?
I know I'm right, I'd pay money to see the embarrassment of the presumptuous Clean Code people who think that they can write maintainable code better than those who write software that matters (like Linux or Postgres, as mentioned before).
> So, your thesis is that writing a terminal emulator - software which is pretending to be hardware that existed 40+ years ago, shows that this person is great at handling surprising requirements changes during development ?
No. My thesis is that this guy can write code better than people who are supposed to be in the top 1% of the developers (well, it's Microsoft, not a web app sweatshop).
He works on games, where you not only have to iterate very quickly but you also may need to completely change direction halfway through the project. They can't have an "unmaintainable mess", otherwise they're not shipping the game, so your premise is wrong from the start. Also, games are much more complicated to program than the average Clean Code Crud app project that Uncle Bob bikesheds on.
> An insistence that the only thing we can measure is performance and specifically speed and therefore that's the only thing that matters is nonsense
Nobody said that, how are you coming up with this stuff?
The point Casey was making is that you're paying a significant performance penalty (speed, in this example) by doing Clean Code, which is true. You're denying yourself very basic performance techniques if you close your eyes and pretend to not see the internals of each shape.
> Try it, first add the hollow box example shape,
What if you don't have to? What if those are all the shapes you have to support? But there's ten billion shapes, you chose to do Clean Code and now you have slow code for zero benefit. Ouch.
On the other hand, if you want to add more shapes then the problem you're solving changed, and therefore you need to change the code (not really the tragedy you're making it out to be). I don't get this obsession, "code should change as little as possible"; it's actually a "careful what you wish for" moment because class hierarchies tend to become very rigid and difficult to change. Good luck making significant changes when your 100k+ loc program relies on a particular class hierarchy being in place.
> the iterators produce exactly the same machine code
That's great but it seems you're trying really hard to interpret Casey's video in bad faith. The way I understood it, he used an old fashioned for loop to avoid detracting from the main discussion, as not everyone knows what are the internals of STL iterators and how they translate to machine code.
Fun fact. Software you routinely use, like Linux and Postgres, is written in the same "spaghetti" style. I guess the Clean Code people who implement CRUD features for a living are better programmers than the ones writing operating systems and databases.
> Most of us work in an environment where surprising - even astonishing - customer requirements are often discovered during development and maintenance.
Another fun fact. The author of the video works in an environment where rapid iteration is absolutely vital. I'd pay good money to see a TV show where his style of programming ("spaghetti", as you claim) run laps around your "Clean Code". Because it would. For example, he wrote a terminal emulator in a weekend to prove that Microsoft doesn't have a clue about how to write code (I assume they also have many Clean Code people, and that it would take them about 6 months to write a terminal emulator from scratch).
The reason why this video mentions performance is probably because 1) the author has a course on performance and 2) it's something you can objectively measure.
If it were me, I'd not even bring performance into discussion, I'd just say that "Clean Code" significantly hurts readability and editability (and thus maintenance). But then you jump in to say that the non-Clean Code version is "an unmaintainable mess", and then we go around in circles. Which is probably why performance is his main point.
You managed to misunderstand both Casey Muratori and Donald Knuth. You are not alone, the majority of the industry seems to have gotten it wrong.
Casey tells you that following "Clean Code" can give you a huge performance hit for no obvious benefit. And even if "Clean Code" were to be more maintainable (it's not; in my experience, it's actually worse for maintainability), you should still be extremely aware of the cost you're likely to pay down the track. It's not a contrived example, it's literally textbook "Clean Code".
I'll say it again: "Clean Code" gives you slower, less maintainable code, and you get nothing from it. Maybe you can afford it, maybe in your use case it's not a big deal, but you should be informed.
Knuth tells you to measure before optimizing, which Casey did. Knuth does NOT tell you "don't worry about performance, you'll optimize later". You quoted Knuth but stopped right before the best part:
> A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; BUT ONLY AFTER THAT CODE HAS BEEN IDENTIFIED [emphasis mine]. It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail.
To recap: "A good programmer will not be lulled into complacency by such reasoning" - in other words, just because 97% of the code may not need optimization does NOT mean you should not be thinking about performance.
Knuth's point is that when identifying hotspots, programmers were relying on intuition rather than measurement. That's what he meant by "premature optimization". Knuth did not mean (especially since it was the 70s) you should write "Clean Code" that you know has worse performance for little benefit.
And Knuth does not write "Clean Code", by the way.
> The author of the post fails to articulate how we strike a healthy balance
There is no healthy balance between a good idea and a bad idea. Just eliminate the bad idea.
> And now the shape_union must be rewritten from scratch.
We spend most of our time reading code. If the Casey's code snippets are easier to reason about (which they are, especially as the codebase get larger), that's a big win. I'd imagine you want to optimize for code that is easy to (re)write, rather than minimize the number of key strokes while increasing the time spent understanding the code.
Correct me if I'm wrong. Even if the compiler devirtualizes the classes, you still have the memory cost of storing the vtable pointer in each of the object instances (8 bytes for each instance), which means you need to do more fetches from memory. Does CPU prefetching negate the cost of these additional memory lookups?
> There are far worse crimes than having code structure that spans several files.
Sure, but what's the advantage of having your code split over several files? Yes, you can jump between them with an IDE, but that's still a disruption, and it makes it harder to see common patterns that can help you simplify the code.
As demonstrated in the video, splitting up the switch into multiple classes only hurts readability.
> If you have more than one person working on a codebase; clean code matters a lot.
You can have fast and clean code, just not the Uncle Bob style of "clean code". Uncle Bob hijacked the meaning of cleanliness. It doesn't mean that code written like that is actually clean, in fact it's usually the opposite: Uncle Bob's clean code is NOT clean.
> I take issue with the idea that maintainable code is about "making programmers' lives easier"
He's talking about "clean code", not maintainable code. The claim that "clean code" is more maintainable is an unproven assertion. Whenever I interact with a "clean code" codebase, it is worse in every way compared to the corresponding "non-clean" version, including in terms of correctness.
Kind of surprised to see this so upvoted, I was under the impression that "top N richest people" articles only impress kids and the immature. Don't have a source for it but I'm pretty sure people with more than a few hundred million in the bank couldn't care less if they're richer or poorer than someone else, as they haven't made their fortune by worrying about frivolous things. But that's just me.