No... not me

the guy who made this video: https://www.youtube.com/watch?v=443UNeGrFoM

It is awesome! You should watch. At least I think :)

While I was already aware/agreed with a lot of what he said, there were a few nuggets in there I didn't really think of before. Overall I enjoyed watching it. Thanks for the post!

Thanks. I also enjoyed his talk on how he gets ideas.
https://www.youtube.com/watch?v=MJmqaWq7PJY

Along similar lines there is this one:
Design Discussion with Casey Muratori
https://www.youtube.com/watch?v=rowyZyVrFHI


Thanks to your post I also found this list. It has a few vids I've seen which are really good, so perhaps the rest are good too.

http://www.opowell.com/post/talks...he-way-i-think-about-programming/

The Jon Blow talk is an oldie but a goodie, I'd not seen before. How to optimize the time you spend working on a project.

Awesome!

Did not know about these ones. Thank you too!

His argument against operator overloading didn't convince me to abandon C++. I just read the documentation before using an operator like with all other functions. When a math formula gets really complex, the neatness of infix operations with the same performance as handwritten SIMD intrinsics wins me over, even if I have to maintain the code a little more to use C++.

Debuggers may or may not find memory errors, because only your program knows which part of the array is padding and which is actually being used. If your code always writes one element outside the collection but you have lots of padding elements for speed, you will not notice the bug until the program reallocates. The array may even be inside of an arena allocator, in which most out-of-bound writes are valid according to the language and debugger. I use C++ pointer classes that are optimized into plain raw pointers in release mode, but have additional inner bounds for catching bugs early in debug mode. Throwing an error from a pointer class before the invalid action is performed, is more well defined for error handling than a segfault signal, that may or may not be caught by the program when turning off hardware and saving a crash report.

"Small house with big mountain"
That's certainly what I do when my library is 200 times as big as my programs.

"Fix it now"
Not so easy if the company is following "lean startup" and promoting products that were made up during meetings with customers. Then you have until the end of the day to complete it. Have to skip all documentation, code style and regression tests that can be done later. Once you know that the MVP was kept in the portfolio, you can begin writing the real version from scratch.

"Most UI libs work like this"
Mine just has a single line loading the interface from a scalable layout file before binding lambda actions by name.
Trying to intercept clicks in the same loop as drawing like he did, will probably not look as nice when using containers, tabs, indexed buttons, dynamic loading of extensions, layouts for different countries and multiple event types.

John Carmack didn't claim to have written the square root function. It works because floats contain an exponent, which can be used to initialize a square root approximation.

Dawoodoz
If your code always writes one element outside the collection but you have lots of padding elements for speed, you will not notice the bug until the program reallocates. The array may even be inside of an arena allocator, in which most out-of-bound writes are valid according to the language and debugger. I use C++ pointer classes that are optimized into plain raw pointers in release mode, but have additional inner bounds for catching bugs early in debug mode. Throwing an error from a pointer class before the invalid action is performed, is more well defined for error handling than a segfault signal, that may or may not be caught by the program when turning off hardware and saving a crash report.

Instead of all this manual work or wrappers you could simply use modern compiler features like Address Sanitizer. It automatically will check that pointer dereference is to valid/allocated memory. And it will do that without any extra work from user - you can pass pointer through countless functions, store it in heap and get it back later, offset by some amount - and runtime will still check that it is valid once it is dereferenced. And error message it will produce will be way friendlier than any manual wrapper can do, as it will tell location of both - where the invalid dereference happens, and where the original allocation happened. It's super useful in both - C and C++.

Dawoodoz
His argument against operator overloading didn't convince me to abandon C++. I just read the documentation before using an operator like with all other functions. When a math formula gets really complex, the neatness of infix operations with the same performance as handwritten SIMD intrinsics wins me over, even if I have to maintain the code a little more to use C++.

He has dyslexia. He also says he likes long function names, the longer the better, so perhaps long function names helps him.

I would prefer to stay with C, but Casey is right, operator overloading and function overloading collapses some things down, so they are easier to read.

mmozeiko

Instead of all this manual work or wrappers you could simply use modern compiler features like Address Sanitizer. It automatically will check that pointer dereference is to valid/allocated memory. And it will do that without any extra work from user - you can pass pointer through countless functions, store it in heap and get it back later, offset by some amount - and runtime will still check that it is valid once it is dereferenced. And error message it will produce will be way friendlier than any manual wrapper can do, as it will tell location of both - where the invalid dereference happens, and where the original allocation happened. It's super useful in both - C and C++.

Sure, but my point was that the compiler and its tools only know the bound of actual memory allocations, so it will take longer before the bug is detected from an actual invalid access due to padding. C++ template collections and such allow considering the tighter length variable when checking for out of bound errors as soon as a potentially dangerous access is detected. Being inside of the same valid allocation can still be a memory error if the same bug eventually goes outside the real allocation. Just like you want to detect memory leaks before actually running out of memory. If your algorithm goes out of bound once in a thousand times and it's only without padding once in a thousand times, the error will only happen once in a million times and be very hard to track down.