SE Radio 577: Casey Muratori on Clean Code, Horrible Performance?
ฝัง
- เผยแพร่เมื่อ 16 ส.ค. 2023
- Casey Muratori caused some strong reactions with a blog post and an associated video in which he went through an example from the “Clean Code” book by Robert Martin to demonstrate the negative impact that clean code practices can have on performance. In this episode, he joins SE Radio’s Giovanni Asproni to talk about the potential trade-offs between performance and the qualities that make for maintainable code, these qualities being the main focus of Clean Code. Brought to you by IEEE Computer Society and IEEE Software magazine.
- วิทยาศาสตร์และเทคโนโลยี
Casey is exceptionally clear with his reasoning and communication. I sincerely hope a large cultural shift takes place so we don’t have to wait 20 seconds for a basic program to load anymore.
Props to Casey for going on all these shows and arguing. It has to be exhausting.
Casey is a legend. Thanks for the interview!
(An argument of a webdev is crushed. "Okay let's move on.") Repeat into infinity.
Haha exactly what I was thinking
Sure, we can move on, just give me 20 seconds for the page to load.
Maybe it's just a language barrier issue but I found the interviewer to be really resentful and condescending.
@@truetom I don't think that was his intentions, I think he just disagreed, and thought continuing those parts of the discussions weren't going to go anywhere. I found the interviewer quite polite
@@LinucNerd 22:23 was not polite at all.
Edit: after watching the complete video, I change my mind.
Critical, precise questions delivered with respect. Insightful, passionate answers grounded in deep expertise. Great interview!
Casey is a national treasure
Having worked in as the sole c++ developer in a team of csharp developers, many ppl really have wrong idea about fast code and clean code.
Casey has a video named simple fast code were he discusses that.
For some reason people think writing classes and inheritance and virtual dispatch are the only way to code faster than 70s style assembly. They think the only way to reduce code duplication is using ton of abstraction, and templates. They think the only way to manage memory automatically if you use a garbage collection or raii.
That is a very narrow way of thinking...
For me, it was believing my professors - and later, colleagues - knew what they were talking about. And the proposition sort of makes sense if you don't look too closely. Abstractions certainly increases productivity from bytecode to ASM, and arguably also to procedural languages like C. I think the problem is that those abstractions are incredibly simple and easy to reason about, but typical abstractions today aren't. Instead it became faith-based rather than knowledge-based. And when I doubled down on that paradigm for years, it became harder for me to realize. Looking back there were so many signs I ignored, because I thought I just wasn't good enough at Clean Code. And foolishly believing those confidently spreading 'trust me' gospel is easy when you don't feel like you can live up to their advice. Programming is a lot easier when you don't buy into all that though.
ill leave you with a Twain quote.
"Whenever you find yourself on the side of the majority, it is time to pause and reflect."
I stopped shopping at a certain supermarket chain because their self service checkout was horribly slow compared to a competitor.
I love this! I really hope that people take their time to understand what Casey is saying, instead of becoming defensive.
That part on being too chatty with IO was on point. I spend days and weeks optimizing enterprise apps that send hundreds or thousands of small queries via great abstractions like ORM to DB instead of writing some queries tailored for the usecase.
If I have, say, 2000 threads and each needs a call to a database, would it be better to just make one batched query and deal with the whole thing locally? Let’s say the database has 5 million accounts/entries and would have to send several GB of data
@@drygordspellweaver8761 If these threads are doing some truly independent work it will be hard to batch their queries. In general.
Watch out for code that iterates over DB entities and does additional queries. This is a red flag often the so called 1+N problem.
Watch out for code that queries data then uses part of queried data in subsequent queries. You might join these queries. Issuing one 'expensive' query is cheaper than issuing many 'cheap' queries achieving the same result.
Limit the queried data. Instead of selecting all columns select the columns your algorithm needs. Then processing millions of accounts may become a matter of some MB instead of several GB.
I worked with Redux (a popular JS library for state management) and I don't really understand why people are OK with sending tens, if not hundreds of small actions on startup application startup. In Redux you send actions (events) and each of them creates a new copy of the state in order to modify it. Redux Logger was a very popular choice to watch state changes. It logged every single action into a browser console, making it absolutely unusable. I quickly found out that if you spend couple extra minutes on your action interfaces and store organization, you can make on action make all changes that are required and get to them point when on user input equals on action.
@@drygordspellweaver8761 you probably don't need the multiple GB of data in a single step. Even better, you should try to do most of the computation on the DB side, only shipping the data that can only be transformed in the server
A bit of abstraction makes things easier ( that's why we make and use functions in the first place ), but a lot of abstractions makes code read like a wikipedia page, where you sometimes need to read a whole book to understand a single sentence, which, if rephrased, would only take twice as much space, but would be understandable even to a first grader.
Great job by Casey and the interviewer Giovanni, excellent questions and inciteful answers
There's no question mark in the title of original video.
I love his point about microservices. If more people thought about it in those terms, that the only benefit is organization structure, you would have less 20 developer teams splitting their application up into services thinking there is some other gains to be made. I had to work on a project where we ended up with about 5 services per developer, and it was actually less efficient than the original monolith it was replacing.
I always imagined that different teams could simply work on separate functions within a monolith
Excellent discussion!
Great questions!
I give you one more advice to the "lines of code" metric Casey talks about. In self contained modules I also like to minimize LOC and file count - but when the system to too big for this one inherently - then I measure "depth of abstraction" or "depth of dependency chains" and minimize those.
This is really resulting in best code quality. Much better code quality than clean code. I wish there would be compiler level support for this actually...
@@microcolonel It would be maybe beneficial then to name a few to see if they do what I point out here or that they do something else (but on this nomenclature). Also even if they exists, they are not well known enough / not in widespread enough use, so probably its good they get benefit by someone naming them
opposite head shapes
wtf hahaaaa
not only was Knuth programming in assembly, he was programming in his own assembly that was not implemented in any hardware.
Cuzzy Muratori
I mean, isn't it obvious that you should make everything you can to work faster, so that when something you have no control over is improved (internet speed, database queries, disk speed, CPU speed etc) - your code automagically benefits from improved hardware/3rd party software?
It kinda works both ways in a sense that if your code is only correct for current gen hardware - you are also doomed to rewrite the whole thing 10 years later(look at old games for like DOS or even early 2000s games, where physics and logic ONLY work at 30 frames a second, so when you try to run it on a much better hardware - the whole game breaks when you suddenly get 300 frames a second).
is it just me or was the interviewer a bit rude
To me it just sounds like they're not a native English speaker. They don't know how to naturally craft sentences in English in a way that comes off as accommodating. I don't know if Casey speaks Italian, but he might sound a bit rude too if this whole interview was in Italian.
Kaazi?
1935 seems to have been scrubbed from the internet. Anyone know why?
Casey got good points but the powers of inheritance and speed of reuse realilly is attractive to businesses. So speed of app vs speed of app dev is the question sometimes. But switch statements are under rated
Yes. What's attractive to business is one of the problems with today's software. Probably the biggest obsticle for good quality software is exactly that
Casey has good insights for the system's he has experience with, but he has little experience with enterprise applications.
He has some good points about over-abstraction, which is important to NOT have.
Another correct point: about Conway's Law and microservices.
BUT his big mistake relevant for business applications: he says that minimizing the number of roundtrips between server and client makes better performance. Not true because often not possible, as users have to exchange data over the server.
Кейси прицепился потому что он из геймдева. Там импользуются другие подходы. Мозгов это понять или желания у Кейси к сожалению нет.
Casey live in a hypothetical world distant from reality.
Man, F performance. I don't want to stay at the office until midnight because some guy wanted to print Hello World using 700 threads. Simple, clean code, please.
You should consider following his course. He shows how to get performance as if it’s just regular programming.
If you really think about it, thinking, “Uhh! Should this be a factory class? What interfaces do I need to inherit? Look at all these dependencies that I need to know about.” Isn’t productive. 30% of your thinking is not about real programming.
This train of thought is never found in people who program using C because there aren’t many features in C that distract you from real programming.
There is you, a problem, and a set of operations. There is no polymorphism, inheritance, method overriding and function overloading, interfaces, virtual methods and classes, concepts and constraints, exceptions, encapsulation, RAII, parametric polymorphism, life times, move semantics, and so on.
@@kingemhyr I'll have a look at the course, thanks.
@@kingemhyr this is exactly what has taken me years to finally figure out. I think elegant code sometimes offers a false sense of "understandability" because in isolation it looks "clean" and is easier to read. But when working with that code, I almost invariably find that it is harder to understand overall processes because of all the indirection (let alone the performance costs). At the end of the day, the few traditional language primitives like conditionals and loops are powerful enough to do a lot with. And even if you try to hide them inside smaller functions, they're still there. They just become increasingly harder to find and more fragmented. I am now a strong believer in locality of behavior over separation of concerns. I'd rather just read through a procedural function in almost a narrative manner than flip back and forth between files like a choose your own adventure book. The procedural code often looks "uglier," but it also ends up being easier to understand.
thats why youre a js kiddy who will never do anything interesting
Casey is so good about going on and on about nothing insightful. Guess he learned from Jonathan Blow.
You're too stupid for this talk.
IS HANDMADE HERO EVER GOING TO BE FINISHED. IT'S BEEN 9 YEARS AND NO NEW VIDEOS HAVE BEEN MADE LATELY. AHAHAHA AHAHAHA LOL
9 Years? It's mostly 1 year of a single person development time. If you remove the QnA and explaination its mostly 3 months of work.
how about you try finishing anything at all?
why does this project break people's brains like this
Clean code scales, 80’s style assembly language level optimization doesn’t. Look at Biology, redundancy and flexibility is the key to success. Optimized life form maybe consume less resource and perform better, but it is so fragile as to be extincted by such small environment changes.
"80’s style assembly language level optimization" - He literally says not to do it. Next time listen to the damn thing first. smh
@@HobokerDev You are right, his argument ended up quite reasonably, not too extreme. But dude, Clean Code is not equal to Horrible Performance… it is also true that title can mislead so many folks. It is a clickbait style naming.
Why do you think it's not equal to horrible performance? He demonstrates a substantial pessimization in a best-case scenario in his video - do you dispute that it is 'horrible', or something else? @@wonseoklee80
@@wonseoklee80 It mostly equal to that - because of horrible cache architecture is the most slowdown-heavy thing one can do and clean code (tm) as it is taught these days really makes you use pessimized code... Also if you pay attention to him, he argues only against the clean code (tm) in the religious sense and not in generally arguing you should not write code that is clean to read... just that the rule set we use for it is really pessimistic for performance and there are better ways. Also new languages can do it better too with having more perf by language design and still making readable code.
OK guys, maybe I have chosen the wrong channel to comment. Clean code has a good part and obsolete part. Many of its examples in Java is horrible, agree. BUT, SOLID principle itself is nothing wrong, it is all about how to implement correctly. Also modern programming languages passionately embrace these abstraction. The theory itself needs to be modified, but still core philosophy tells many goodies.
Casey is wrong, like 200% wrong. Custom code leads to terrible performance. Random code that tries to optimize and handle extreme cases that are not used 99% of the time, generates spaghetti and kills the performance in the rest of the code.
Clean code is an architecture that establishes well know patterns in the code, allowing maintainability, scalability and more.
What is easier then to optimize, a messy code or clean code?
Casey is falling to the classic trap of early optimization