@Scribblersys
5:05 "Apple hires really smart hardware engineers, and they just keep making things faster and faster, which means we can keep making things more convoluted and slower." This is exactly the kind of attitude that Casey is trying to push against. Why do you think it's a good thing that as hardware gets faster and more optimized, software can get slower and more bloated such that it basically runs just as fast (if not slower) as it did 5/10/20 years ago, basically squandering the work that hardware designers put into making things as powerful as they are now?
@nberedim
Noone remembers clean code. Everyone remembers Quake's fast inverse square root
@rafaelbordoni516
For context, this is Casey Muratori, he is a game dev. Performance in games is not like "if it takes less than a second to load the data it's fine", it's more like "the faster the code, the prettier the game and the better it plays", plus the customers complain way more when a game performs a little worse than the industry standard, everyone can see when a game looks better, plays better and performs better than yours. In this context, using all of the hardware with top efficiency is paramount. I think the message isn't to write the most unmaintainable code to get the best performance, it's just to be aware of how your code affects performance. Also, breaking clean code rules doesn't necessarily make your code unmaintainable, what is considered clean is extremely opinionated and writing performant code doesn't need to be a tangled mess.
@skytech2501
Software is definitely slow nowadays, we are riding on the hardware improvements.
@ohwow2074
What I find the most frustrating thing in Clean code bases is the abstraction level. I personally sometimes find it disgusting. Like you mentioned for DRY. Why would someone want to invent abstractions for some small pieces of code that are already readable and maintainable? Yet some people do this.
@anm3037
Web developers are the best neglecters of performance. There are few websites today that don’t keep you waiting.
@briankarcher8338
At its heart, "Clean Code" is about abstractions on top of abstractions. If you follow the book strictly you will get an unmaintainable application. If it takes more than two hops to find the code that your function is calling, you're probably doing something wrong. Removing abstractions, when it makes sense, improves the speed of code development.
@Pspet
Your mentality is literally the reason why my smart tv takes 2.5 seconds to open a static settings menu. (Hint: it should take 0 seconds. Exactly 0)
@donjindra
Object oriented programming introduces as many problems as it allegedly solves. IMO, the best policy is to keep your code simple, easily understood and well documented. I also favor short functions that perform one task. But there are definitely some cases where good programming practices take a back seat to performance. I'm one of those who wants to know as much about the internals as practical, especially when performance is a concern. It has helped me understand whole systems much better.
@VladyslavPavliuk
7:20 - that reaction is probably the root cause why the default Windows picture viewer takes 1-2 seconds to load on $4k PC.
@tibimunteanu
15:40 Just saying that "clean code" = "faster delivery time" does not make it true. I worked at many companies which required "clean code" from the programmers.. and most of the code was just awful. Adding really simple features on top of the "easy to maintain clean code" were really hard and frustrating to squeeze into those overly complex systems. And they took way more time to get done, and there were always large lists of bugs to deal with. Sometimes projects just have to be rewritten just because they become so convoluted that there is no way to add some specific new feature. I found myself mostly trying to navigate and understand complex layers of abstraction that had nothing to do with the problem at hand. This is never the case when you write the simplest code and avoid those clean code doctrines. I think you should try that coding style before commenting on whether you think it's good or bad.
@dire_prism
Everyone is worried about too many lines of code in a method. Everyone is worried about too many methods in a class. Not very often do I see people worried about polluting the namespace with too many small classes or having too many layers of indirection. But in reality this is just as bad, perhaps even worse.
@MadaraUchihaSecondRikudo
Regarding AVX at around 10:40 the reason you would not be using AVX or SIMD when writing clean code is that you need to be grouping (or at least be able to group) things by operation rather than by *data*, AVX is essentially "do 8 or 16 add operations in one instruction" if each add is a virtual call with a bunch of overhead, you would never be able to pre-determine which are the adds you want, then group them together to be performed at the same time.
@dagoberttrump9290
Gotta side with casey on this one. I'm doing embedded systems for a living and gamedev as a side project. For me a big part of the fun lies in squeezing as much efficiency out of the algorithms as possible. And i always find it funny that people think you'll end up with a mess after doing that. The most optimal code for me is procedural, code that you can read like a book. And as it happens, cpus like it this way too so why bother with pointless abstractions? The only thing that i care about is how to get from A to B in the shortest amount of time. And oop often gets in the way. I like oop for the concept of raii and stateful objects though, in all other cases i just ignore it.
@paulooliveiracastro
I can guarantee that I'm upset with performance. I literally pay hundreds of dollars for a new phone whenever it "gets slow". And I know my phone is not slow, its the software that got slower over time. I also believe that doing things more efficiently doesn't take that much more time to do. We just got lazy over time, and we also do things that actually harms our productivity for the sake of clean code.
@m4rt_
How readable code is isn't a constant thing for everyone. It's based on familiarity with that kind of code, how long you are willing to look at the code, etc. Just because you don't see it as readable when taking a glance at it doesn't mean it's not readable. Everything is hard to read when you aren't familiar with that thing.
@BrunoidGames
Programmers vs Developers perspective. I work with zOS assembly. We don't have a bit to waste, some routines are called more than 1 mi times per minute and computer cycles demands energy. Everything has its cost and the cost of today's extremely slow software is unimaginable. That's why I love retro game dev, I can play with z80, 6502, 68k, etc without a big company behind.
@bloody_albatross
About short functions: I never did game dev, but they say the main render loop can be a very long function. I think it was John Carmack that said that he thinks it's better to keep it all in one long function (in that case) instead of pulling out lots of tiny functions. Reason: You want to read that function top to bottom to understand how your game updates state, you don't want to jump around to many other functions and get confused. And when separating out tiny functions someone on your team will always try to call one of those where it shouldn't be (they are supposed to be only ever be called at that one place). Instead he says its better to divide that long function into sections with local scopes { } that have a comment describing what that part is doing on top. You can then collapse these blocks in your IDE, leaving only the comments and you still get that nice overview of what the function does. That kind of overview is usually the argument for small functions.
@ToBeardOrNotToBeard
Put simply, "Clean Code" as put forth by Bob Martin is a religion. It is not engineering. Statements are made with absolutely no evidence to back them up, and the result is the mess that software is in today, where everything not only runs thousands of time slower than it should (note, should, not could), but also has more bugs than ever before. All Casey is trying to do is draw attention to the notion that when it comes to the simple performance of the code, which is something that actually can be objectively measured, Clean Code introduces insane penalties. If you want to justify these penalties, you'd better be damn sure that you're actually getting something out of it, and well, you can't really argue "I read this in a book with 0 evidence" and expect to be taken seriously by somebody who is actually engaging in engineering.
@CodyEngelCodes