Great talk. "Separating calculating from doing" is a very valuable guideline. It has been in the back of my mind for a while but was never able to express it clearly. Hilarious story with the dog and the fridge, this is something you really see everywhere and it always ends up in a mess :D
He has a point. Seems like Sean Parent only gives talks that leave people silent and then causes a lot of discussion. Also putting Wind waker clips in the middle negates any critique one might have.
30:31 They are different. If Orientation on the left is a typedef for a basic type (double, for example), it can be stored in a register. On the right, even if it has a single member of that type, it cannot be stored in a register, or passed to a function in a register.
That's not strictly true, it depends on the ABI. Since it would have a trivial destructor, the ABI on every platform except for Windows would allow it to be passed in a register
18:22 I like to pass references instead of not nullable pointers, even if that looks strange in that instance. It just makes it clear for the reader that null is not accepted here, because null references are evil. (Although I've heard of a C++ codebase that null-checks references.) In this case, it could probably even be a const ref, since we're just reading from Projector.
Checking for null references is a fundamental misunderstanding of the language. It's not impossible to have a null reference. In order to have one, you would have to dereference a null pointer, which we all know blows up. Now it's very possible to have a DANGLING reference, but there's no way to check for that
I liked the talk. I have one question though, or perhaps an issue I'd like to raise, hopefully the speaker can address it. at 55:52 - "expect it would return the result". Even though this is (personally) preferable, because it makes the code easier to read, doesn't this make it a lot harder to allow for control of memory allocations? That's at least the issue I seem to run into, all the time, when thinking about value semantics or value oriented programming. It ends up being, so many spurious allocations all over the place, _because_ we return results from functions. I'm not fond of output parameters either, I think they make it a bit "harder" (not harder, really, but it might take longer time) to reason about code, but it does allow for the caller to control what memory is being used, how much gets pre-allocated so on and so forth. From a "value oriented programming"-perspective, what would be the solution for this?
Interesting talk although I would actually argue this often produces horrible code to read. If I have to jump through 15 layers of functions to find the business logic i'm going to have a much harder time modeling the scope of the program in my head.
You usually want to define a lot of smaller functions but then use them at mostly the same level in kind of a pipeline manner. Deep call graphs are indeed pretty bad
Great talk. "Separating calculating from doing" is a very valuable guideline. It has been in the back of my mind for a while but was never able to express it clearly. Hilarious story with the dog and the fridge, this is something you really see everywhere and it always ends up in a mess :D
Amazing, wise and fun talk with explanation and arguments for presented opinions.
Can't wait to watch part V.
He has a point. Seems like Sean Parent only gives talks that leave people silent and then causes a lot of discussion. Also putting Wind waker clips in the middle negates any critique one might have.
Love Sean Parent. Why is the original talk no longer available? How awful. He gave a version at Google which you can find.
30:31 They are different. If Orientation on the left is a typedef for a basic type (double, for example), it can be stored in a register. On the right, even if it has a single member of that type, it cannot be stored in a register, or passed to a function in a register.
That's not strictly true, it depends on the ABI.
Since it would have a trivial destructor, the ABI on every platform except for Windows would allow it to be passed in a register
18:22 I like to pass references instead of not nullable pointers, even if that looks strange in that instance. It just makes it clear for the reader that null is not accepted here, because null references are evil. (Although I've heard of a C++ codebase that null-checks references.) In this case, it could probably even be a const ref, since we're just reading from Projector.
Checking for null references is a fundamental misunderstanding of the language.
It's not impossible to have a null reference. In order to have one, you would have to dereference a null pointer, which we all know blows up.
Now it's very possible to have a DANGLING reference, but there's no way to check for that
I liked the talk. I have one question though, or perhaps an issue I'd like to raise, hopefully the speaker can address it. at 55:52 - "expect it would return the result". Even though this is (personally) preferable, because it makes the code easier to read, doesn't this make it a lot harder to allow for control of memory allocations? That's at least the issue I seem to run into, all the time, when thinking about value semantics or value oriented programming. It ends up being, so many spurious allocations all over the place, _because_ we return results from functions.
I'm not fond of output parameters either, I think they make it a bit "harder" (not harder, really, but it might take longer time) to reason about code, but it does allow for the caller to control what memory is being used, how much gets pre-allocated so on and so forth.
From a "value oriented programming"-perspective, what would be the solution for this?
Interesting talk although I would actually argue this often produces horrible code to read. If I have to jump through 15 layers of functions to find the business logic i'm going to have a much harder time modeling the scope of the program in my head.
You usually want to define a lot of smaller functions but then use them at mostly the same level in kind of a pipeline manner. Deep call graphs are indeed pretty bad