A lot of talking without saying anything.

I don't understand how so many people in the development space let their emotions cloud their judgment. Clean code makes sense in certain environments. Many of the variables in our real time jobs are out of our control. Focus on what pros and cons you get with clean code, as with any tool or language, you can also opt to use just some if it, if it is not obvious enough... See if it fits your goals, and is feasible. Is hard for many people, I get that.

It probably shouldn't be impossible to write a program where you pass to it clean code and it makes into efficiently compliable procedural?

You're right about the rhetoric! It's everywhere. Right on front of the book is this manipulative beauty: "Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best.". Translation: either obey our rules or be expelled from the industry!

You seem to be a bit lost in this video, your counter arguments are sooo vague and fingery fluffy. I am not pro any side, but man brush up your rethoric / arguments.

looks absolutely amazing!

I suspect that people who "prefer polymorphism" have never used a language that supports tagged unions (sum types)

If you see similar large switch statements that cover the same cases in multiple files within the codebase, that’s usually a code smell that the code can be refactored using dependency inversion. Since the switch is both large and in separate files, the refactor would result in much more code cohesion in the end. Basically if you liked having all the code in one function then why would you prefer the code to be in multiple files instead of one.

I find both sides tend to miss the forest for the trees. On the topic of small functions, the goal of being small is the wrong goal to have, it should be comprehensible. When abstracting code into more functions, do so when you can give it a very clear name as to what it’s not only responsible for but what it wouldn’t be responsible for. That way when ppl read your code, drilling into a function is done because they know the answer lies inside. This allows the search to be a log n search as opposed to a depth first search.

You lost me at 10,000 line functions. If you are writing code for your own hobby, sure. Not when you are expecting other people to have to maintain your code.

LMAX is an example of high-performant OOP code. It's not a Robert C. Martin example, but nevertheless I would argue it achieved this objective. I think the issue is that both sides do have arguments, and Robert C. Martin "yells" loudly about Cleancode especially when he himself didn't practice it when he first started programming. But now he has seen the light at the end of the tunnel for quite a long while and advocates for cleancode. One discrepancy I would point out is that there is somewhat of a consensus between older developers that there is a general style that exists that is better. Martin Fowler, Dave Farley, many other decades-old developers. Nobody is truly wrong, I would say many people have parallel thinking when you compare in nuance the individual smells. There are few hard-and-fast rules on either side.

you should stop the bla bla bla and you should just do something! what about creating a new compiler and a new language? If you try to make it then I doubt you would go and start crying in a corner and would just go back to C++ right away and you would never ever dare complain about C or C++ again. You stand on the shoulders of giants. Bla bla bla C and C++ is bad, bla bla skill issue.... . . . . . . . . . . what, wait a minute.... have you heard of this "better C alternative", Odin? ;)

Martin is a classic primary psychopath. A shameless manipulative confident liar. So everything he does is dishonest useless or stolen from someone else.

Looks like Vincent van Gogh and Bill Burr had a child.

His book on professionalism was actually good.

I remember it used to be called "snake oil" and Mr. Martin would have been called "snake oil salesman". Now it looks like he and his kind have won.

I am very surprised Uncle Bob actually knows how to use Git. I've worked with his devout followers in various companies and most of them wrote shitty littly Java applets or whatever in 2001 and since then have been pushing sticky papers and Jira issues. Bob hasn't written anything of any importance and does not develop anything in open source mode, so all his bullshit is unverifiable. I would much rather take advice on programming from thousands of people on Github who wrangle dozen different languages in dozens of public projects that are visible commit-per-commit than some boomer that allegedly wrote Java in a corporation twenty years ago. The entire 'discussion' is unbelievable pie of bullshit that Casey had to endure.

bill is either being disingenous at worst or he has swollen his own coolaid at best. neither of which are good. this reminds me of when you criticize a piece of media and then a bunch of people who really liked that piece of art dismiss every single criticism you have of it.

I'll be honest: I did not like this video (I could not watch in full, I probably won't try again, I still might watch & like your other content) but the comment section is -- no sarcasm -- one of the best I've seen on YT.

Would love to see your comparison on cpp2/cppfront as well

Odin is definitely better :D

Bob's regex was some real old-school C hacker shit. I have to say he's gained my respect now

Could you make a YT playlist of the Dunjan Days? 😊

It is surprising that people are already hiring for Carbon and it looks like it is not what it seems. Is it like Typenscript after they Made C#?

i think google just want to hold the power

Nice thanks for your comments. May I ask a question about thr designt choice of the for loop? I like that there is only one loop type, but I wonder why you did not use "foreach" for the "for in" loop and the normal "for int i..." loop for the rest. (So many for xD)

