Conversation

Notices

1. Embed this notice
   novatorine 🏴🏳️‍⚧️ (anarchopunk_girl@kolektiva.social)'s status on Wednesday, 16-Aug-2023 21:45:56 JST novatorine 🏴🏳️‍⚧️

   I understand pure FP. I can read and write pure FP just fine and I get all the concepts. I know what a Monad is.

   I just fucking hate actually writing pure FP programs.

   I'll write specific functions or algorithms in pure FP style when it suits the problem at hand naturally (eg, processing data, recursion stuff), and I typically try to make sure that all mutations stay local to functions / don't cross function boundaries, and as much of the codebase as possible, especially the business logic, is side-effect free and referentially transparent (even if it performs mutations on the inside), but those flashy pure FP UI or game frameworks, or pure FP languages... Blech. They're just terrible to use. In trying to achieve purity, they usually have to be extremely abstract in a way that isn't necessary for the problem at hand, just using layers and layers of abstractions to make pure FP even possible, and they also tend to force you to shove the square peg of whatever algorithm you're working on into the round hole of pure FP when not all algorithms naturally map onto pure FP, and imo the key to good comprehensible code is making the shape of your code and its abstractions fit the natural contours of the problem you're trying to solve. Plus, like, some things just *really* don't benefit from pure FP. Doing tail call recursion when you actually just want a fucking for loop, or having your application do tail call recursion (again lol) to update the application state instead of just mutating the state directly, doesn't help at those levels of abstraction. What difference does it really make if the core loop of your application looks like (Python bc its good pseudocode:

   state = initial_state()
   while (!state.exit):
   run_app(state)

   versus:

   def loop(state):
   new_state = run_app(state)
   if !new_state.exit:
   loop(new_state)
   loop(initial_state())

   Like how is this meaningfully different? You're still effectively mutating the state, because the same variable name will now refer to a different value, you're just doing it in a ✨fancy✨ way to make you feel special, and now you've got to return descriptions of all state changes from every function and wire them all together and make sure they all flow upstream properly so you've now created infinitely more work for yourself (basically the reverse of React's fucking state management issues).

   I could go into a ton of gritty detail with this, and *trust me* I've fucking done my time with pure FP and thinking it was the best thing ever, I know my shit, but it's just... not all its cracked up to be. A little bit of it here and there? Even a lot, to inform your code design decisions? Sure. But like, as a paradigm you have to wrap everything around it isn't ideal. I honestly much prefer struct-oriented and compression-oriented practical procedural programming with lots of FP sprinkled on top.

   • Embed this notice
     novatorine 🏴🏳️‍⚧️ (anarchopunk_girl@kolektiva.social)'s status on Wednesday, 16-Aug-2023 22:01:01 JST novatorine 🏴🏳️‍⚧️

     in reply to

     Like I've gone on extensive infodumps to my partner about how monads, higher kinded types, and the IO monad work and how fucking cool they are, but like, fuck off, this is not the one true paradigm because there IS no one true paradigm. I'm an anarchist, and that applies to my methodological approach to software too: I don't think there is one true correct way to do everything that's always better in all situations, some ultimate paradigm od plan, whether IRL or in programming, because that's a fucking spook, I think that the right answer for any situation is highly contextual and embedded in the particularity of that situation and is best decided by the people directly involved in the moment in light of both the specific context and the wider context and systems at work.

     So sometimes modeling the problem as structs (or components) that encapsulate some state and some behavior and change over time just describes things more naturally. Not all the time, and inheritance is horrible and we should use composition and interfaces instead, but most of the time that's a much more natural paradigm for modeling certain kinds of things. And sometimes it's best to use pure functional paradigms. And sometimes it's best to use entity component systems. Sometimes an imperative loop is what you want, and sometimes (probably most times), map, foldl, etc are what you want.

     Ultimately, the way I program, I tend to write out all the code to do what I want directly, and then I look carefully and find all the duplicated code and code structures and then use *whatever* abstractions will most naturally factor out the duplication into a conceptually clean abstraction that mirrors just exactly what was actually necessary and repeated, with just enough future flexibility to not lock you in. And I think that's much better than starting out with some specific set of abstractions you want to use, and, like someone with a hammer thinking everything is a nail, trying to force that one set of abstractions on everything. Or trying to start with abstractions first, and build the best most extensible abstraction for something possible without knowing in advance what the actual use cases practically speaking will be. That's not clever, that's very silly and rigid.

   • Embed this notice
     unrelatedwaffle (unrelatedwaffle@kolektiva.social)'s status on Wednesday, 16-Aug-2023 22:10:40 JST unrelatedwaffle

     in reply to

     @anarchopunk_girl 💯 yes. concrete --> abstract is the way. i think of it as analogous to learning a grammatical rule in language. memorizing verb endings and trying to apply it consciously ahead of time will not make it gel. you gotta just let the pattern recognition part of your brain do its thing.

   • Embed this notice
     novatorine 🏴🏳️‍⚧️ (anarchopunk_girl@kolektiva.social)'s status on Wednesday, 16-Aug-2023 22:14:43 JST novatorine 🏴🏳️‍⚧️

     in reply to

     Also, to add, like — I already model whatever problem I'm working on using types and function type signatures, break up what needs to be done into small take oriented referentially transparent, side effect free functions, limit actual mutation (mutation that isn't extremely localized and small) and side effects, etc before I start coding. I constantly use recursive sum and product types (ala Rust's enums and immutable structs). So idk what extra benefit I'd get from going pure FP besides more mental effort.