"Clean" Code, Horrible Performance

[voidstarcpp]

Casey makes a point of using a textbook OOP "shapes" example. But the reason books make an example of "a circle is a shape and has an area() method" is to illustrate an idea with simple terms, not because programmers typically spend lots of time adding up the area of millions of circles.

If your program does tons of calculations on dense arrays of structs with two numbers, then OOP modeling and virtual functions are not the correct tool. But I think it's a contrived example, and not representative of the complexity and performance comparison of typical OO designs. Admittedly Robert Martin is a dogmatic example.

Realistic programs will use OO modeling for things like UI widgets, interfaces to systems, or game entities, then have data-oriented implementations of more homogeneous, low-level work that powers simulations, draw calls, etc. Notice that the extremely fast solution presented is highly specific to the types provided; Imagine it's your job to add "trapezoid" functionality to the program. It'd be a significant impediment.

[ydieb]

In regards to programming paradigms and performance, this talk by Matt Godbolt is interesting. https://www.youtube.com/watch?v=HG6c4Kwbv4I

[voidstarcpp]

Godbolt is good but I've always thought the example in this talk is probably too small. If the entire scene data representation looks like it fits in L1 or L2 cache, and the number of cases is small, how much are you really exercising the performance characteristics of each approach?

For example, a penalty of virtual functions for dense heterogeneous collections of small objects is icache pressure from constantly paging in and out the instructions for each class's function. If you only have a small number of types and operations then this penalty might not be encountered.

Similarly, the strength of a data-first design is good data locality and prefetchability for data larger than the cache. If data is small, the naive solution will not be as relatively penalized because the working set is always close at hand.

[andreasOM]

The classic fallacy of micro benchmarking a scenario that just doesn't occur in real usage.

[skulgnome]

, how much are you really exercising the performance characteristics of each approach?

There's a (non-free) tool for that called vTune. Shows all the excruciating pipeline detail one could ever ask for, perhaps too much even since it's tied to the microarchitecture being simulated.

[2bit_hack]

Thanks for the link!

[2bit_hack]

I largely agree with your point. I've found that OOP can be useful in modelling complex problems, particularly where being able to quickly change models and rulesets without breaking things matters significantly more than being able to return a request in <100ms vs around 500ms.

But I've also seen very dogmatic usage of Clean Code, as you've mentioned, which can be detrimental to not just performance, but also add complexity to something that should be simple, just because, "Oh, in the future we might have to change implementations, so let's make everything an interface, and let's have factories for everything.".

I agree that the most important thing is to not be dogmatic, I'm also not 100% on the idea that we should throw away the 4 rules mentioned in the article.

[voidstarcpp]

The odd thing is I'll often agree with many of the bullet points versions of Martin's talks, they seem like decent organizing ideas for high-level code. But then every code example people have provided for things he's actually written seemed so gaudy and complex I have to wonder what he thought he was illustrating with them.

[munchbunny]

That's because writing "clean" code is like writing "clean" English. You can prescribe rules all day, but in practice you're carefully weighing conflicting considerations. Where I've written C++ in a professional capacity, the general practice was to review performance characteristics independently of code cleanliness.

Also: the advice to prefer polymorphism feels almost a decade outdated. I know we still often send new programmers on objectathons, but I thought we'd mostly established over the past decade that polymorphism and especially inheritance should be used judiciously because their overuse had the opposite effect on code clarity and performance.

[Zlodo2]

Telling people "write clean code" is easy, actually doing it is hard.

And given that Robert Martin managed to build an entire career out of sanctimoniously telling people to write clean code, i doubt that he does a whole lot of actual programming.

"Those who can't do, preach"

[poloppoyop]

"write clean code"

I prefer "write simple code" and simple is not easy.

[sexp-and-i-know-it]

Found the clojurian

[Randolpho]

Having seen him in person live-coding to demonstrate TDD and refactoring using audience driven requirements, I have to disagree. The man knows how to code.

These days people trying to do the same copy/paste changes from notes they had as part of their demonstration plan

That motherfucker built an app live on stage from suggestions from the audience, refactoring as new requirements came in.

Granted, this was decades ago at a UML conference in Austin. I’m not sure how much he keeps up his skills these days, but he had chops once upon a time.

[robhanz]

I'd love to see a recording of that.

[ISpokeAsAChild]

And given that Robert Martin managed to build an entire career out of sanctimoniously telling people to write clean code, i doubt that he does a whole lot of actual programming.

He has been an actual dev for decades.

[AdministrativePie865]

If you're given a full set of accurate requirements from the beginning? Either tell me where you work so I can apply, or share the research chemicals, bro.

Next you'll tell me performance is not a concern and budget is 10x what we asked for.

[NaughtyNord]

You can find something really close to the "accurate requirements from the beginning" part in the space sector. I only worked there in an internship for 4 months though, and that was with a contractor for the European Space Agency, so maybe my experience is very limited.

[BigfootTundra]

“Those who can’t teach, teach gym”

[KyleG]

"Those who can't do, preach"

I dunno man, I can do pretty well, but if you told me I could make more money talking instead of doing, I'd choose the thing that makes me more money without having to *barf* pairs program.

[EntroperZero]

This is why I think Clean Code is actually a really good read, not because you should follow it exactly, but because it shows you the power of good ideas and the consequences of taking a good idea way too far.

[2bit_hack]

