4 ms·
The "intermediate beginner" who latches on whatever is "new" and trendy is my biggest annoyance with the industry. Unfortunately functional programming seems to
by sotojuan 10y ago
The "intermediate beginner" who latches on whatever is "new" and trendy is my biggest annoyance with the industry. Unfortunately functional programming seems to be what at lot of these people are claiming is the solution to everything now, even if they have little experience building systems with it and it's older than OOP.
- pitaj 10y agoI hate to go on a tangent, but what are some examples of things that OOP does better than FP? I can only think of a couple examples: data structures and some APIs.
- sevenless 10y agoAnything that behaves like an object, would be the obvious answer. GUI elements, things in games or simulations. More abstractly, an object's a namespace with persistent properties, so for something that has a persistent, possibly mutable, state, an object is the metaphor you want. Whether data structures should be objects rather than primitives depends very much on the data.
- stickfigure 10y agoErm... pushing data structures between APIs is the essence of countless viable businesses. I love both FP and OOP and especially love using them together. I honestly don't get these arguments.
- sotojuan 10y agoI think what frustrates me is that I see these people as, for lack of a better word, "posers". I'm no functional expert and I'm just in the beginning of my career, but I'm very skeptical of devs who had little problem with imperative/OOP code suddenly writing Medium articles saying OOP is dead and "functional" is the "next" step. Just makes me uncomfortable, but I'm learning to ignore it.
- pitaj 10y agoIt wasn't an argument. I was asking a real question I am curious about.
- nine_k 10y agoIt's pretty strange to think that OOP cannot be implemented using a functional language. Various Lisps had several OO systems, and there's OCaml, where the "O" stands for "objective". Objects are merely collections of partially-applied functions (or often procedures): methods are bound to `this` aka `self`, the instance. When you have a language where partial function application (currying) is a norm, you have little trouble implementing this approach. What made OOP popular, things like good modularity and hiding of implementation details, has little to do with the "inheritance + encapsulation + polymorphism" trio proper. They can be and often are achieved without these. What makes FP powerful is higher-order functions / function composition, immutable data / pure functions / referential transparency, and isolation of effects. Technically, all of these are easily available in most popular OO languages, and you can reap many benefits of FP writing in C#, Python, or even Java 8. But the standard libraries of most of them actively resist such usage, and the translators do not rely on the functional features heavily for optimization. Where pure FP has trouble is e.g. large mutable structures with constant small mutations, like editing a bitmap in a paint program. Real-time stuff can also be harder, because the shape of the machine code is much less obvious than when using a lowest-possible-level language like C. Since the real world is inherently effectful, there will always be a mix of approaches. Pick the right tool for the job; a job of any serious complexity will likely require multiple different tools.