Odin compiler go brrrrrrrr... :)

13 year old video of 2 funny English people playing Minecraft together? Yes please! Also, hey, I am also making a compiled programming language. I am making mine in such a way where writing a 3rd party compiler is trivially easy. I am using QBE as the official implementation until I write a compiler backend myself. I am using QBE instead of LLVM because LLVM is sooooo bloated! 😆

In the U.S. it has become standard practice for poloticians to name bills in such a manner that it rarely has any real resemblance to the actual content of the bill but, provides a title that is misleading but easily defended by those less informed! This is a practice I think should be stopped but when you have to foxes guarding the hen house, its not likely anyone will vote to get a guard dog...

You can hate Robert Martin as much as you want but the video from Muratori is just stupid. Clean Code is for "enterprisey" code and he "debunks" it using a HPC example. Everyone knows polymorphism has some overhead, of course calling a virtual method zillions of times would be slower than conditional/procedural code. The problem is: no one fucking cares, if the problem being solved doesn't run in a loop a zillion times and does IO stuff who the fucks care about picoseconds being "wasted" in dynamic dispatch. If Muratori was right in this debate, no one would even use Javascript/PHP/Python/Ruby, because all that matters is raw performance when running HPC code.

I still don't understand why Mr. Martin trademarked coding common senses. And some of his takes are just plain stupid.