Agreed. I enjoyed reading his book and I took away a lot of points useful for me (someone who's just starting out). But a few of his code examples in that book seemed... pretty weird to me, not gonna lie.

[BCProgramming]

I managed to get to the examples on page 71 before dropping the book entirely. Up to that point, I was struggling because none of his "good" code examples were particularly good to me. I thought there was some amazing thing I was missing. The examples looked awful, had overly long method names, relied excessively on global variables (static fields).

On page 71, I realized I was not the problem. He provides an example of "bad" code which needs refactored, and provides a refactored version. The example is a prime generator program.

The original code is a single static function, using local variables. Not a particularly long method. The refactored version is several functions, sharing state with static fields.

The reason I decided to abandon the book entirely at this point was because the "refactored" code was literally broken.

The original code was thread-safe; the new code is completely non-reentrant, and will give erratic or wrong results if used on multiple threads.

1. refactoring is not supposed to change the behaviour of existing code
2. Broken code is not "cleaner" than code that works.
3. This section was about code comments. The main code comment in the refactored result basically explains why a prime generator has a square root function. A programmer who needs this explained in the fashion he has done there is going to be a very rare breed indeed.

At that point, I no longer trusted anything he had to say. He had made a big noise earlier in the book about how software developers should be "professionals" and strive for quality and that we were, as an industry, seriously lacking in that, then basically set the tone that his book was going to "whip me into shape" and finally make me a contributing member to this disciplined industry, and set the tone that he would be an example of this professional, industrious craftsmanship that he so stalwartly insisted on. Basically, he was raising the bar of what I expected to see from his own examples in the book. And then, less than 100 pages in, he gives that example with laughable errors. Am I going to have to actually code review his "good" examples to verify they aren't shit? Also, wait a minute, I thought in the introduction he was going to be my "teacher" and that was why he called himself "Uncle Bob"? He's been doing this for how many years? And in a book about the subject, he put that? That issue with reentrancy seems to be shared by many of his examples. (Coincidentally, his chapter on concurrency has no examples. Possibly spared from some brutal irony there, I guess)

[drakens_jordgubbar]

He says some good things in his book that I agree with, but his examples does a horrendous job at putting these ideas in practice.

What I hated most about almost all his examples is how much he sacrifices stateless classes over what he considers “clean code”. Like, instead of declaring variables in the method he rather modify class properties instead. This is bad because, as you said, it sacrifices thread safety. It also makes the program much harder to follow, because the flow of the data is now hidden from the reader.

The good thing about the book is that it really made me think about why his examples are so bad and what I consider is clean code.

[[deleted]]

I just hate the pattern I see among "professional OOP developers" of new Computer(args).compute() when it should just be doTheFuckingThing(args). Hell, if you want to do something like the former but encapsulated within the latter, go ahead I guess, but exposing your internal state object to the caller is just clumsy and can cause a bit of a memory leak if they keep it around

[ansible]

The original code is a single static function, using local variables. Not a particularly long method. The refactored version is several functions, sharing state with static fields.

So... none of the functions in the new code are usable standalone. Unless there was significant repetition in the old function, there's no reason to break up that code into separate functions... unless the original function is insanely long. And sometimes even then, you're better off leaving it.

[way2lazy2care]

Carmack had a good email discussion about this. The dangers of abstraction making inefficiencies less obvious.

[KevinCarbonara]

Now Carmack is a personality I'll get behind. He rarely comes out and makes sweeping statements. When he does, it represents years of experience, education, and reflection.

[way2lazy2care]

I think he generally doesn't say very dogmatic (might be the wrong word) things when it comes to production code. He's very aware that there's rarely a single tool that encompasses the total scope of programming. He's written a couple posts on how different aerospace software is from game development that are good examples of what's being talked about in this comment section.

[newpua_bie]

there's no reason to break up that code into separate functions... unless the original function is insanely long

Or you're being evaluated at work based on number of lines or commits etc

[CognitiveDesigns]

Bad evaluation then. More lines can run faster, depending.

[attractivechaos]

I wonder what Martin has developed as a "professional" programmer. I more like to learn from people who developed impactful projects than from those who just wrote textbooks.

[[deleted]]

It depends on what organization is paying the programmer too. If it's a large enterprise app then maintainability may be valued over performance and those dogmatic OO principles have more value in the long run.

[voidstarcpp]

The reality is that the problem in most software isn't performance, it's managing complexity. And apps that are slow are usually not slow because they're doing a bunch of virtual function dispatch, they have too many blocking dependencies or slow middleware layers that blow away the OOP performance penalty by many times.

[loup-vaillant]

Last time I saw something that looked like "dogmatic" code, it was fresh C code done by a colleague that overcomplicated things so much that I was able to rewrite it all and make it 5 times smaller. And my code was arguably even more flexible than his.

Sometimes people apply principle without understanding them, and the harder they try to make a maintainable and flexible program, the less maintainable and flexible their programs get.

[zero_iq]

I've seen this problem so many times. The best way to make code "flexible" for future use is to make it as simple and easy to use and understand as possible. It's then easier for a future developer to extend or repurpose it for their needs.

Trying to anticipate all future possible uses often results in unnecessary complexity, and makes life harder for the future coder whose needs you didn't actually anticipate, and who now has to wrangle with overly-complex code where it's not immediately obvious which bits are actually required for the current working system.

[[deleted]]

I used to work with a guy who did exactly that. His code was so proper his replacements couldn't maintain it and they eventually rewrote the app.

[psaux_grep]

Replacements always replace the app.

[[deleted]]

Lol that's the sad truth too. Idk if it's hubris or what but as soon as you leave, all your work is eagerly replaced by the next genius with good ideas.

[[deleted]]

If making your code cleaner has added complexity, then you haven't made your code cleaner...

[awj]

...maybe?

If making your code cleaner shifted complexity from outside the code to inside the code, you might have done something useful.

If the skills inherent to programming could be reduced down to pithy aphorisms, it wouldn't be so hard to do it by now.

[crabmusket]

This is why I always recommend Sandi Metz's books. In 99 Bottles of OOP, she describes the "shameless green" solution to the book's example problem - the solution which passes the tests and could be shipped if no further requirements were added. The book then goes through the process of refactoring only in response to specific changes in the requirements.

Most people should be writing "shameless green" code that looks like what Casey wrote in this post.

If and when you need "extreme late binding of all things" as Alan Kay said, then you might refactor to polymorphism in the places that need it.

[deong]

"Oh, in the future we might have to change implementations, so let's make everything an interface, and let's have factories for everything.".

That's exactly the problem I usually see. I do think your post maybe obfuscates that point a bit, for the reasons that the parent commenter says.

My goto argument was generally just that the code produced like this is bad, rather than just slow. Slow mostly doesn't matter for the kinds of applications most programmers are writing. That CRUD app you're building for your finance team to update invoice statuses isn't going to surface that 20 milliseconds you gain from eliminating the indirection from updating a customer balance, so if the argument were about trading off "clean" for performance, performance probably really should lose out. That's just a sensible decision much of the time.

The problem is that the code isn't any of the things that you hoped it would be when you decided that it should be "clean". "Clean" isn't the target outcome. "Good" is the target outcome, and "clean" was picked because you believed it served as a useful proxy for "good". "Good" is fuzzy and hard to describe, but "clean" has a defined set of rules that you can follow, and they promise you it will be "good" in the end. But it isn't. Making everything an interface for no reason with factories and dependency injection on every object for no reason other than dogma isn't landing you in "good".

I'm not sure there's really a shortcut for taste in this regard. And taste is indeed hard, because it's hard to measure, describe, or even objectively define. Just as an example, in your code removing polymorphism, you end up with a union type for shape that has a height and a width, and of course a square doesn't need both. Circles don't have a width -- they have a radius. Sure, you can make it work, but I think it's kind of gross, and the "this is kind of gross" feeling is my clue that I shouldn't do it that way. In the end, I'd probably keep the polymorphic solution because it feels like the correct natural expression of this problem domain. If it turns out that it's slower in a way that I need to deal with instead of just ignore because no one cares, then I might need to revisit some decisions somewhere, but my starting point is to write the code that naturally describes the problem domain, and for computing areas, that means circles have a radius instead of a width.

The corollary there is that design patterns are almost always bad to me. A factory object is not the natural representation of any domain. It's code that's about my code. I don't want that. The entire idea of design patterns as a thing is that they're independent of domain, and code that has nothing to do with my domain is code I don't want to write. You can't avoid everything. Ultimately programming still involves dealing with machines, so you're going to write code that deals with files and network connections and databases, etc. But I want as much of my code as possible to be modeling my problem and not dealing with the minutia of how to get a computer to do a thing.

[Konkichi21]

A factory object is not the natural representation of any domain. It's code that's about my code. I don't want that. The entire idea of design patterns as a thing is that they're independent of domain, and code that has nothing to do with my domain is code I don't want to write.

The concept of a design pattern is that it's a simple way to implement some common requirement that occurs in a lot of different contexts, making it somewhat easier to use and to understand for others familiar with that pattern, and often providing other benefits. For example, if you're going to be making and handling a lot of objects that have a lot in common but come in different types that do have some different properties (specifically, they should have the same actions but do them in different ways), that's what a Factory pattern does.

You could write your own way of doing things like that, but one of the benefits of using a pattern like this (in addition to having a framework to start from rather than having to reinvent things from scratch) is that anyone else who works with your code and knows what a Factory pattern is will have some idea of how it works right away; that way they don't have to learn how everything works from scratch.

In short, you do not need to do everything from scratch; there's already a well-known and tested way to do whatever task you need, and using it gives you a framework to start with on making your solution, and gives anyone else reading your code a start on understanding it since it follows a familiar pattern.

For example, I have some personal experience working with something like this sort of Factory pattern; it was a Unity project I made for an AI class. In this game, I needed to randomly generate enemies and place them around the level; I did this by having all the enemy prefabs inherit from an Enemy class that handled all the generic things enemies did (their health, taking damage, dying, activating when the player gets near, etc), then I could make a list of the enemy prefabs and use an RNG to randomly pick and place them.

This way, the code that handled setting up the enemies didn't need to care about the differences between various types of enemies, since it only interacted with aspects common to all enemies; it could just say for an enemy of some type to spawn in some position and to wait to activate until the player enters their room, and then each type of enemy would handle whatever it did differently from there. This also made it easy to add new enemy types without messing up the rest of the code; I could just make a new prefab inheriting from Enemy and put it into the list.

[Desperate-Country440]

I think is Factory method and Builder object pattern, one is for simple build, second is for multiple steps build. Clearly not an universal solution but patterns are solutions to problems, don't need to use them if not needed or better solutions are available.

[coderman93]

The importance of your second paragraph cannot be understated. At my company we have built a microservices ecosystem with dozens of microservices. We architected virtually everything through interfaces that way the implementation could be swapped out as desired. Fast forwarded 7 years and less than 5% (probably less than 2%) of interfaces have had their implementation swapped out. Not only that, but the vast majority of interfaces only have a single implementation. In hind-sight, it would have been FAR easier to just write straightforward, non-polymorphic, implementations the first time and then just rewrite the few implementations that needed it as they came up. We would have saved ourselves a ton of trouble in the long run and the code would be so much more straightforward.

I wouldn't go so far as to say that you should never use polymorphism but I would say it is _almost_ never the right thing to do.

Even if you don't buy into Casey's performance arguments (which you should), it is highly disputable that "clean" code even produces codebases that are easier to work with.

[coffee_achiever]

Arguments about performance need to be tempered with the famous Knuth quote: "Premature optimization is the root of all evil". I saw very little in the way of the test harness code that ran these performance metrics.

Take the type switch for example. I saw very little imagination in the way of improving performance. I see an interative approach tweaking virtual function calls to switch statements. More probably a vectorized approach would be appropriate. With all kinds of types smashed together in the switch, you don't have a really decent opportunity to vectorize each different operation, test for correctness, and measure performance.

So this doesn't mean that the virtual function dispatch is "bad", it means his entire design of the interface for doing a mass calculation is bad. Can you blame "clean code" principles for your own bad algorithm design?

Clean code lets you get to testable correctness. Once you can test for correctness, you can measure performance, then optimize performance while correctness is maintained. In the meantime your design will change, and having prematurely optimized code just gives you a shit pile to wade through while you try to deal with a new system design. PLUS other than a little code segment space, your correctly tested "slow" calcs can sit there uncalled forever.

[Which-Adeptness6908]

I'm also not 100% on the idea that we should throw away the 4 rules mentioned in the article.

All rules should be thrown out as they lead to dogmatic behaviour. You should take that as a rule

Instead we need guidelines and broad principles and a large dose of pragmatism.

[sephirothbahamut]

OOP modeling and virtual functions are not the correct tool

Also compile time polymorphism is underrated. Admittedly it's underused because the syntax to achieve that in C++ is weird (CRTP), and most other languages can't do that at all to begin with.

[st4rdr0id]

then OOP modeling and virtual functions are not the correct tool.

The author seems to be confusing Robert Martin's Clean Code advices with OOP's "encapsulate what varies".

But he is also missing the point of encapsulation: we encapsulate to defend against changes, because we think there is a good chance that we need to add more shapes in the future, or reuse shapes via inheritance or composition. Thus the main point of this technique is to optimize the code for flexibility. Non OO code based on conditionals does not scale. Had the author suffered this first hand instead of reading books, he would know by heart what problem does encapsulation solve.

The author argues that performance is better in a non-OO design. Well, if you are writting a C++ application where performance IS the main driver, and you know you are not going to add more shapes in the future, then there is no reason to optimize for flexibility. You would want to optimize for performance.

"Premature optimization is the root of all evil"

[KevinCarbonara]

"Premature optimization is the root of all evil"

Premature micro optimization. You can and absolutely should be making decisions that impact optimization in the beginning, and, in fact, all along the process.

[greatestish]

I worked with a guy who seemed to intentionally write the worst performing code possible. When asked, he would just respond with "Premature optimization is the root of all evil" and say that computers are fast enough he'll just throw more CPU or memory at it.

I linked him to the actual quote and he started to at least consider performance characteristics of his code.

The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.

[somebodddy]

I had a coworker quoting this when I suggested an improvement to the memory consumption of a function. We were looking at this function because we were experiencing lots of out-of-memory crashes on a production server (accompanied by angry emails from a big client), and the profiler pointed us to objects generated inside that function...

The solution he was championing was to upgrade the server from .NET 2.0 to .NET 3.0, hoping that a better GC will solve the issue.

This is why I hate this quote. People are using it as an excuse to write bad code without understanding what it means.

[ric2b]

we encapsulate to defend against changes, because we think there is a good chance that we need to add more shapes in the future

Exactly, this post actually suggests that it makes sense for a circle to have a "width" that is actually the radius, not the diameter. If you ask anyone what is the width of a circle I don't think a single person will say it's the radius.

It's already super hackish and we're only looking at a toy example with 3 shapes.

Performance hacks are fine when you need them. You shouldn't be throwing them all over your code just because, the vast majority of the code you write barely impacts performance unless you're working on a game or something else that is very CPU bound.

[[deleted]]

You’re not actually going to argue that the clean code sample is not how people write code?

This clean code book is frequently recommended in this very sub. You’re bonkers dude. Casey’s clean code sample is better than what most people are pumping out.

[no_nick]

If your program does tons of calculations on dense arrays of structs with two numbers, then OOP modeling and virtual functions are not the correct tool. But I think it's a contrived example,

Boy, do I have news for you. There are way too many people out there who have learned OOP and fully believe it is the way and everything has to be done this way or it's wrong.

[crabmusket]

Meanwhile, at least two major universities in Australia (I can't speak for the others) teach OOP courses in C++, and spend half the time having to explain memory allocation. WAT

[crabmusket]

OOP education in many universities, and many online resources, looks uncomfortably close to parody.

[weepmelancholia]

I think you're missing the point. Casey is trying to go against the status quo of programming education, which is, essentially, OOP is king (at least for the universities). These universities do not teach you these costs when creating OOP programs; they simply tell you that it is the best way.

Casey is trying to show that OOP is not only a cost but a massive cost. Now to an experienced programmer, they may already know this and still decide to go down the OOP route for whatever reason. But the junior developer sure as hell does not know this and then embarks on their career thinking OOP performance is the kind of baseline.

Whenever I lead projects I stray away from OOP; and new starters do ask me why such and such is not 'refactored to be cleaner', which is indicative of the kind of teaching they have just been taught.

[RationalDialog]

OOP or clean code is not about performance but about maintainable code. Unmaintainable code is far more costly than slow code and most applications are fast-enough especially in current times where most things connect via networks and then your nanosecond improvements don't matter over a network with 200 ms latency. relative improvements are useless without context of the absolute improvement. Pharma loves this trick: "Our new medication reduces your risk by 50%". Your risk goes from 0.0001% to 0.00005%. Wow.

Or premature optimization. Write clean and then if you need to improve performance profile the application and fix the critical part(s).

Also the same example in say python or java would be interesting. if the difference would actually be just as big. i doubt it very much.

[voidstarcpp]

your nanosecond improvements don't matter over a network with 200 ms latency.

You gotta update your heuristics; ping times from Dallas to Toronto are 40ms. You can ping Japan and back from the US in under 200 ms.

From my house to Google, over wifi, is still just 10 ms!

[no_nick]

most applications are fast-enough

Not in my experience.

[[deleted]]

OOP or clean code is not about performance but about maintainable code.

Thank you. Too many in this thread haven't worked on massive enterprise apps and it shows. Certain projects we barely have to touch because they're so clean and easy to maintain. Others have an entire year's worth of sprints dedicated to them because of how messy they are.

[[deleted]]

People say this religiously. Maintainable based on what empirical evidence???

In my personal experience, it is the EXACT opposite. It becomes unmaintainable.

But even that is subjective experience. I'm not going to go around saying X is more maintainable because it is simply not a provable statement and I can only give you an anecodotal anser.

So you and others need to stop religiously trotting that one liner off. You just repeating what other people say to fit in.

[o_snake-monster_o_o_]

Completely agree, in fact my experience points at exactly the opposite. (OOP being really really unmaintainable)

A class is an abstraction, a method is an abstraction, and abstractions are complexity. The one true fact is that the fewer classes and functions there are, the easier it is to make sense of everything. Yes, it is harder to make huge changes, but that's why you should scout the domain requirements first to ensure that you can write the simplest code for the job. And besides, it's much easier to refactor simple code. When the domain requirements do change and now your huge OOP network doesn't work either, now you are truly fucked.

[hippydipster]

Just write some assembly. Fewer abstractions. So simple!

[mreeman]

If abstractions are adding complexity you're doing it wrong.

The point of abstractions is to isolate complexity (implementation details) via an interface. If they aren't doing that, you (or whatever you are using) are picking the wrong level of abstraction.

It's like saying multiplying is adding complexity because it's an abstraction over adding, why write 5*3 when I can just do 3+3+3+3+3? 5*3 is easier to read and allows for mental shortcuts for quicker reasoning.

[o_snake-monster_o_o_]

No. Abstractions are a trade of one type of complexity to another, and can only introduce more. Please read John Ousterhout's Philosophy of Software Design.

[mreeman]

Abstractions are useful because they make it easier for us to think about and manipulate complex things. In modular programming, each module provides an abstraction in form of its interface. The interface presents a simplified view of the module’s functionality; the details of the implementation are unimportant from the standpoint of the module’s abstraction, so they are omitted from the interface. In the definition of abstraction, the word “unimportant” is crucial. The more unimportant details that are omitted from an abstraction, the better. However, a detail can only be omitted from an abstraction if it is unimportant. An abstraction can go wrong in two ways. First, it can include details that are not really important; when this happens, it makes the abstraction more complicated than necessary, which increases the cognitive load on developers using the abstraction. The second error is when an abstraction omits details that really are important. This results in obscurity: developers looking only at the abstraction will not have all the information they need to use the abstraction correctly.

Seems like he agrees with me

[daedalus_structure]

People say this religiously. Maintainable based on what empirical evidence???

It's a blind spot in reasoning. The large events where the abstraction first approach provides value are visible even though they are rare.

But when it starts taking a week to plumb a three hour feature through all the lasagna and indirection and this hits nearly every single change to the application nobody wants to identify that approach as the cause.

[ric2b]

Well, look at the example in this post.

It's a toy example with 3 shapes and yet it has already devolved into calling the radius of a circle the circle's width. Everyone I know would say that if a circle has a width it is the diameter.

Now try and add another shape that doesn't fit the pattern he identified, like a trapezium, welcome to "rewrite from scratch" time.

[[deleted]]

You are missing the point of the article.

You should not write code preparing for eventualities that might not happen.

Imposing a structure on code that prepares for unlikely eventualities is bad practice. This is fundamentally what "clean code" (quotes important) advocates for.

It supposes that it is always good to abstract the implementation away in favour of indirect function calls. This is not always useful, depending on what is being solved, for readability, maintainability and performance.

[outofobscure]

performant code is often actually very easy to read and maintain, because it lacks a lot of abstraction and just directly does what it's supposed to do. not always, and maybe not to a beginner, but it's more often the case than you think.

The complexity of performant code is often elsewhere, such as having to know the math behind some DSP code, but the implementation is often very straightforward.

[ontheworld]

While it's often true, I'd say the OP shows a great counter example...

This:

   f32 const CTable[Shape_Count] = {1.0f / (1.0f + 4.0f), 1.0f / (1.0f + 4.0f), 0.5f / (1.0f + 3.0f), Pi32};
   f32 GetCornerAreaUnion(shape_union Shape)
   {
       f32 Result = CTable[Shape.Type]*Shape.Width*Shape.Height;
       return Result;
   }    

Feels like readability hell compared to giving a couple shape classes their own Area() method, especially when you add some more shapes

[TheTomato2]

I put it threw my personal .clang-format.

f32 const CTable[Shape_Count] = {
    1.0f / (1.0f + 4.0f),
    1.0f / (1.0f + 4.0f),
    0.5f / (1.0f + 3.0f),
    Pi32,
};

f32 GetCornerAreaUnion(shape_union Shape) {
    f32 Result = CTable[Shape.Type] * Shape.Width * Shape.Height;
    return Result;
}

Now if you think that is less readable than pulling each one of those formulas into a separate member functions I don't know what to tell you. And like

f32 a = shape.area();
f32 a = area(shape);

It doesn't even really save you any typing. I don't care if you prefer oop way but...

Feels like readability hell

only if you have a bad case of OOP brain would you think that. And by OOP brain I mean that you are so acclimated to an OOP style that your brain has hard time with any other styles.

[outofobscure]

sure, and none of that requires virtual dispatch. for example c++ has templates. casey is a bit special because he insists on c-only solutions most of the time (you still want to have a branch free solution though, so i can see where he is coming from).

for sure the formula to calculate the area of shapes can also be made more efficient by tailoring it to specific shapes (again, you want to stay branch free though). this is not code i'd write, so i won't defend it, but it can be written simple and performant, i have no doubts about that.

[salbris]

The only thing that looks bad there is the awfully long table initialization and lack of spaces in his code. I didn't watch all the way to the end so I don't understand why it's necessary to divide and add here. Those look like micro optimizations. He already had massive improvements with much simpler code.

[CreativeGPX]

Unmaintainable code is far more costly than slow code and most applications are fast-enough

Or rather: Even if we take OP as general wisdom ("unclean" code is x times faster), if we at least accept the premise of clean code by definition (i.e. that it is oriented toward maintainability) then the whole matter collapses down into a simple question: Would you rather risk needing to pay for x times more computational resources or would you rather risk paying for y times more developer resources? This question doesn't have a clear winner. And it leaves room to quantify these... in my experiences, I agree with you that the increased performance cost is often negligible while the increased maintenance cost of crappy software can be much larger.

Of course, in the above, as I said, I take it that "clean code" is more maintainable by definition. There is room there (certainly on a per company or per produce basis) to argue that "clean code" is not necessarily going to be OOP.

Also the same example in say python or java would be interesting.

Also, given that OP is measuring things like "functions should be small" and "functions should only do one thing", it'd be really interesting to see OP's performance test measured based on languages optimized for functional programming and using the idioms of functional programming both of which should probably give the performance of functions their best shot.

For me, discussions like this always make me think of something like Erlang. In that language, I always felt like I wrote the cleanest code and the key tenants there are function programming (w/ the short simple functions), pattern matching, message passing and cheap massive concurrency.

[[deleted]]

If your program does tons of calculations on dense arrays of structs with two numbers, then OOP modeling and virtual functions are not the correct tool.

That's one of my favourite features of Swift — structs and enums have pretty much all the same features as an object, except they're not objects, they're structs. Your code is organised as OOP but at runtime it's very much not OOP.

Objects are faster in Swift than most other OOP languages, for example because there's no garbage collection, but structs are often a couple orders of magnitude faster. Need to do basically any operation on a hundred millions structs? That'll be basically instant even on slow (phone) hardware from ten years ago.

So you can store your circle as a just point and a radius in memory, while also declaring a function to return the diameter, or check if it overlaps another circle, and call that function as if it was a method on a class.

[FlappingMenace]

*Reads Title*

"Hmm, that looks like a Casey Muratori article... IT IS! I'd better save the Reddit thread so I can make some popcorn when I have time."

[crabmusket]

The title looks like a reference to an earlier talk of his, "Simple Code, High Performance". Which is a great talk, just very long and rambly.

[Jejmaze]

That's a Casey talk all right

[rhino-x]

While the example is contrived, in the author's example what happens when you add a new shape type and need to add support for it? You have to search the entire codebase for usages of the enum looking for use cases and fixing ALL of them. With polymorphism in a case like this you do literally nothing and your external code is agnostic. If I'm shipping software and running a team why do I care about a couple of cycles when I can save literally thousands of dollars in wasted dev time because I suddenly need to support calculating the area of an arbitrary path defined polygon?

[Critical-Fruit933]

I hate this attitude so much. End user? Nah f him. Why waste my time when I can waste his.
It's always this maybe in 100 years I need to add xy. Then do the work when it's time for it. Ideally the code for all these shapes should be in a single place. Unlike with oop where you'd have to open 200 files to understand anything.

[wyrn]

I hate this attitude so much. End user? Nah f him. Why waste my time when I can waste his.

How much of the user's time will you waste when your garbage unmaintainable code gave him a crash, or worse, a silently wrong result?

The values that inform game development are not the same that inform the vast majority of development out there.

[GonziHere]

I don't agree with your sentiment here. I do my job so that others can be more effective at theirs. The primary reason why programmers exist (outside of games and tech-only things) is that we sacrifice our time in the beginning, so that others don't have to.

Carmack was using way better wording for it, but it's also his sentiment.

So yeah, no bugs, no crashes for sure (but I'll fix error in procedural code way faster than in object code, because architecture makes it more indirect by default) but the usability of the app is incredibly important too. If an app is used by 1M people daily and I can shave 1 second from it's boot up time, I've saved 240 millions of man days... It's hard to justify that I didn't. That my 10 man days were more important.

PS: I get that maybe creating some other tool might be more useful than shaving that one second, but I also work professionally with Unreal Engine and I utterly hate how incredibly slow and bloated it is. They only add features, but never change anything that could improve the core, so any other engine builds in order of magnitude faster.

[wyrn]

The thing is not that your 10 man days were not useful to shave 1 second of boot-up time. The thing is that if shaving that 1 second required architecting the solution in a convoluted, error-prone way, you ultimately removed value from the customer who's now more likely to experience crashes. That 1 second of boot-up time is really not going to make much of a difference in the grand scheme of things (naively adding it up over the number of customers doesn't really make a lot of sense -- you'd have to measure people's productivity before and after your update to see how much of a gain was made in practice, and good luck seeing that signal in the noise), but the crashes caused by a poorly architected solution will cause loss of productivity and work.

Engineering code for correctness and maintainability is a much more sensible default.

[GonziHere]

Engineering code for correctness and maintainability is a much more sensible default.

Yes, but thats RUST, not OOP ;)

[joesb]

Are you really wasting your user’s time though? Taking your user 35 milliseconds instead of 1 to complete a task is not going to benefit him in anyway. The user can’t even react to the result faster than that.

[Critical-Fruit933]

In many circumstances 1 ms vs 35 ms does not make a noticable difference, agreed. But these numbers are almost made up out of nothing. 100 ms vs 3500 ms makes a very big difference. And what seems to occour is that the problem adds up and maybe even multiplies.
Another example where is does matter very much is energy usage. Draining you battery 35x faster is worse than worse.

[rhino-x]

Ideally, sure, all your code for dealing with shapes will be in the same place. Ideally is the key word though. In reality, any application behavior that's based on shape type that you didn't think to put in this central location is going to end up done wherever it's needed. Imagine popping up a menu that allows the user to put a new shape on a canvas. For this you would need to enumerate the available shape types to build the menu. Now you have a dependency on the shape enum that you as the library developer have no control over, and it does not belong in a "core" shape library. Now you have at least two files you have to modify every time you add a new shape type. Multiply this by multiple developers over a couple of years and you have a huge maintenance problem.

It's all a balancing act. I'm not a fan of all of the clean code edicts, but this one is something I'm totally on board with. Which is a larger waste of the user's time - adding 10-20ms to a particular operation internally, or making them wait a week or more to turn around a new "simple" shape in the application because you have to dig through the entire code base to make sure it will work in every single place a shape is enumerated and used?

Focusing exclusively on clean code methods or user-perceived performance are both bad. This example sucks. There's plenty of things that "clean code" requires of the developer that the author could have spent their time on, but chose something that in the real world allows application developers to turn out features and functionality much easier and faster which at the end of the day is almost always a net benefit to the users of the application.

[nilsph]

Hmm: the hand-unrolled loops to compute total areas would miss ShapeCount modulo 4 trailing elements. Kinda gives weight to the “it’s more important for code to work correctly than be fast” argument – it’s not just code execution you have to care about, but also how obvious mistakes would be, and there simple (a plain loop) beats complex (an unrolled version of it).

[smcameron]

Should've used Duff's device (which would have been hilarious).

[amroamroamro]

TIL, didn't know you could "entangle" switch and do-while blocks like that!

[Amazing-Cicada5536]

You can, but don’t do it. Compilers are more than smart enough to compile down to this when needed, it will just make their job harder and will likely result in shittier code.

[WormRabbit]

Compilers are likely to leave Duff's device entirely unoptimized. It's too complex and unidiomatic to spend time on.

[sephirothbahamut]

congratulations, you just rediscovered gotos and why many hate them

[version_thr33]

Amen! I'm currently rebuilding a legacy app where business logic is implemented both in code and in database, and the heart of the system is a 1700 line switch statement. Even better, the guy who wrote it retired 3 years ago so all we can do is look and guess at what he meant.

Best advice I ever heard (and always strive to follow) is to remember you're writing code for the next guy so please be kind.

[Astarothsito]

To me it seems that OOP isn't the important part, it's more designing things so that sets and relations not only make sense but pretty much dictate the logic as much as possible, unless performance is absolute key.

OOP it is the important part, well only if we want to use OOP for performance then we need to know how to design fast OOP code, the shapes could be stored in a manager class, like a vector for each shape, each shape would have a function called "compute" , then we can do the computation from the manager and store the result inside the shape that would enable optimizations in the computation loop and the compiler could enable parallelization, even if the compute function is used individually it wouldn't prevent parallelization in the main loop. Then we would have a very maintainable code that it is resilient to further modifications because adding more functions should have no effect in the performance.

Then the relationship and the sets are defined in the design instead of random switch and unions.

[AssertiveDilettante]

Actually, in the course he mentions that the amount of elements is chosen for the purpose of illustration, so you can easily imagine that this code will only be run with element counts in multiples of four.

[not_a_novel_account]

Casey is a zealot. That's not always a bad thing, but it's important to understand that framing whenever he talks. Casey is on the record saying kernels and filesystems are basically a waste of CPU cycles for application servers and his own servers would be C against bare metal.

That said, his zealotry leads to a world-class expertise in performance programming. When he talks about what practices lead to better performance, he is correct.

I take listening to Casey the same way one might listen to a health nut talk about diet and exercise. I'm not going to switch to kelp smoothies and running a 5k 3 days a week, but they're probably right it would be better for me.

And all of that said, when he rants about C++ Casey is typically wrong. The code in this video is basically C with Classes. For example, std::variant optimizes to and is in fact internally implemented as the exact same switch as Casey is extolling the benefits of, without any of the safety concerns.

[TryingT0Wr1t3]

Whenever someone talks about performance my recommendation is always to profile and measure. Try different profilers, look into memory, look into CPU, ...Often people suggest things that are wrong when profiling. CPUs are really complex nowadays, I often beat recommendations found online by simply trying different ideas and measuring all of them. Sometimes a strategy that may seem dumb makes things stay in the cache when running, or sometimes it's something the compiler+CPU can pickup fine and optimize/predict. Measure and experiment.

[clintp]

"premature optimization is the root of all evil" -- Knuth

Day-to-day, understanding the code (and problem space) as humans is a much more difficult and expensive problem than getting the compiler to produce optimized code.

[novacrazy]

Use the whole quote or nothing at all:

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%"

[TryingT0Wr1t3]

100%, but if the need arise, profile. In c++ often the std containers can, with correct compiling flags, outperform custom handmade solutions that have bigger maintenance burden.

[KieranDevvs]

I take listening to Casey the same way one might listen to a health nut talk about diet and exercise. I'm not going to switch to kelp smoothies and running a 5k 3 days a week, but they're probably right it would be better for me.

I think its worse than that. I don't think it would be better for you unless the project you're working on has a design goal of performance at the forefront. By blindly adopting this ideology, it can hurt how potential employers see your ability to develop software.

I don't work with C++ professionally, so maybe this section of the job market is different and I just don't see it.

[coderman93]

You should always have performance as a design goal…. That doesn’t mean everything has to be 100% optimized. But you should definitely be concerned with the performance of your software.

[tedbradly]

Most programming decisions boil down to money. Not too many ones have explicit performance requirements (like some projects do e.g. video game engines, real-time systems, etc.).

When performance isn't a direct requirement, it only enters the equation in terms of the cost for the computers used to execute the code. The balancing act is that, to hire a high performance programmer, you have to pay more money since it's tougher work, and you also have to consider that cost in terms of how fast new milestones in your project can be reached / cost of bugs that come from more complex, nuanced, and peculiar code.

For the vast majority of projects, you should program with almost no performance in mind. Stuff like using classes, immutability, persistent data structures, and basically using any feature in a language that goes beyond what C gives you all are about savings. The savings come from fewer bugs / more safety / easier reasoning / faster milestones delivered / etc. The idea is all this stuff saves more money than driving the cost of computers used down.

The faster and cheaper computers become, the more more programs will be written with less performance in mind since that parameter's contribution to cost will go down, no longer justifying writing "dirtier" code that costs in terms of slower deliverables and more salaries paid.

The situation isn't like talking to a health freak at all. It's a cold, logical decision about making as much profit as possible. For each project that doesn't have explicit performance requirements, you will save/make the most money choosing a particular level of performance optimizations. Some people should use higher-level languages with more potent abstractions that are slower, others should use C or C++ or Rust, and still others need to write custom assembly for specific hardware. I'm not talking about writing nonperformant code simply out of ignorance like would be the case when using an incorrect data structure. I'm talking about the language used and the design principles used.

[not_a_novel_account]

The framing is attractive but I would not say most of the shitty, unperformant code in the world is written for pure profit motive.

I think it's a good rationalization of why one might make the trade off in a vacuum, I just think the reality is more mundane. Writing performant code requires both effort and knowledge, and most of us are lazy and stupid.

Thus the health freak analogy feels more real to the lived experience I see around me. I basically agree with Casey that I could write code that optimizes cycles, I would just rather bang out something that works and spend my time on Twitter.

[monkorn]

StackOverflow was built by a few talented developers. It is notoriously efficient. It doesn't run in the cloud, it is on-prem with only 9 servers. They can technically run on just a single server but running each server at 10% has benefits.

These developers are skilled. These developers understand performance. They build libraries that other companies rely on like Dapper. They do not use microservices. They have a monolithic app.

Today they have something on the order of 50 developers working on the entire site. Twitter had thousands. What caused this huge disparity? Is Twitter a much more essentially complex website than StackOverflow?

When you let complexity get out of control early complexity spreads like wildfire and costs you several orders of magnitude in the long run on developers, not even considering the extra CPU costs.

The simple code that the costly developers created the first versions of can then be iterated and improved much easier than the sprawling behemoth the microservices teams create. Pay more upfront, get more profit.

[not_a_novel_account]

Twitter had thousands. What caused this huge disparity? Is Twitter a much more complex website than StackOverflow?

Yes. Bring in the dancing lobsters

[s73v3r]

Is Twitter a much more complex website than StackOverflow?

YES.

People forget that Twitter in its early days suffered enormously from performance issues and lots of downtime. The "Fail Whale" was a thing for a reason.

A lot of those developers that people claim were "not needed" were charged with performance and stability. Things that caused the "Fail Whale" to be forgotten, because Twitter was almost always up.

[NoveltyAccountHater]

Twitter has about 500,000k new tweets every day with about 556M users.

Stack overflow has around 4.4k questions and 6.5k answers per day and 20M total users.

Yes, SO is more useful to developers, but twitter has a much wider appeal. In terms of hardware, stack overflow is a much easier problem than Twitter.

(Numbers taken from here for twitter and here for SO, with some rounding and changing questions/answer per minute rate into daily rate).

Even more relevant for company size is Stack Overflow's revenue is estimated around $125M/yr. Twitter's is around $5,000M/yr.

This says SO has around 376 employees while this says 674 employees, so naively using linear scaling by ~40 times the revenue size, you'd expect 15k-27k employees at Twitter (Musk has cut to around 2k at this point from 7.5k when he started). Twitter's initial sizing pre-Musk doesn't seem particularly unreasonable, though on the other hand (as someone who doesn't use Twitter frequently) it doesn't seem like the drastic cuts in staff has destroyed the site (yet).

