Value Oriented Programming. Part 1: You Say You Want To Write A Function - Tony Van Eerd CppNorth 22
Vložit
- čas přidán 19. 08. 2022
- CppNorth Twitter: / cppnorth
CppNorth Website: cppnorth.ca/
---
Value Oriented Programming. Part 1: You Say You Want To Write A Function - Tony Van Eerd - CppNorth 2022
Slides:github.com/CppNorth/CppNorth_...
CppNorth 2022 video sponsors:
think-cell: www.think-cell.com/en/
Adobe: cppatadobe.splashthat.com/
Aaahhh!
You say you want to write a function....
TL;DR. This is a talk about functions. We all write them, but look around, most are bad. Can we do better?
Aaahhh!
You say you want to write a function
Well, you know
We all want to change the code
You tell me that it's evolution
Well, you know
We all want to change the code
But when you talk about member functions
Don't you know that you can count me out?
Don't you know it's gonna be
All right
All right
All right
You say you got a real solution
Well, you know
We'd all love to see the plan
You ask me for a contribution
Well, you know
We all doing what we can
But if you want money for params with all that state
All I can tell you is, developer, you have to wait
Don't you know it's gonna be
All right
All right
All right
You say you'll change the param direction
Well, you know
We all want to change your head
You tell me it's the common solution
Well, you know
You'd better free your mind instead
But if you are still writing functions that return void now
You ain't gonna make it with anyone anyhow
Don't you know it's gonna be
All right
All right
All right
All right, all right, all right
All right, all right, all right
All right, all right
---
Tony Van Eerd
Stunt-double for C++ Expert, Christie Digital
Tony has been coding for well over 25 years, and hopefully coding well for most of that. Previously at Inscriber, Adobe, and BlackBerry, he now enables painting with light at Christie Digital. He is on the C++ Committee. He is a Ninja and a Jedi.
Follow @tvaneerd
---
CZcams Channel Managed By Digital Medium Ltd: events.digital-medium.co.uk
---
#Programming #Cpp #CppNorth - Věda a technologie
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.
I loved the step by step walkthrough. Great speaker!
That’s an exceptionally good talk. Thanks a lot !
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).
Tony's next talk will be: Function Oriented Programming.
hmmm, have you seen the preview I recorded for this talk? czcams.com/video/OD0YMc-_50c/video.html
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 :)
Enjoyable presentation with some well known but, nevertheless, needed reminders on good coding principles.
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 :(
I say I want to right a function.
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.
Is there a part 2?
There will be. At the next CppNorth. (Hopefully)
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: czcams.com/video/LKtk3HCgTa8/video.html
It really is a good talk.
While you are at it, also Rich Hickey: The Value of Values czcams.com/video/-6BsiVyC1kM/video.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.