Thanks Tony, this is a great talk! You've managed to explain brilliant techniques in such a way that it sounds "too simple" to be true - it's like you've refactored a more complex talk to be as simple as possible to understand while conveying exactly the same information.
This talk takes a long time to actually get rolling but it eventually narrows down on a set of incredibly important points in a very easy to understand way.
A talk that is both enjoyable and insightful. I remember the "projectorFacingNorth - don't open the fridge" part from a previous talk from Tony. That 5-minutes part had struck me as especially deep advice in its simplicity. I'm happy to see it expanded a lot in this talk. Thanks Tony for the great advice!
@@metal571 Yeah, I've seen it too :) I think it is in that one that I was exposed to the "projectorFacingNorth - don't open the fridge" statement the first time.
Using inheritance from base-classes just for code reuse is indeed a rabbit hole you don't want to go into. About Directional devices, I usually opt for an interface (abstract baseclass) and have a CRTP implementation of the interface that I can mix-in (which may call free functions).
This talk helped me, though you might not expect how. It made me understand why so many people still insist that Ackermann's function cannot be made iterative/tail recursive. They want to see the input as two numbers instead of a stack with 1 or more numbers on it. They want to see only values, not structures. The function does not have to modify the stack, as I got the idea from Haskell (proper functional lists are basically stacks - change my mind). Then again, they also refuse to write helper functions (one which takes the two numbers and one which does the tail recursion on a stack), so maybe I still don't get it. Anyways - Great talk and good explanation of the value oriented world. Thanks :)
There is still a smaller part of the Sneetch that should be passed on to the function to calculate the position of the stars. :) (Probably only its geometry)
Very enjoyable presentation, but the line at 3:04 is disputed ... you should use Rotors from Geometric Algebra, they're isomorphic to quaternions but are actually intuitive for our feeble human minds ;)
Overall a good talk, but there are some footnotes: 8:20 and 49:25, good and old utopia of getting rid of complex code by putting it away... just to go on that away to face it once again. Plus, if proj is hard to copy, and that f() can't be inlined, a ref./pointer will be passed, which is not for the optimizer taste. 26:00, sometimes f()s like that calcStarPos only makes sense inside StarOn - too technical. Making a f() out of it, gives the chance to call it by mistake. To avoid that, maybe a class will need to wrap all of this, putting the new f() on nonpublic area. It's questionable if the costs are worth. 40:40, this is a simple example, of course it's destined to be a struct. But I saw several cases in which a class, even having just 1 variable, even a byte, it should be read most of the time, having to be changed in a few f()s. For this case, a class is much preferred. Or even for that point class struct, if x,y change in a special way, different from other x,y from the project, member f()s may be useful. 57:20, let's say this get-f() is critical to security. Here you have only 1 f()/class that has access to it. If this pointer was received by parameter, then you would have 2 f()s accessing that data. And if it returns that data, a potentially 3rd f() should be friend of the class. I know there should be some part of this current f() that could actually be separated as a data creator-only. But the 1st part of it has to receive and delete the data, because it's a reloader.
2 роки тому+2
Enjoyable presentation with some well known but, nevertheless, needed reminders on good coding principles.
at 6:20 he talks about rich hickey's clojure simple made easy talk and says go watch it but not right now and then talks about a 5min talk in which he says the same thing lol it has to be an elaborate joke only people who go click the lightning talk while watching his talk will understand
Simple Made Easy: ua-cam.com/video/LKtk3HCgTa8/v-deo.html It really is a good talk. While you are at it, also Rich Hickey: The Value of Values ua-cam.com/video/-6BsiVyC1kM/v-deo.html you should go watch them now
9:35 oh, look at you, with your strongly-typed languages and function overloading. "what's that? `def to_string(value: int)`? sorry, there's already a `to_string` in this scope"
I'm sure I read some blog or book years ago exhorting us to write "string_from_int" instead of "int_to_string" because it puts "int" next to the int parameter and "string" next to whatever is needing a string
@@RoamingAdhocrat I'm a big fan of "from" particularly when you have (unfortunately) a param that is the output. string_from_int(string &, int). Because the thing being modified should be the first param (or really the return value, but if for some reason that is not an option, then it should be the first param. And "from" then makes the function name order match the param order.
For the first example, the solution is a function bool Projector::FacesNorth(); No function is in the global namespace. Then for the second, the solution is bool Orientation::FacesNorth(double or float tolerance); To use then, the code is like: if(proj.FacesNorth()){...} or if(proj.orientation().FacesNorth()){...} This is still pure OOP. No comment is needed. 27:46 pure functions are not guaranteed to be thread safe. If they read some value, and some other threads are modifying these values at the same time, oops. I think I should stop here. A lot people don't like OOP while have very limited idea of OOP. This is a problem.
I think I explain why Projector::FacesNorth() is not a good idea. It leads to complecting - I explain it in the talk. As another example, should all functions involving strings be member functions of strings? (I ask this in the talk) And I mention that pure functions are not guaranteed to be thread safe because of that reason, although I didn't go over it explicitly, just a quick comment. You are probably right, it is a very important point, I should have been more clear. I hope you are not assuming I don't understand OOP. The question is when is it the best solution vs an OK solution vs the only solution. It is not the only solution. EDIT: see also Scott Meyers - How Non-Member Functions Improve Encapsulation www.aristeia.com/Papers/CUJ_Feb_2000.pdf
It's interesting you mention thread safety, OOP is explicitly not thread safe, so I don't know if I am missing something in the video, because due to the lifetimes problem inherent to OOP, this is more true for OOP than any other paradigm. The main problem I have with OOP is that it is applied all over the place when it really should only ever be used in a pretty limited fashion. Functions in the global namespace are also one of the most (if not *the* most) easiest programming constructs to reason about. They are also optimized better in some cases due to not having an implicit this pointer. This is only for edge cases though, but I have seen optimizers doing a better job in GDB for instance, using a free function.
That Tony guy is a really handsome man, why don't we see him in the video?
Thanks Tony, this is a great talk!
You've managed to explain brilliant techniques in such a way that it sounds "too simple" to be true - it's like you've refactored a more complex talk to be as simple as possible to understand while conveying exactly the same information.
This talk takes a long time to actually get rolling but it eventually narrows down on a set of incredibly important points in a very easy to understand way.
A talk that is both enjoyable and insightful. I remember the "projectorFacingNorth - don't open the fridge" part from a previous talk from Tony. That 5-minutes part had struck me as especially deep advice in its simplicity. I'm happy to see it expanded a lot in this talk. Thanks Tony for the great advice!
If you haven't already seen it, check out his talk, Postmodern C++. It might just be the most entertaining one I've ever seen
@@metal571 Yeah, I've seen it too :) I think it is in that one that I was exposed to the "projectorFacingNorth - don't open the fridge" statement the first time.
Using inheritance from base-classes just for code reuse is indeed a rabbit hole you don't want to go into. About Directional devices, I usually opt for an interface (abstract baseclass) and have a CRTP implementation of the interface that I can mix-in (which may call free functions).
That’s an exceptionally good talk. Thanks a lot !
This talk helped me, though you might not expect how.
It made me understand why so many people still insist that Ackermann's function cannot be made iterative/tail recursive. They want to see the input as two numbers instead of a stack with 1 or more numbers on it. They want to see only values, not structures. The function does not have to modify the stack, as I got the idea from Haskell (proper functional lists are basically stacks - change my mind).
Then again, they also refuse to write helper functions (one which takes the two numbers and one which does the tail recursion on a stack), so maybe I still don't get it.
Anyways - Great talk and good explanation of the value oriented world. Thanks :)
I loved the step by step walkthrough. Great speaker!
There is still a smaller part of the Sneetch that should be passed on to the function to calculate the position of the stars. :) (Probably only its geometry)
yeah, I should follow my own advice there!
Very enjoyable presentation, but the line at 3:04 is disputed ... you should use Rotors from Geometric Algebra, they're isomorphic to quaternions but are actually intuitive for our feeble human minds ;)
namespace collision when working on flight simulators, sadly :(
Tony's next talk will be: Function Oriented Programming.
hmmm, have you seen the preview I recorded for this talk? ua-cam.com/video/OD0YMc-_50c/v-deo.html
Overall a good talk, but there are some footnotes:
8:20 and 49:25, good and old utopia of getting rid of complex code by putting it away... just to go on that away to face it once again. Plus, if proj is hard to copy, and that f() can't be inlined, a ref./pointer will be passed, which is not for the optimizer taste.
26:00, sometimes f()s like that calcStarPos only makes sense inside StarOn - too technical. Making a f() out of it, gives the chance to call it by mistake. To avoid that, maybe a class will need to wrap all of this, putting the new f() on nonpublic area. It's questionable if the costs are worth.
40:40, this is a simple example, of course it's destined to be a struct. But I saw several cases in which a class, even having just 1 variable, even a byte, it should be read most of the time, having to be changed in a few f()s. For this case, a class is much preferred. Or even for that point class struct, if x,y change in a special way, different from other x,y from the project, member f()s may be useful.
57:20, let's say this get-f() is critical to security. Here you have only 1 f()/class that has access to it. If this pointer was received by parameter, then you would have 2 f()s accessing that data. And if it returns that data, a potentially 3rd f() should be friend of the class.
I know there should be some part of this current f() that could actually be separated as a data creator-only. But the 1st part of it has to receive and delete the data, because it's a reloader.
Enjoyable presentation with some well known but, nevertheless, needed reminders on good coding principles.
Is there a part 2?
There will be. At the next CppNorth. (Hopefully)
I say I want to right a function.
at 6:20 he talks about rich hickey's clojure simple made easy talk and says go watch it but not right now and then talks about a 5min talk in which he says the same thing lol
it has to be an elaborate joke only people who go click the lightning talk while watching his talk will understand
Simple Made Easy: ua-cam.com/video/LKtk3HCgTa8/v-deo.html
It really is a good talk.
While you are at it, also Rich Hickey: The Value of Values ua-cam.com/video/-6BsiVyC1kM/v-deo.html
you should go watch them
now
Why parent class constructors are executed first and then child?
Same reason you build the foundation of a house before the walls?
9:35 oh, look at you, with your strongly-typed languages and function overloading. "what's that? `def to_string(value: int)`? sorry, there's already a `to_string` in this scope"
I'm sure I read some blog or book years ago exhorting us to write "string_from_int" instead of "int_to_string" because it puts "int" next to the int parameter and "string" next to whatever is needing a string
@@RoamingAdhocrat I'm a big fan of "from" particularly when you have (unfortunately) a param that is the output. string_from_int(string &, int).
Because the thing being modified should be the first param (or really the return value, but if for some reason that is not an option, then it should be the first param.
And "from" then makes the function name order match the param order.
For the first example, the solution is a function bool Projector::FacesNorth(); No function is in the global namespace.
Then for the second, the solution is bool Orientation::FacesNorth(double or float tolerance);
To use then, the code is like:
if(proj.FacesNorth()){...}
or
if(proj.orientation().FacesNorth()){...}
This is still pure OOP. No comment is needed.
27:46 pure functions are not guaranteed to be thread safe. If they read some value, and some other threads are modifying these values at the same time, oops.
I think I should stop here.
A lot people don't like OOP while have very limited idea of OOP. This is a problem.
I think I explain why Projector::FacesNorth() is not a good idea. It leads to complecting - I explain it in the talk. As another example, should all functions involving strings be member functions of strings? (I ask this in the talk)
And I mention that pure functions are not guaranteed to be thread safe because of that reason, although I didn't go over it explicitly, just a quick comment. You are probably right, it is a very important point, I should have been more clear.
I hope you are not assuming I don't understand OOP. The question is when is it the best solution vs an OK solution vs the only solution. It is not the only solution.
EDIT: see also Scott Meyers - How Non-Member Functions Improve Encapsulation www.aristeia.com/Papers/CUJ_Feb_2000.pdf
It's interesting you mention thread safety, OOP is explicitly not thread safe, so I don't know if I am missing something in the video, because due to the lifetimes problem inherent to OOP, this is more true for OOP than any other paradigm.
The main problem I have with OOP is that it is applied all over the place when it really should only ever be used in a pretty limited fashion.
Functions in the global namespace are also one of the most (if not *the* most) easiest programming constructs to reason about. They are also optimized better in some cases due to not having an implicit this pointer. This is only for edge cases though, but I have seen optimizers doing a better job in GDB for instance, using a free function.