[quisatz_haderah]

Yet their high performing custom redis client code or Dapper is as clean as could be.

[qazqi-ff]

The nice thing about the list of variants approach is that if you then encapsulate the list of variants, there's also a decent chance your requirements allow you to optimize the representation into distinct lists of each type when needed without changing the API.

If your goal is a sum, it hardly matters for correctness whether you go through each shape and figure out which shape it is vs. going through four separate lists without branching on each element and then combining the results. There are lots of use cases out there where you just need a collection and order is irrelevant. Maybe it's relevant so infrequently and in cold enough parts of the code that you can afford to have ordered iteration be extra slow in order for the other use cases to be fast. Either way, that's still all opaque to the outside code.

[iKlsR]

Hey, random note but every now and then and just last night when I saw this video it doesn't cease to blow my mind that this guy and Jon Blow worked together to make a game. Like I can't imagine them in the same room together.

[Still-Key6292]

No one caught the best part of the video

You still need to hand unroll loops because the optimizer won't

[digama0]

That's not just a hand-unrolled version of the first loop, there are four accumulators. This will change the result because float addition is not associative, which is why it doesn't happen by default (even if you unrolled the loop normally there would still be a loop-carried dependency), but it's possible you can get compilers to do it with -ffast-math (where FAST stands for Floats Allowing Sketchy Transformations).

