3 ms·

I'd be curious what your flavor of "functional programming and pure functions" is? I ask, because I used to feel very similar about the OO paradigm (it helped

I'd be curious what your flavor of "functional programming and pure functions" is? I ask, because I used to feel very similar about the OO paradigm (it helped me model the world easier, made me insufferable because of my zeal, etc). But, I had the privilege of doing that with nearly 20 years of Smalltalk. A battle worn path of ObjectiveC, Swift, Java, Python, Kotlin, and JavaScript later, I feel the pain. It's like being in forestry, one day you work with a chainsaw, and the next day they give you a fan with spoons welded for the blades. These days I'm doing some Elixir... and I love it. I don't know how welcome it is in the "functional programming and pure functions" club, but I think it's awesome. I have a working theory that what has made these paradigms loved or hated, is less about them theirselves, and more about the execution thereof. What made and makes both Smalltalk and Elixir appealing to me is their simplicity and straightforwardness. There's a mechanism you learn to reason about the problems you're trying to solve, and then you can excel at it, instead of constantly stumbling on edge cases where "hybrid" languages try to reconcile all of the paradigms together. YMMV

fredrikholm 4y ago
> I don't know how welcome it is in the "functional programming and pure functions" club, but I think it's awesome. Erlang, and by extension Elixir, are very respected. The fact that you have a strong background in Smalltalk isn't a surprise: Kay's idea of isolated objects sending methods to each other, independent of each other is OTP. Erlang, IMO, is the most beautiful combination of functional and (Kay's definition of) OOP there is.
actinium226 4y ago
I had done a little bit of OO before diving into functional, but what really got me about functional was "the same inputs always produces the same outputs" and "no side effects" In OO (the kind I've seen, and I've not seen Smalltalk, mostly C++), it's common for a member function to just go ahead and modify the member variables it needs to modify. This is considered "good encapsulation," but it's horrid for reading code and likewise horrid for parallelizing anything. When you take that practice to the logical conclusion, you can end up with a member function like "void update();" (let's pretend that our class is a physics engine and this function presumably takes velocity and time step and increments position). Some early advice I got for writing maintainable code was "assume that whoever is maintaining the code after you is smart and in a hurry," and that sort of code just breaks that advice. If I see that kind of function, I need to dive into it to figure out what's going on. Whereas if I saw "state.position = update_position(state.velocity, state.dt);" I can make an educated guess about what's going on and move on. I'm making myself a little angry here, so I'll wind down. These are the main points anyway, this sort of functional style feels like it takes something in 4D space where I have to twist my brain into a klein bottle to figure it out and puts it into 2D space where I'm like "oh, that's all there is to it then." To your working theory, I see what you're saying, but I think I lean towards preferring poorly done functional code as opposed to well done OO code, because the functional code will be easier to test and shape into good code, whereas the OO code might get fragile over time. But let's be honest, it's not like "well done OO code" is an option we expect to have on the table :D

fredrikholm 4y ago

> I don't know how welcome it is in the "functional programming and pure functions" club, but I think it's awesome. Erlang, and by extension Elixir, are very respected. The fact that you have a strong background in Smalltalk isn't a surprise: Kay's idea of isolated objects sending methods to each other, independent of each other is OTP. Erlang, IMO, is the most beautiful combination of functional and (Kay's definition of) OOP there is.

actinium226 4y ago

I had done a little bit of OO before diving into functional, but what really got me about functional was "the same inputs always produces the same outputs" and "no side effects" In OO (the kind I've seen, and I've not seen Smalltalk, mostly C++), it's common for a member function to just go ahead and modify the member variables it needs to modify. This is considered "good encapsulation," but it's horrid for reading code and likewise horrid for parallelizing anything. When you take that practice to the logical conclusion, you can end up with a member function like "void update();" (let's pretend that our class is a physics engine and this function presumably takes velocity and time step and increments position). Some early advice I got for writing maintainable code was "assume that whoever is maintaining the code after you is smart and in a hurry," and that sort of code just breaks that advice. If I see that kind of function, I need to dive into it to figure out what's going on. Whereas if I saw "state.position = update_position(state.velocity, state.dt);" I can make an educated guess about what's going on and move on. I'm making myself a little angry here, so I'll wind down. These are the main points anyway, this sort of functional style feels like it takes something in 4D space where I have to twist my brain into a klein bottle to figure it out and puts it into 2D space where I'm like "oh, that's all there is to it then." To your working theory, I see what you're saying, but I think I lean towards preferring poorly done functional code as opposed to well done OO code, because the functional code will be easier to test and shape into good code, whereas the OO code might get fragile over time. But let's be honest, it's not like "well done OO code" is an option we expect to have on the table :D