Ugh I really hate the snarky response to the question how do you measure code readability. By reading it? Really? In that case, readable code is code with zero comments (yes, really, programmers tend to be terrible at getting their point across in English, but programming languages are much more strict and well defined, so it's much easier to just read their code rather than their descriptions of their code), no templates, no operator overloads, no exceptions, no inheritance, no constructors/destructors and definitely no splitting logical, coherent code blocks into smaller functions, even if the original block is a thousand lines long. All of these things make code extremely difficult to read. I wonder if Mr Bob would agree with his own answer in that light?

Oh, how easy it is to switch from using Go to Odin. Almost as if i don't have to learn a new language syntax, so I can focus immediately on semantics. It is, too, very intuitive. A remark on syntax: Why do you need right arrow in front of the output types in a procedure signature? Why not omitting it?

I watched the video to hear something about this Carbon language, but instead I realized that Odin is fantastic for my purposes, and in general. I am currently using Go and I like it. (I am not a programmer, but a scientist who wants to make custom tools for my projects, that's why I am using programming, but I also wanted to know a highly performant, safetype, general purpose, non-OOP language, easy to learn, and so I chose Go over Julia or Python) Now, with Odin, I don't need to write my own matrix package in Go (although I've written quite a bit of it already) . So nice to have it built into the language itself. Element-wise operations on arrays are a candy :D Q: How would you rate Odin's performance compared to Go on one hand, and Rust, on the other?

Many devs work in a company where there is a large code base in C++. Yes you can have C wrappers and yes you can then use other languages for new projects. But typically for successful big products there is no budget nor time to easily rewrite all of that and so you're stuck with C++. While C++ added nice features, the defaults, the signal to noise ratio, looking at you [[nodiscard]], and all the stuff you have to know you're supposed NOT to use make it no fun. Especially not when working with rather big teams where everyone has an opinion on what correct C++ is. :) So yes if this was production ready I would try it. BTW Cpp2 is another way around these C++ issues.

I know this map. I miss the game. Let's recreate the game in Odin.

You sound like a critical thinker who sees through B.S. "He can't help himself," indeed, lol. I am incredibly tired of hearing appeals to "authority," but I'm also getting a bit jaded about "data." A guy who worked at a lab employed by Pfizer said "They had us compare the short term outcomes for 100,000 vaccinated and 100,-000 people who took a different (non-mrna) vaccine with a known risk profile (not an actual placebo) and take the 1000 best results from the vaccinated group and the 1000 worst from the 'placebo' group and present that to the CDC and to the public as a study of 1000 people." (I'm paraphrasing, but that was the general gist.) Yeah, see, this is why Mark Twain said "There are lies, damned lies, and statistics."

...what? There was practically nothing about Carbon in this video at all. Was just 20 minutes of abstract rambling

it's rather anoying having not having a honest discussion, I'm more than willing to acept if I'm wrong but when I present DOD the response I get is that OOP it's good enought, or everyone uses it why change, it's some sort of lazyness if only OO was easy to write just unwillingness I guess

You can measure code quality pretty well. For some people it is actually trivial. And yes, there is data. DORA has some related numbers. However, DORA and subsequently Accelerate mainly shows you how to get and analyse the data. You, on your end, should gather only the ones which matters to you in your business context. For example: If you are building a piece of software which has an estimated lifespan of 2 years, very little fucks you need to have to give about quality. Quality metrics in relationship to clean code is directly interfaced by the amount of cognitive load an engineer must endure during development which in turn affects many other parameters. My point is, you do not have a conversation about the meta of programming with someone who did not read Accelerate or is not subscribed to the Devops research and assesment newsletter.

You can measure code quality pretty well. For some people it is actually trivial. And yes, there is data. DORA has some related numbers. However, DORA and subsequently Accelerate mainly shows you how to get and analyse the data. You, on your end, should gather only the ones which matters to you in your business context. For example: If you are building a piece of software which has an estimated lifespan of 2 years, very little fucks you need to have to give about quality. Quality metrics in relationship to clean code is directly interfaced by the amount of cognitive load an engineer must endure during development which in turn affects many other parameters.

Odin commercial yay

How much would your argument change, if we had much better compilers that optimized only for performance (i.e. Don't care about, say optimizing compile time, etc.)

Thank you for picking this old fucker apart. His principles have always been trash.

There are several problems that I have with TDD. One is that to have full test coverage on any module, you need to create numerous tests for every state *transition,* and a singular module can have *many* states. Take for example, a simple stack. Test case 1, you need to check all of the member variables to make sure that the stack is initialized properly. Test case 2, you need to check the top stack item to make sure that the program sanely handles doing so on an empty stack. Test case 3, you need to attempt to pop the stack to make sure that the program sanely handles doing so on an empty stack. Test case 4, you need to attempt to push the stack and ensure that the stack depth is properly increasing afterwards. Test case 5, you need to make sure that the item that's currently on the top of the stack is equal to the previous item. Test cases 6 and 7, you need to repeat test cases 4 and 5 to make ensure that successive pushes are working properly. Test case 8, you need to keep pushing stack items until the stack buffer is resized and then verify that the items in the newly resized buffer are all correct. That, or just to an isolated test of the stack resizing procedure. Test case 9, you need spoof the alloc function and replace it with one that fails so that you can ensure that the stack resizing function gracefully handles a failure to allocate more memory. Test case 10, you need to make sure that the item pushing also gracefully handles a failure to resize the stack buffer when needed. Test case 11, you need to pop an item off the stack and make sure that the stack depth changes appropriately. Test case 12, you need to make sure that after a pop, the new top of the stack is correct. Test case 13 and 14, you need to repeat cases 11 and 12 to ensure that successive pops work correctly. A stack is quite literally the *simplest* data structure I can think of, and yet, bar minimum, we're looking at 14 test cases with probably around 400 lines of code to test something that can be implemented in like < 10 lines of code. Imagine now, doing this for a more complicated object that has 20+ different states. If you did this for an entire project, 99.9% of your codebase would be nothing but tests. And you're spending potentially *hundreds* of hours writing code that doesn't actually deliver any features. This then leads to my second gripe, which is that the second you need to change the structure of *any* object or the behavior of *any* function at all, you need to throw out all of your old tests and write new ones. It immensely slows down the development process. Third, there's just the simple fact that many things *aren't easily testable.* Consider, for example, that you're writing a triangle rasterizer based on the Bresenham algorithm. How do you test whether or not the triangle splitting is working correctly? Do you sit down with pencil and paper, draw a diagram, work out the linear interpolation for binary floating point, and compare your hand calculated value with what the computer does for a mock triangle? Maybe. Well how do you check that there are no gaps in the seams between triangles? There's problems like this all the time, where the easiest way to test it is to just run the program and look at it with your own eyes. And keep fiddling with the algorithm until it *seems* like it's doing the correct thing.

Idk if i trust this guy about Odin. I mean, he doesn't even have 20+ years of experience with it.

I love the "type on the left, usage on the right", but is there a reason why varargs are done only on the left? For example, with print :: proc(args: ..any) --- arr := []int{1, 2, 3} print(..arr) is it simply easier to parse, or what's the reason?

Is Sublime Text your preferred editor? Any video tutorial somewhere how to setup an efficient dev environment with Sublime, debugging, syntax, lsp, etc?

Hey, this should be redone in Odin.. hehehe :)

I want to disagree with you at around 8:27... But notice I say "want to" rather than "do". I've been experimenting recently with trying to combine something like "clean code" rules to AVR assembly language. And I've been trying to keep things in SMALL well named macros and inline them all together at assembly time. And, yeah, just the other day I noticed how in several of my "lovely" little neat macros I pretty much needed to check the same flag again and again and how much more optimal the code would be if I had it all in one big "horrible" block. So, yeah, I want to disagree with you... but you're probably right... so I can't.