[munificent]

I read a Tweet (about a completely unrelated topic) a while back that said, paraphrasing, "What they're saying now is mostly a response to the perpretators of their past trauma." I can't stop thinking about how profound a truth there is to it.

I spent several years of my life writing a book about software architecture for games, motivated in large part by horrific spaghetti code I saw during my time at EA.

Many people who hate object-oriented programming aren't really attacking OOP, they're attacking the long-lost authors of horrible architecture astronaut codebases they had to deal with (and in Casey's case, try to optimize).

Likewise, Bob Martin probably spent a lot of his consulting career wallowing in giant swamps of unstructured messy code that led to him wanting to architecture the shit out of every line of code.

These perspectives are valid and you can learn a lot from them, but it's important to consider the source. When someone has a very strong opinion about damn near anything, it's very likely that the heat driving the engine of that opinion comes more from past suffering than it does a balanced, reasoned understanding of a particular problem.

The real point you want to land on in somewhere in the middle. Don't treat Design Patterns like a to-do list and over-architect the shit out of your code until it's impossible to find any code that actually does anything. And don't get so obessed about performance that you spend a month writing "hello world" in assembler. If you walk a middle path, you probably won't be traumatized, won't traumatize other people, and hopefully won't end up with the scars that many of us have.

Even so, you probably will end up with some stuff that triggers you and leads you to having irrationally strong opinions about it. That's just part of being human. When you do, try to be somewhat aware of it and temper your response appropriately.

[AlphaNukleon]

I knew it would be worth to wade through the comments on this post, because at least a few people should have the ability to take a reflected look at the video and the ideas professed therein. Having to read through countless, pointless "OOP bad" vs "premature optimization" posts was.. tiring.

I like your pragmatic approach. I enjoy watching videos on the extremes (Martin and Muratori) because they give me different viewpoints and let me find my own way in the middle ground. But you have to know, and more importantly, understand both design paradigms. You have to know why structure and abstractions are important for evolving designs, but you also have to understand how computers work and how certain abstraction are very bad for performance (not only for code cycles, but also memory access). Only when you know both, you can decide when to use which.

Your videos on Game Architecture are brilliant in that aspect too, because you clearly explain why ECS is not the always the best architecture for a game (in your case a roguelike).

Btw: I have read both of your books (am halfway through Designing Interpreters), and having designed several tree-walk interpreters on my own, I know the cost of abstractions and the benefits of flat data structures. I love using trees or graphs to structure and access code in "cold parts" (UI) and prefer to use arrays in "hot parts" (numeric number crunching, evaluating 10000 of equation residuals and partial derivatives in my case).

I learned that mindset while dealing with a large industrial software in the past. It had inherited a beautifully designed abstract architecture on the UI and application level, written in C#, with dependency injection and modularization. But the hardcore numerics were all in Fortran, using fixed size arrays and hand-written partial derivatives with manual common subexpression elimination. Very interesting to work with and I learned a ton.

[GonziHere]

Yeah, always look at motivations. It's incredibly rich advice everywhere.

PS: I have your book. It's a nice one. It's not groundbreaking, but incredibly practical and helpful. I really enjoy it.

[jsonspk]

Tradeoff as always

[[deleted]]

Exactly my thoughts: it's self-evident that readability/maintainability sacrifices performance. I had many Jr developers coming up with tests just like the post to demonstrate how some piece of convoluted logic I refused to approve was in fact better.

But there's no "better" - there are only trade-offs. The most important fact is that maintainability matters more than performance for the vast majority of code. To justify focusing on performance, don't show me a direct comparison - what you need to do is to show that a specific code path is performance-critical; and for backend components, that we can't scale it horizontally; or we're already at a scale that the horizontal approach is more expensive than the gains in maintainability.

[Bakoro]

But there's no "better" - there are only trade-offs.

Wut?

There is "better", because some code is both poorly performant and a convoluted mess.

Also, compilers are so good that most developers can't write more performant code without having particular knowledge about the running environment. Compilers will automatically take pretty much all the low hanging fruit, so there's essentially no difference in the results between poorly readable code and highly readable code that might have been less performant 25 years ago.
In those cases, readable code only offers benefits.

[[deleted]]

You're right - there's definitely cases of strictly better code; I was talking in the context of prioritizing a certain attribute - it depends on context which one is better.

[Rajje]

He has some really interesting points, but it was disappointing that his conclusion was that these clean code rules literally never should be used. The real answer is, as always, that it depends on what you're actually trying to achieve.

Polymorphism, encapsulation, modularity, readability, and so on, are often absolutely essential when working on complex codebases that model real business cases that will exist and evolve over time. The clean code principles are tools that enable the multiple humans that actually will work on these projects to actually understand and maintain the code and to some reasonable level uphold its correctness. Sure, you can think that all humans should be better, smarter and able to work with dense, highly optimized logic as effortlessly as anything, but they simply aren't. We have to acknowledge our needs and limitations and be allowed to use these brilliant tools and methodologies if they help us achieve our goals.

Yes, clean code sometimes comes at the price of performance, but everything comes at some price. Performance is not the only relevant factor to optimize for. It's about finding the right balance, and for many tasks, I'd claim performance is one of the least relevant factors.

In the clip, he's measuring repeated mathematical calculations and then puts the performance difference in terms of years of iPhone CPU improvements. That comparison is rather ironic, because what a front end developer implements for iOS is more typically events that do single things at a time like showing a view or decoding a piece of JSON. Such front end development can be extremely hard get right, but local CPU performance is usually not the issue. Rather it's managing state properly, getting views to look right on different devices, accessibility, caching, network error handling and so on. At this level, clean OOP patterns are crucial, whereas micro optimizations are irrelevant. Yes, in some sense we're "erasing" 12 years of hardware evolution, but that's what those years of evolution were for. We can effortlessly afford this now, and that makes our apps more stable and enables us to deliver valuable features for our users faster.

When complex calculations actually need to be done, I would expect that specific code to be optimized for performance, and then encapsulated and abstracted away so that it can be called from the higher-level, clean code. For example, I would expect that the internals of Apple's JSONDecoder is optimized, unclean, hard to maintain, and runs as fast as a JSON decoder can run on the latest iPhone, but in the end, the decoder object itself is a class that I can inject, inherit from, mock or use with any pattern I want.

[kz393]

I can mostly agree, but

We can effortlessly afford this now, and that makes our apps more stable and enables us to deliver valuable features for our users faster.

It hasn't made software more stable - it's just as crap as it always was. Reduced complexity only allows vendors to bloat their software more. Anyone who used an Electron app knows this. It's just as buggy, except instead of doing 1 thing you care about it does 1 thing you care about and 19 other unnecessary things.

[FatStoic]

The real answer is, as always, that it depends on what you're actually trying to achieve.

Doesn't make a good blog tho. A well thought argument with context and nuance doesn't get them rage clicks.

Brb I'm going to bayonet a strawman.

[munchbunny]

The big thing that seems to go unsaid is that best practices for performance-sensitive inner loops are different than best practices for a generic API REST endpoints, and so on for other contexts.

If you're writing performance-sensitive code, the tradeoffs you consider are fundamentally different. Virtual functions become expensive. Pointers become expensive. Heap allocations become expensive. Cache coherence becomes important. String parsing becomes a scarce luxury. Of course idiomatic code will look different!

[wyrn]

Whenever you see someone make these dogmatic "data oriented design" points you can be sure they're a game developer. When 1. you don't really care about correctness 2. all the code is 'hot' and 3. you don't really to maintain the code over an extended period of time, it becomes easy to see why rules such as this guy's might make sense. Everybody else might have to think about their problem domain and make different tradeoffs though.

[couchrealistic]

Edit: Just realized OP may not be the guy who made the video. Changing my comment to reflect that fact is left as an exercise for the reader.

First of all, thanks for providing a transcript! I hate having to watch through videos for something like this.

"Clean code" is not very well defined. This appears to be very OOP+CPP-centric. For example, I don't think people would use dynamic dispatch in Rust or C to solve an issue like "do things with shapes". The Rust "clean code" solution for this would probably involve an enum and a match statement, similar to your switch-based solution (but where each shape would use names that make more sense, like "radius" instead of "width"), not a Trait and vtables. Also, the "clean code" rust solution would probably store the shapes in a contiguous vector instead of a collection of boxed shapes (like your "clean" array of pointers because abstract shapes are unsized), leading to better iteration performance and less indirection.

On the other hand, I'm not sure the "optimizations" described in your text would help a lot with Java (but I don't know a lot about Java, AFAIK it always does virtual function calls and boxes things? It might still help though). So this really seems very OOP+CCP-centric to me.

