3 ms·

Compare the DirectX XNA OOP library to the OpenGL procedural library, and you will quickly see that when OOP is done right it makes code fun and easy to work wi

Compare the DirectX XNA OOP library to the OpenGL procedural library, and you will quickly see that when OOP is done right it makes code fun and easy to work with again. In my my mind OOP is the next logical step after procedural programming (simply packaging up a set of procedures into an object, and adding a few new ideas like inheritance and so on). Functional programming though is not the next logical step; it is a total paradigm shift. The main argument is that you get rid of state etc which means you can parallelize better - but why are no cutting edge games made in an FP language I wonder? Surely they would want to distribute all the physics collision rendering and so on to multiple cores? It's because functional programming as a separate language makes no sense, you lose too much. But incorporating FP style into OOP languages (such as with the new C++ constexpr, C# linq, and Java lambda), and giving the programmer the choice to use it when it makes sense is a far more powerful option.

LoSboccacc 11y ago
OOP is about information hiding and providing well defined state transitions. objects are used to hold a state and to act as gateway for valid transitions. most complaints I see come from people using OO programming languages badly, leaking abstractions all over the place and making it so you have to mentally take care of the state of everything instead of trusting your objects to take care of themselves, and thus you get the worst of both world: rigidity coupled with complexity I need information hiding because my brain is only so big, so I cannot possibly have in mind the whole application state and all it's permutation at all time while programming. functional languages work similarly in a sense: you avoid thinking about state transitions because the only things you have to take care of is each function input and output in a broader sense, programming becomes way way simpler if you think of your functions as having 4 well defined input output: the inputs, the return values, data from a persistent store and a state. And with experience you start noticing that it is much much more simple and productive if in any of your method at a given time you only reduce the 4 io ports in 2: on one side you have functional languages, only ever working with inputs and returns, on the other you have OO languages, which focus so much on the input, state and state, return couples. mastering the ability of using both styles where appropriate is the key here. but people get dragged into name specific too much, forgetting that these pattern emerged from coding and not the other way around.
- mercer 11y ago
  Very well put. I've found that in some cases objects make a lot of sense, and the more functional approach would really end up emulating objects through closures and whatnot. That said, especially for a lot of the typical web-related work I do, I find that I'm generally better off leaning towards a more functional approach, as most of what I do boils down to transforming database values to html in 'one pass'. I'd say many of the typical functional programming approaches are excellent for that. Avoiding mutable state has been a wonderful lesson, for example.
sklogic 11y ago
> In my my mind OOP is the next logical step after procedural programming Modules and namespaces are the next logical step. And they've got nothing to do with OOP and its dynamic dispatch, which is absolutely, totally illogical.
- jazzyk 11y ago
  Do you distinguish between OO and OOP? At the conceptual level, OO is primarily about encapsulation and detail hiding. So, a module is a higher-level instrument of encapsulation and information hiding than an object, but still very much OO.

LoSboccacc 11y ago

OOP is about information hiding and providing well defined state transitions. objects are used to hold a state and to act as gateway for valid transitions. most complaints I see come from people using OO programming languages badly, leaking abstractions all over the place and making it so you have to mentally take care of the state of everything instead of trusting your objects to take care of themselves, and thus you get the worst of both world: rigidity coupled with complexity I need information hiding because my brain is only so big, so I cannot possibly have in mind the whole application state and all it's permutation at all time while programming. functional languages work similarly in a sense: you avoid thinking about state transitions because the only things you have to take care of is each function input and output in a broader sense, programming becomes way way simpler if you think of your functions as having 4 well defined input output: the inputs, the return values, data from a persistent store and a state. And with experience you start noticing that it is much much more simple and productive if in any of your method at a given time you only reduce the 4 io ports in 2: on one side you have functional languages, only ever working with inputs and returns, on the other you have OO languages, which focus so much on the input, state and state, return couples. mastering the ability of using both styles where appropriate is the key here. but people get dragged into name specific too much, forgetting that these pattern emerged from coding and not the other way around.

mercer 11y ago
Very well put. I've found that in some cases objects make a lot of sense, and the more functional approach would really end up emulating objects through closures and whatnot. That said, especially for a lot of the typical web-related work I do, I find that I'm generally better off leaning towards a more functional approach, as most of what I do boils down to transforming database values to html in 'one pass'. I'd say many of the typical functional programming approaches are excellent for that. Avoiding mutable state has been a wonderful lesson, for example.

sklogic 11y ago

> In my my mind OOP is the next logical step after procedural programming Modules and namespaces are the next logical step. And they've got nothing to do with OOP and its dynamic dispatch, which is absolutely, totally illogical.

jazzyk 11y ago
Do you distinguish between OO and OOP? At the conceptual level, OO is primarily about encapsulation and detail hiding. So, a module is a higher-level instrument of encapsulation and information hiding than an object, but still very much OO.