I lived in a perfect OOP bubble for my entire life. Everything was peaceful and it worked perfectly. When I wanted to move that player, I do player.move(10.0, 0.0); When I want to collect a coin, I go GameMan -> collect_coin(); And when I really need a global method, so be it. I love my C++, I love my python and yes, I also love my GDScript (Godot Game Engine). They all work with classes and objects and it all works perfectly for me.
But oh no! I wanted to learn Rust recently and I really liked how values are non-mutable by defualt and such, but it doesn't have classes!? What's going on? How do you even move a player? Do you just HAVE to have a global method for everything? like move_player(); rotate_player(); player_collect_coin(); But no! Even worse! How do you even know which player is meant? Do you just HAVE to pass the player (which is a struct probably) like this? move(player); rotate(player); collect_coin(player, coin); I do not want to live in a world where everything has to be global! I want my data to be organized and to be able to call my methods WHERE I need them, not where they just lie there, waiting to be used in the global scope.
So please, dear C, Rust and... other non OOP language users! Tell me, what makes you stay with these languages? And what is that coding style even called? Is that the "pure functional style" I heard about some time?
Also what text editor do you use (non judgemental)? Vim user here
My dear friend - what if I told you that every call to Player.move should return an entirely new instance of a Player? One with an immutable position, and a helper function that takes a position delta - and constructs yet another Player!
What if I told you that all user interfaces are a function of application state; and all interactions apply a transformation that is then re-rendered? (We have gotten very good at only re-rendering the parts that change.)
Welcome to FP! There’s a whole world here for you to explore. You’ll be telling your friends about monoids and endofunctors before you know it :)
Constricting a new player for every movement seems a bit excessive and slow because of memory, but I'm on board. Our teacher always told us that hoping around in memory is bad tho
Your compiler is allowed to optimize things tho
Ok fair. Didn't think about that. I always think that for these kinda of low level optimisations one needs to tell the computer -hey, I'm creating a new object which has the same type and most parameters are the same BESIDES this one variable-
Well, if your compiler knows the old value is unused afterwards, it can just modify the parameters you want and return the object as is. And if you're really manipulating non-mutable objects, shallow copies should be enough to replicate an object + a few modifications. I don't have everything in mind but once the semantics of your program has been checked by the compiler and it starts emitting lower-level code, it can cheat a lot to optimize things out
Lol this is the wrinkle - FP is great for humans, but under the hood, what is memory but a big block of mutable state? Sometimes we have to dig into the specifics for performance.
That being said - Rust knows that the instance of Player passed in is the only reference, and it can re-use that memory - maybe even mutate it in-place ;) while still presenting an FP interface to the user.
You know, I'd been meaning to try out functional programming languages one of these days, but you've just about cured it. That's horrifying.
If you're used to it, it works fine. The thing is that everything is immutable, so having tons of copies doesn't matter in terms of incorrect state between threads (just don't actively hold onto old copies).
Performance certainly does suffer to some degree, but that's single-core performance. Where FP really shines is that you can very easily parallelize everything.
Not as “horrifying” as you make it sound. However, it does rely quite a bit on compiler optimizations. Haskell uses this approach a lot: Rust, however, very rarely does.