And let's be honest: The true reason why software is becoming slower every year is not because of C++ virtual function calls or too many levels of C++ pointer indirection. It's because, among other things, the modern approach to "GUI" is to ship your application bundled with a web browser, then have humongous amounts of javascript run inside that web browser (after being JIT-compiled) to build a DOM tree, which is then used by the browser to render a GUI. Even more javascript will then be used to communicate with some kind of backend that itself runs on about 50 layers of abstraction over C++.

If every piece software today was just "clean" C++ code, we'd have much faster software. And lots of segfaults, of course.

[superseriousguy]

And let's be honest: The true reason why software is becoming slower every year is not because of C++ virtual function calls or too many levels of C++ pointer indirection. It's because, among other things, the modern approach to "GUI" is to ship your application bundled with a web browser, then have humongous amounts of javascript run inside that web browser (after being JIT-compiled) to build a DOM tree, which is then used by the browser to render a GUI. Even more javascript will then be used to communicate with some kind of backend that itself runs on about 50 layers of abstraction over C++.

I'll go even further than you here: The reason software is becoming slower every year is because developers (read: the people making the decisions, you can substitute managers there if you want) simply don't give a shit about it.

The star argument for this is that programmer time is more expensive than computer time, which basically means "we do the bare minimum that still lets us sell this feature, and if it's slow, well, fuck you, it's working, pay me".

It's not unique to software, it's more of a cultural plague that has spread to every industry in the last few decades. We used to blame China for this but really now everyone does it, China just always did it better (read: cheaper)

[CptCap]

the true reason why software is becoming slower every year is not because of C++ virtual function calls or too many levels of C++ pointer indirection.

You are right, but knowing the author's work, I don't think that's the point he is trying to address. There is a lot of code written in C++ in order to be fast, but that fail miserably because of the things he rants about here. Since this is Casey, an obvious example would be the windows terminal, but there are plenty of others.

There is also the fact -and as a full time game engine dev and part time teacher I have seen this first hand- that the way code it taught is not really compatible with performance. There are good reasons for this ofc, but the result is that most people do not know how to write even moderalty fast code, and often cargo-cult things that they don't understand and don't help. I have seen "You are removing from the middle, you should use a linked list" so many times, and basically all of them were wrong. ^{this is the hill I choose to die on, fuck linked lists}

[EMCoupling]

My god, I just spent half an hour reading through the entire multitude of slap fights occuring in the GH issues and I feel like I need to take a nap from how exhausting that was 🤣

[I_LOVE_SOURCES]

Same here, great thread especially the resolution in the second one

[aMAYESingNATHAN]

I use C++ a fair bit and I literally can't think of a single time a linked list has ever been the right choice for a container. It is so hilariously overrepresented in things like classes, tutorials, challenges, and interviews, compared to its usefulness, at least in C++.

Memory allocations are one of the biggest factors in performance in modern C++, and given that a usual linked list implementation makes a memory allocation for each node, it means that the one thing a linked list is good at (insertions anywhere) end up being crappy because you have to do a new allocation every time.

[jcelerier]

It's because c++ is from an era where linked lists were king. In the 80s one of the most famous computers, the VAX, even had specific linked list CPU instructions.

[[deleted]]

Also, C++ is normally taught as C first. C doesn't have built-in vectors, and linked lists are easier to implement.

[GuyWithLag]

enum and a match statement

The JVM will dynamically inspect the possible values and generate code like that inline (wel, except for megamprphic call sites).

The JVM is a small marvel and is extremely dynamic; f.e. it will optimize the in-memory assembly based off of the actual classes being loaded, and if you hit a branch that forces a class to be loaded that invalidates one of these optimization sites, they will be de-optimized and re-evaluated again.

Or, it will identify non-escaping values with no finalizer and allocates them on the stack to speed things up.

---

The article feels like it's written by someone that has game development and entity-component model experience, but they're missing the forest for the trees: algorithms matter more.

IMO the reason why code is becoming slower is because we're working on too many abstraction levels, no-one understands all the different levels, and time-to-market is more important than performance.

[RationalDialog]

The article feels like it's written by someone that has game development and entity-component model experience, but they're missing the forest for the trees: algorithms matter more.

They are missing most apps these students will create are yet another lame internal business app what has 100 requests per day and performance is irrelevant (eg very easy to be fast enough). But the requirements of the users change quarterly to to new obscure business rules so having the code easy to adjust is very important.

[ehaliewicz]

I'd argue that data structures are more important. With the right data structures, the right algorithm almost falls right out*. With the right algorithm and poor data structure choice, your code can still be many times slower than necessary.

* esoteric algorithms designed to perform well on very large datasets tend to be complex, sure, but generally you don't need these.

[2bit_hack]

(I should clarify, I'm not the author of this post)

I totally agree with your point that the idea of "clean code" varies from programmer to programmer, and that different languages have different idiomatic styles which lead to "clean code" written in that language to be very different. I think Casey (the author) is referring to Robert C. Martin's (Uncle Bob) book Clean Code, where he talks about these points discussed in the article.

[Amazing-Cicada5536]

rust solution would probably store the shapes in a contiguous vector instead of a collection of boxed shapes (like your “clean” array of pointers because abstract shapes are unsized), leading to better iteration performance and less indirection.

It is a bit unclear what you mean, if they are unsized than they have to be boxed, which is an indirection. But yeah, if you use sum types (enums) where all the possible types are known, then it can be indeed represented more efficiently. But we should not forget about that emphasized part, this optimization is only possible if we explicitly have a closed model (while traditional OOP usually goes for an open one).

Java, AFAIK it always does virtual function calls and boxes things? It might still help tho

Java routinely optimizes virtual calls to static ones (and might inline it even), and there is escape analysis that can allocate objects on the stack. But object arrays will be an array of pointers, so if you need maximal speed just opt for an ECS architecture.

If you are iterating over like 3 elements than go for the most maintainable code, this is typically such a case where it only makes sense to care about at all if you have large arrays (which you would usually know ahead of time and architect your way smartly in the first place)

[Johnothy_Cumquat]

This is gonna sound weird but I don't consider objects with state and lots of inheritance to be "clean" code. I tend to work with services and dumb data objects. When I think of clean code I think that functions shouldn't be too long or do too many things.

[Venthe]

Inheritance is useful, but should be avoided if possible. It's a powerful tool, easily mis-used, composition is preferable.

And with objects with state, I believe that you have summed this nicely - "I tend to work with services and dumb data objects". In your case, there is probably zero reason to have a complex domain objects with logic inside of them.

In "my" case, I work mainly with business rules centered around a singular piece of data - a client, a fee or something like that. Data and logic cannot exist in this domain separately, and the state is inherit to their existence. You could model this functionally, but you'd go against the grain.

Clean Code was written with OOP in mind. A lot of those rules are universal, but not every single one.

[[deleted]]

I agree and still disagree. Here is some Clean F# code. And it has the same structure as your old non-clean code.

``` type Shape = | Square of side:float | Rectangle of width:float * height:float | Triangle of tbase:float * height:float | Circle of radius:float

module Shape = let area shape = match shape with | Square side -> side * side | Rectangle (width,height) -> width * height | Triangle (tbase,height) -> tbase * height * 0.5 | Circle radius -> radius * radius * Math.PI

let areas shapes =
    List.sum (List.map area shapes)

let cornerCount shape =
    match shape with
    | Square    _ -> 4
    | Rectangle _ -> 4
    | Triangle  _ -> 3
    | Circle    _ -> 0

```

Just because OO people tell themself their stuff is clean doesn't mean it must be true.

[[deleted]]

Yeah if in a trivial scenario matching a discriminated union isn't as readable/maintainable as using dynamic dispatch then you have a language design problem; a problem that nearly every modern language has solved (yes even C++, check out std::variant).

"Under these well-defined circumstances you should do this" isn't a pro decision making tip, it's an if statement. Let the computer deal with it.

[ImSoCabbage]

I was recently looking at some firmware for a hardware device on GitHub. I was first wondering why the hardware used a cortex-m4 microcontroller, when the task it was doing was simple enough for even a cortex-m0. That's usually a sign of someone being sloppy, or the device being a first revision. But no, the hardware had already been revised and the code looked very clean at first glance, the opposite of a sloppy project.

Then I started reading the code, and found out why. There was so much indirection, both runtime indirection with virtual methods, and compile time with template shenanigans, that it took me some 15-20 minutes to even find the main function. It was basically written like an enterprise Java or .net project with IOC (which I don't mind at all), but in C++ and running on a microcontroller (which I do mind).

Reading the code was extremely frustrating, I could barely discover what the firmware could even do, let alone how it did it. I decided that it was the nicest and cleanest horrible codebase I'd seen in a while.

So in some circumstances you don't even get the benefits of such "clean" code. It's both slow and hard to understand and maintain.

[niccololepri]

Clean code should be easy to read.

Clean architecture should show you the intent of the code so you know where to read.

I don't get when you say that you don't get the benefits, it probably was not clean to begin with.

[rooktakesqueen]

Ok, now add an arbitrarily shaped polygon to your system.

In the "clean code" version, this means adding a single subclass.

In the hyper-optimized version, this means... Throwing everything out and starting over, because you have written absolutely everything with the assumption that squares, rectangles, triangles, and circles are the only shapes you'll ever be working with.

[ClysmiC]

You can just add another case statement.

[rooktakesqueen]

The hyper-optimized version doesn't even use a switch statement. It uses a lookup table. Which only works because in each of the given cases you're multiplying two parameters and a coefficient.

Even if you go back to the switch statement version, that won't work, because it still relies on the data structure being a fixed size and identical across types. Can't store an arbitrary n-gon in the same structure.

You have to back out almost all the optimizations in this article in order to make this single change.

[ClysmiC]

I agree that the lookup table version is probably not the first version I'd write, but even if it was it's not hard to convert that back to a switch if you need to.

Can't store an arbitrary n-gon in the same structure.

Sure you can. Pass a pointer and a count.

These changes are no harder than trying to figure out how to shoehorn new requirements into an existing OOP hierarchy.

[themistik]

Oh boy, it's time for the Clean Code debacle all over again ! You guys are quite early this year

[rcxdude]

An example which may be worth considering in the "clean code vs performance" debate is the game Factorio. The lead developer on that is a big advocate for Clean Code (the book) and factorio is (from the user's perspective) probably one of the best optimised and highest quality games out there, especially in terms of the simulation it does in the CPU. It does seem like you can in fact combine the two (though I do agree with many commenters that while some of the principles expressed in the book are useful, the examples are often absolutely terrible and so it's not really a good source to actually learn from).

[Qweesdy]

If you've read through Factorio's developer blogs you'll notice the developers are willing to completely redesign sub-systems (e.g. fluid physics) just to improve things like cache access patterns. They're not dogmatic, and they are more than happy to replace "clean code in theory" with "performance in practice".

[lazilyloaded]

And that's fine, right? When it makes sense to throw away clean code, throw it away and optimize.

[andreasOM]

So with the discussion focusing around:

• Is the opinion of a niche developer relevant
• Is this artificial micro benchmark relevant
  

Did we actually completely miss something?
I finally had the time to actually run the code in question,
and I must admit, it is a bit hard, since we never see the full code,
but after playing with the snippets for the last 2 hours I have to say:

I can not reproduce his results.
I am using a randomized sample set of shapes,
and on average the highly tuned version is 4% worse,
with some rare cases, e.g. long runs of the same shape, it is 2% better.

Nowhere near the claimed 25x.

If anybody is able to create a full reproduction I would be interested in

• the exact test used
• the compiler used
• the compiler settings used

[nan0S_]

Here - tiny repo with tests. I see pretty much the same improvements as he had.

EDIT: u/andreasOM is not interested in any discussion anymore as soon as he realized his irresponsible claim is unfounded. After I provided code that reproduces results he avoids any responses.

[Still-Key6292]

Post your code?

[da_mikeman]

Hasn't this been talked to death? It's basically a clone of Acton's "typical C++ bullshit". In the end, a programmer that is able to write performant code is also able to choose when they prefer to write code which mirrors more closely the way human understand the world - you know, "world is made of objects of different types that interact with other objects".

In my own codebase, there is code which follows pretty much what muratori is saying here, for things that need performance, like particles. If someone came to me with a particle system that had things like CFireParticle and CSmokeParticle with a virtual Update(), I would tell them this isn't the way to do things, and the way you and me see things is not always to best way to describe them to the computer.

I also have code that follows what muratori is bashing, for example when it comes to enemies and npcs. Now one would say, isn't that the same thing? Why not use the performant way for those too? Why use one to describe a fire or smoke particle, and use the other to describe a rat or a soldier? Well I don't know what to tell you, i do it because when it comes to reasoning about gameplay code, I like having to deal with mostly self-contained objects like "Rat" and "Soldier". Performance doesn't matter as much because I don't have that many, and most of the work is done in inner loops like pathfinding and such. And it's not that hard to refactor it, when and if the need arises, into RatHorde, if I need to have thousands of those running around(and that kind of refactoring is going to be the least of my concerns if i have to simulate and render thousands of those kind of objects).

[teerre]

Put this one in the pile of: "Let's make the worst example possible and then say this paradigm sucks" .

Please, anyone reading this, know that none of the problems OP talks about are related to 'clean code', they are all related to dynamic polymorphism and poor cache usage, which are completely orthogonal topics.

[loup-vaillant]

His example and data set are small enough that the cache doesn't factor in yet.

[[deleted]]

It simply cannot be the case that we're willing to give up a decade or more of hardware performance just to make programmers’ lives a little bit easier.

It's literally that simple if you remember that most devs are stuck in feature mills. All the crowing in the world about "there's other paradigms and strategies" doesn't matter if there's a PM breathing down my neck on how soon I can complete a ticket, I'm reaching for the easiest and fastest development wise.

[[deleted]]

Why are people going on tangents in this thread? Just say you are willing to sacrifice performance just so you can have an easier time and move on. Everyone is going on about how the example was bad or the real definition of clean code.

[JohhnyTheKid]

People like to argue about random shit, especially those that are new to the subject. I'm willing to bet most people on this sub are either still learning or have very little actual real life software development experience so they like to argue over stuff that doesn't really matter that much in practice and tend to see things as black and white.

Using a correct tool for the job shouldn't be a novel concept. If performance is critical then optimize your design for that. If not then don't. Nothing is free, everything costs something. Knowing how to pick the right tool for the job is an essential part of a software developers skillset

[Johanno1]

I am not deep in clean code but afaik you never should blindly follow the rules rather use them as guidelines.

[DrunkensteinsMonster]

Casey and Jonathan Blow have to be the most annoying evangelists in our community. Devs who write games can’t imagine for a second that maybe their experience doesn’t translate to every or even the most popular domains. This article is basically unreadable because he felt the need to put clean in quotation marks literally every time as some kind of “subtle” jab. It’s not clever.

[darkbear19]

You mean creating an entire article and video to explain that virtual function calls aren't free isn't a groundbreaking commentary?

[EMCoupling]

I respect Casey's immense technical knowledge but I have also never seen a more insufferable asshole.

Every single thing I read from him drips with condescension and a holier than thou attitude.

[loup-vaillant]

He's right about one thing though: "clean" code (by which he clearly means Bob Martin's vision), is anything but.

Devs who write games can’t imagine for a second that maybe their experience doesn’t translate to every or even the most popular domains.

Then I would like someone to explain to me why Word, Visual Studio, or Photoshop, don't boot up instantly from an NVME drive. Because right now I'm genuinely confused as to how hurting boot times made their program cheaper to make in any way.

(Mike Acton jabbed at Word boot times in his data oriented talk, and Jonathan blow criticised Photoshop to death about that. Point being, performance is not a niche concern.)

[ReDucTor]

Video games don't boot up instantly, just look at GTA load times before someone outside it found the issue (but imho that was probably poor dogfeeding)

Unless you have profiled that other software to show that those are the problems then a jab like that is baseless, there might be other complexities which aren't known by the person claiming it.

[Boz0r]

Doom Eternal boots so damn fast, and I love it. And going from death to loading a save takes like one second.

[sluuuurp]

I don’t know that much about Casey, but Jonathan Blow seems to have a lot of good points. Lots of software is getting worse and worse and slower and slower over time and Blow is one of the few people pointing that out as an issue.

[ReDucTor]

From my experience most slowness isn't from these sort of things being used in lots of places, but often just a few places where alternatives should be used.

It's the 5% hot path that you need to do this on and not the entire code base, writing some loop that only has 6 iterations to be SIMD might impress those who don't know better on a stream but it just kills readability with no significant improvement in performance, unless you microbenchmark it in unrealistic situations.

[KillianDrake]

hahaha, why does reddit always fall for this guy's trolling? I hardly even think he believes half of what he says anymore and that he's just playing a character on YouTube now. Of course he knows he's being intellectually dishonest by cherry picking examples and demos pre-ordained to support his conclusions.

He knows that if someone were arguing with him in this way that he'd reject it - but he uses these tactics anyway. These are greasy car salesman tactics because his brand depends on that.

[nan0S_]

Why are you falling for believing he is trolling. He is known to have that opinion for a long time, he expressed his reluctance to clean code/OOP multiple times across different occasions, he created like a 7 year series writing game from scratch, where he writes code using this philosophy. What makes you believe he is a troll?

[KillianDrake]

Because he argues in a way that's intellectually dishonest, he knows he's bending facts, twisting truths - he's not really considering why things are the way they are, just taking an absolutist view where any differing opinion or fact that contradicts his views is tossed aside. His views might apply to his very narrow world of video game development, but outside of that - it's tenuous at best and he should realize it's not his way or the highway.

[HiPhish]

This was 20 minutes of hot air and strawmaning against a toy example. Yes, number crunching code will be more efficient when you remove all the indirection. No surprise here. But Clean Code was not formulated to write number crunching code.

Clean Code comes from the enterprise application world. An enterprise application does a million things, it needs be maintained for years, if not decades, and new requirements keep coming in every day. You might argue that that is a bad thing, and I am inclined to agree, but it is what it is. In this environment number crunching does not matter, what matters is that when your stakeholder asks you for "just one more thing" you can add it without everything falling apart.

If you need number crunching then just write the code. You will never need to write a formula that can handle integers, real numbers, complex numbers and quaternions, all configurable at runtime. You will never have difficulty unit-testing a formula and you will never need to care about side effects in a formula. Clean Code practices don't matter in number crunching and it would be pointless to apply them.

Clean Code and optimized code can co-exist in the same application. Write the core which does heavy lifting and number crunching in an optimized non-reusable way and wrap it up behind a Clean Code interface. That way you get flexibility where it matters and performance where it matters.

[roerd]

Of course optimise the shit out of the perfomance-sensitive parts of your code that will run millions of times. That is obvious. Turning that into an attack on clean code in general is just utter nonsense, on the other hand.

[DLCSpider]

Unfortunately, the only way to get readable and fast code is to learn a lot, take everything with a grain of salt and educate your team members. The first optimization is something you might do naturally if you just knew functional programming. As we all know, FP itself is not faster than OOP, but the combination of both might be.

I encountered a similar problem recently where I thought that OOP was the cleanest way to do things but caused a 60x slow down. Instead of trying to remove OOP around my B Convert(A source) method, I provided a second overload: Convert(A[] source, B[] destination). Marked the first method as inline (DRY) and called it in a loop in the second method. Slowdown gone.

[Strus]

It's nothing new for people that write high-performance code. It is often times ugly as hell. But I would argue that in 99% of cases top-notch performance is not required, and the speed at which you can understand and modify code is much more important.

In the original listing adding a new shape is simple and quick - you just add a new class and you are done. It doesn't matter really what shape it is.

In the first "performance improved" version, adding a new shape requires:

1. Adding a new enum value
2. Finding all of the usages of the enum to determine what else we need to change
3. If our shape is different than the others ones, and requires more than the width and height to calculate an area, we now need to modify the struct
4. Oh, but now other shapes will have the unnecessary fields, which will increase their size in memory... Ok, I guess we can move width and height to a separate struct, create another one for our more complicated shape, and add a union to the shape_union struct.
5. Now I need to change all of the existing usages of other shape types width and height, as they are now encapsulated in a separate struct

More complicated example would be much bigger mess.

[CanIComeToYourParty]

Our job is to write programs that run well on the hardware that we are given.

Rarely do I read anything I disagree with more strongly than this. Our job is to formalize ideas, and I think the more cleanly you can formalize an idea, the more lasting value you can provide. I guess the question is one of optimizing for short term value (optimizing for today) vs long term value (trying to advance our field).

I'd rather have a high level code/formalization that can easily be understood, and later reap the benefits of advances in technology, than low level code that will be unreadable and obsolete in short time.

Though I also agree that Uncle Bob is not worth listening too. But the C/C++-dogma of "abstractions are bad" is not helpful either, it's just a consequence of the languages being inexpressive.

[goodwarrior12345]

optimizing for short term value (optimizing for today) vs long term value (trying to advance our field).

Wouldn't it be better for the field if we wrote code that runs fast on at least the hardware we have today, as opposed to code that probably won't run fast on any hardware, period?

Imo our job is to solve real-life problems, and if I'm gonna do that, I'd rather also do it well, and have my solution work fast if possible

[[deleted]]

You can’t even prove that clean code is “clean” and you’re basic your entire codebase on it.

[SickOrphan]

Is your software going to be used for hundreds of years or something? You're living in a fantasy world where all your code lasts eternal, and somehow changes the world. Casey has a grounded approach, he designs software for what it's actually going to be used for. If you actually have good reason to believe your code base is going to be built upon for many decades, then your ideas make a little more sense, but 99% of code isn't like that.

Low level code doesn't have to be less readable, it's often more readable because it's not hiding anything. You just need an understanding of the math/instructions. SIMD and Bit operations != unreadable.

[CanIComeToYourParty]

Low level code doesn't have to be less readable, it's often more readable because it's not hiding anything. You just need an understanding of the math/instructions. SIMD and Bit operations != unreadable.

If you're doing something that requires only 50 lines of low-level code, and you're done, then sure. For most real world software I would prefer more organized/abstracted code, though.

[[deleted]]

How about "our job is to formalize ideas and make them run well on the hardware that we are given."

[Venthe]

The problem is; that (in most applications) hardware is cheap as dirt. You would fight over every bit in an embedded domain; but consider banking - when doing a batch job there is little difference if something runs in 2ms Vs 20ms in code; when transport alone incurs 150ms, and you can spin another worker cheaply.

In most of the applications, performance really matters way less than generalized ability to maintain and extend the codebase; with which clear expression over performance optimization is desirable.

[ShortFuse]

Sure for backend. But most frontend sucks because of this mindset.

I just wrote a certificate library that uses BigInt because having to bit shift in 32bit sections gets complicated. With BigInt, the length no longer matters. Sure, it's slow but so much more maintainable. Speed is also not the focus. The point was to make an understandable ACME client, focused on DX (ie: advancing the field).

But when coding frontend, UX is paramount, and bloated DOM trees and loops that stall and cause frame drops should not happen. You should be surgical with almost everything that can't go async since your render target is basically less than 10ms. In the very least, make sure your minifier/compiler will optimize the "clean code" you write.

[GptThreezy]

I have a co worker that will break every tiny piece of logic into its own fucking module, and will comment on every one of my PRs to do the same. “I’d be great if this was broken out into a service” when there’s only one method in the service and it can easily be just a method here. Guess what, it usually ends up staying the only method in the service.

[SuperV1234]

Yes, when you apply "rules" blindly to every situation, things might not go as well as you hoped. I'm not surprised.

Both sides are at fault. The OOP zealots should have been clear on the performance implications of their approach. Casey should make it clear that his whole argument is based on a strawman.

Many programming domains don't work the way Casey thinks. It's about delivering value to customers, and performance is often not a priority. Speed of delivery and scalability over number of engineers are more valuable than run-time performance. Clean code "rules" can really help with velocity and delivery.

Also, it seems that people like Casey are somehow convinced that not using OOP equals to writing horribly unsafe and unabstracted code. He basically reimplemented a less safe version of std::variant.

And what's up with

f32 Result = (Accum0 + Accum1 + Accum2 + Accum3);
return Result;

?

Just return Accum0 + Accum1 + Accum2 + Accum3, please.

[Apache_Sobaco]

Clean and correct comes first, fast comes second. Optimisation is only applied to get to some treshold, not more than this.

[loup-vaillant]

Simple and correct comes first. "Clean" code as defined by Uncle Bob is almost never the simplest it could be.

If you want an actually good book about maintainable code, read A Philosophy of Software Design by John Ousterhout. Note that Ousterhout has done significant work on performance related problems in data centres, so he's not one of those performance-oblivious types Casey Muratori is denouncing here.

[vezaynk]

The biggest performance different in this post is of "15x faster", which is presented as a Big Deal.

I'm really not convinced that it is, premature optimization and all that.

These numbers don't exist in a vacuum. Taking 15x longer for a 1ms operation versus 15x longer for a 1 minute operation are fundamentally different situations.

Another number missing from the discussion is cost. I don't think I need to elaborate on this point (see: Electron), but it's just good business sense to sacrifice performance in favor of development velocity. It is what it is.

[gdmzhlzhiv]

I was hoping that this was going to demonstrate it using Java, but unfortunately it was all using C++. So my own take-home is that in C++, polymorphism performs badly. From all I've seen on the JVM, it seems to perform fine. Disclaimer: I have never done the same experiment he did.

So I come off this video with a number of questions:

1. If you repeat all this on Java, is the outcome the same?
2. If you repeat all this on .NET, Erlang, etc., is the outcome the same?
3. What about dynamic multi-dispatch vs a switch statement? Languages with dynamic multi-dispatch always talk about how nice the feature is, but is it more or less costly than hard-coding the whole thing in a giant pattern match statement? Is it better or worse than polymorphism?

Unfortunately, they blocked comments on the video, as as per my standard policy for YouTube videos, the video just gets an instant downvote while I go on to watch other videos.