13 ms·

I think the functional vs OO debate is being done with a very narrow point of view. Functional came before OO and there are reasons why it became much more pop

I think the functional vs OO debate is being done with a very narrow point of view. Functional came before OO and there are reasons why it became much more popular- it had much better, easier and simpler solution to the most common problems of the 90's and early 2000's, namely handling GUI and keeping single process app state (usually for a desktop app). It fares much worse in today's world of SaaS and massive parallel computing. Frankly I think the discussion will be much better if we debate the merrits of each paradigm in the problem domain you are facing, rather then blindly bashing on a paradigm that is less suited to your problem domain. For instance I have yet to see an easy and simple to use (and as such maintainable) functional widget and gui library.

DanWaterworth 10y ago
> For instance I have yet to see an easy and simple to use (and as such maintainable) functional widget and gui library. Like react?
- quacker 10y ago
  My impression of react is that it's very object oriented. Defining reusable, stateful components is classic OO design. Now, I don't have much experience with React so maybe someone can explain why it should be considered "functional".
  - acemarke 10y ago
    React is an interesting mix of functional and OO. It's OO, in that the primary approach for defining components is class-based, and components have state and lifecycles. It's functional, in that the render methods are expected to be pure functions based on component state and props, and simply output a description of what the UI should look like as a result. Also, as a whole, React definitely pushes you to view the system in terms of composition, state transformations, and pure functions, rather than imperative "toggle this, add that, update the other thing".
    - TheOtherHobbes 10y ago
      Maybe we need a new tag: OOF. Or possibly FOO.
  - jaegerpicker 10y ago
    Not sure why people have that impression. It doesn't fundamentally do any OO things. You don't inherit from the react components. Maybe you could make an argument for encapsulation but even that is shaky in JavaScript. Most it only uses prototypes as object for namespacing and to organize the api better since JS lacks good namespacing syntax.
  - danek 10y ago
    It depends on how you use React. You can use it in a stateful, OO way. Or you can use it in a more functional way. A good example of how to use React in a functional manner is the Redux framework (basically you don't use the stateful parts of React and treat your components as a tree of pure render functions). http://redux.js.org/ http://redux.js.org/
- olmo 10y ago
  ReactComponent are also very OO, just the render function is functional
- Illniyar 10y ago
  Is this same react where your components keep internal state (called state) and every component must be created by extending a base class?
  - MindPenguin 10y ago
    Conceptually, components have state, but it's all managed by react, so you only ever write pure functions. Granted, depending on how you update state in event handlers and lifecycle methods, you will need to think about state a lot, but this is an unavoidable fact of UI programming. > every component must be created by extending a base class This is an implementation detail, instead of ES6 classes you can also use React.createClass(), which might as well be named React.createComponent(). These "classes" can't be inherited from.
    - jaegerpicker 10y ago
      Also, now in react (as of 0.14 with stateless function components) you can define components as pure functions that return a jsx dta structure to the render function. IE (coded by memory quickly syntax may be wonky): const test_component = () => { return <H1>Blah!</H1>; } <test_component/>
    - Illniyar 10y ago
      Conceptually is nice. All react code I've seen or wrote of even the most trivial systems have components (and more then a few) that override lifecycle methods - which is by almost definition OO's polymorphism. Buy even if you could write every component with the stateless style it doesn't change the fact that your framework/GUI-library is using OO extensively and in it's fundamental concepts, I think that makes it OO, you seem to disagree.
      - MindPenguin 10y ago
        It's not "overriding" lifecycle methods, it's passing lifecycle methods to a component factory function.
  - 10y ago
ebbv 10y ago
I agree with you. Moreover, I think anyone who is rabidly attaching themselves to a programming paradigm of any kind is doing themselves (and anyone who has to work with them) a disservice. It's all just tools. Committing yourself fully to a single tool like functional or OO or whatever is just as silly as a woodworker attaching themselves to only a single form of joinery.
- thinkloop 10y ago
  Of course limiting oneself to one thing gives less options than two things, but this "tool" analogy (that keeps coming up) is not fair. Better would be to compare to the woodworking shop itself, where there are many tools that together solve a wide class of problems. You can run multiple shops if you like, with varying combinations of tools, and large overlap in the problems they can solve, but the overhead involved is not the same as choosing a screwdriver to screw and a hammer to smash.
chiefalchemist 10y ago
#SpotOn. Tools should match problems. But try telling that to a ego driven programmer. For most, they have a hammer and everything is a nail. Is it any wonder the number of IT projects that go sideways or full on tits up really hasn't changed?
fbonetti 10y ago
> For instance I have yet to see an easy and simple to use (and as such maintainable) functional widget and gui library. I will continue to shill for Elm[1], like I always do. [1] http://elm-lang.org/ http://elm-lang.org/
- maaaats 10y ago
  But that's not a library. It forces your whole project into a box in which it may not fit. Elm is not without problems as well, although they (him?) are working on the biggest pain-points.
  - fbonetti 10y ago
    > It forces your whole project into a box Isn't that the point? Since Elm is a pure, strongly typed language, it introduces a lot of constraints. You can't mutate anything, there are no side effects (only declared effects captured by the type system), and the only architecture you can use is "The Elm Architecture". However, those restrictions will keep your code sane and the compiler almost guarantees that your code will work. It's a pretty fair trade-off if you ask me.
SFJulie 10y ago
Pre Scriptum: For the GUI tcl/tk made the root of all OOP model and no one has been innovating since. Just copying. But, it is not whether a paradigm/language is better than another one. It is about getting shits done. The paradigm/language war/agile are cargo cult science. It is transforming a practice into a religious thinking while it is not the case. All the list he makes about OOP is right, on the other hand, you can admit that objects as a namespace can be a right thing. Like ... well the stringIO, the string and the file or IO objects. But, the data encapsulated these way have finite well known states. I had a lot of pleasure using OOP in Perl, python, PHP because it was easy to remember where things were for some stuffs, and error/resource handling can be done in a nifty way, even though trying to make stuff optimized for speed or memory required to dive into the guts of the implementations or counter-intuitive so called intuitive ways of doing stuffs. I guess the rant can be made about making leaky stateful objects that are coupled. Which is what OOP has been advocated for years now. With every dimension with finite states you couple, your cardinality is the cross product of every dimension and it grows more than linearly, defying very soon the brain cognitive power. But still, people insists on going for more complexity because their «tool» can handle it. The limit is NOT the language. It is the human brain. But the hubris is there. Is Bill built from an Invoice itself built from a Quotation, or are these simple transition applied to a document through the use of functions? The OOP approach may seem simpler for «encapsulation» but as soon as you add the polymorphism to add the payment gateway and the serialization of data ... and have to make it straight with book-keeping while no developers actually understand accounting, this becomes hell to synchronize what should be plain documents that are worthy with objects. Because ... coders are lost in complexity and lose focus about the real world application, and that what they think may be wrong. Very few coders I know check that their model fit the reality : they make assumptions. The Quote/Bill/Invoice is basically no better as a poor document in ascii you can read and is self descriptive with stamps giving the stage. The problem of OOP is documents are «abstracted» as a view on multiple states that are poorly modeled because people are overthinking the implementation and losing the goal : to put $ in the bank and make your accounting/billing/commercial services working. Very soon, the document is very dependent from a database, its view, its controler .... And, while most boss are kind of embezzling. They don't say it this way, they say they want something flexible that can be easily changed. To make an innovation. All our IT is about subtly walking around rules or regulations. Coder are over-specialized in coding, while they should first learn the craft they are modeling. Other times, bosses are overgeneralizing expecting rules (like accounting) to stay the same across country. Well coders being believers they have bugs, not because their code is complex, sometimes because the real world accept no possible automation of tasks. The problem sometimes do not lie in the paradigm or the language but in the excess of confidence people have.
TillE 10y ago
This is a good point. Functional is a really useful model for mostly stateless data processing. When you have lots of state that needs to be mutable, not so much.
- whateveracct 10y ago
  Even state is easier when modeled purely though imo. Especially once you have to backtrack and rollback state. If you use pure state, it's trivial. If you don't, gl!
pjmlp 10y ago
Lisp with LOOPS, followed by FLAVORS and finally settled on CLOS?
- Illniyar 10y ago
  What are those?
  - pjmlp 10y ago
    OOP in Lisp, since the early days of the language in the mid-70's. As the language was being further used for research at Xerox PARC and Genera.
rubber_duck 10y ago
I think the reason is much more fundamental - even now functional languages are slower - even with all the fancy modern compilers, optimizers, GCs that were not even in the same league 20 years ago or more. OO maps nicely to shared memory model and it's fairly low overhead compared to things like persistent collections data structures. This helps when you are forced to deal with lower level stuff. Nowdays we are IO bound, we moved from single shared memory machine -> distributed services communicatig with messages and the problems are more about data transformation rather than HW management. OO is cumbersome in this context. Functional GUI is easy to do, look at clojure react wrappers.
- qwertyuiop924 10y ago
  >even now functional languages are slower OCaml is famously faster than C++.
  - unscaled 10y ago
    OCaml is quite fast, and I guess it could produce faster code than C++ on some occasions, but it's definitely SLOWER than C++ for most benchmarks, e.g.: benchmarksgame.alioth.debian.org/u64q/compare.php?lang=ocaml&lang2=gpp
    - qwertyuiop924 10y ago
      Ah. Sorry. But yes, Ocaml is quite fast. Which was my point.
      - rubber_duck 10y ago
        That's not a very strong point -those benchmark sources usually look like "C in language X" and not like "idiomatic use of language X" - I'd bet they don't use immutable data structures and hand optimize code avoiding common patterns in functional programming for perf. Which is my point - there are languages that can compile to similar code as C/C++ if you write similar code - but the idiomatic code is still slower because it doesn't map to hardware cleanly and have inherent overhead, this is why functional languages didn't catch on when we were heavily CPU bound, it was common for people to write ASM because they couldn't get good enough perf out of C compilers. Now that we transitioned from vertical to horizontal scaling problem domain maps very nicely to functional languages (actor model/message passing style communication is practically transparent with immutable data function calls).
ltbarcly3 10y ago
I don't have any idea what you're talking about when you say 'functional came before OO'. I'm guessing you are talking about Lisp, but not only are Common Lisp (and the languages it evolved from) not at all functional in any technical sense of the word, many of them only had dynamic scoping, and often used mutation of data structures implicitly. Stop talking nonsense. EDIT: If you are talking about scheme, then the same exact points apply. On top of all of the above points, nobody in the world other than a few extreme language-philes ever use any of the functional languages, and for good reason. Functional programming is nonsense, the only people that talk about it are academics and people who want to seem smart. Functional != Structured Programming, Functional != Procedural, 'functional' has a precise meaning: treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. Neither Schema nor Lisp nor any but a very few quite obscure languages satisfy this.
- qwertyuiop924 10y ago
  >I don't have any idea what you're talking about when you say 'functional came before OO'. Lambda calculus is technically the first functional language, and predates computers. But if we're talking about actual programming languages, SASL, one of the earliest functional languages actually implemented, was released the same year as Smalltalk, and was influenced by the older ISWIM, which was never implemented. >I'm guessing you are talking about Lisp, but not only are Common Lisp (and the languages it evolved from) not at all functional in any technical sense of the word. The functional style (writing most of your code as pure functions, keeping impure code isolated), however, can be practiced in ANY language. It makes your systems easier to reason about, because you know if state is being modified. And Lisps had many constructs that made FP convenient. Like map. So while Lisp, on the whole, wasn't functional, it was one of the easiest languages to write functional code in for some time. >On top of all of the above points, nobody in the world other than a few extreme language-philes ever use any of the functional languages, and for good reason. On the contrary, FP has heavy use in finance and other places where there is a low tolerance for error, as well as Microsoft and many other conpanies. It has heavy use in programming language research, and a functional programming language was used for program analysis to aid in the optimization of FFTW, which is still one of the fastest implementations of the Fast Fourier Transform. >Stop talking nonsense. As the above demonstrates, you're the only one who's doing that.
jdeisenberg 10y ago
Erlang is a good choice for doing massive parallel computing, and it is a functional language.
eru 10y ago
It took people quite a while to figure out how to compile functional code (especially lazy functional code) to commodity hardware. The research only caught up in the 80s.

DanWaterworth 10y ago

> For instance I have yet to see an easy and simple to use (and as such maintainable) functional widget and gui library. Like react?

quacker 10y ago
My impression of react is that it's very object oriented. Defining reusable, stateful components is classic OO design. Now, I don't have much experience with React so maybe someone can explain why it should be considered "functional".
- acemarke 10y ago
  React is an interesting mix of functional and OO. It's OO, in that the primary approach for defining components is class-based, and components have state and lifecycles. It's functional, in that the render methods are expected to be pure functions based on component state and props, and simply output a description of what the UI should look like as a result. Also, as a whole, React definitely pushes you to view the system in terms of composition, state transformations, and pure functions, rather than imperative "toggle this, add that, update the other thing".
  - TheOtherHobbes 10y ago
    Maybe we need a new tag: OOF. Or possibly FOO.
- jaegerpicker 10y ago
  Not sure why people have that impression. It doesn't fundamentally do any OO things. You don't inherit from the react components. Maybe you could make an argument for encapsulation but even that is shaky in JavaScript. Most it only uses prototypes as object for namespacing and to organize the api better since JS lacks good namespacing syntax.
- danek 10y ago
  It depends on how you use React. You can use it in a stateful, OO way. Or you can use it in a more functional way. A good example of how to use React in a functional manner is the Redux framework (basically you don't use the stateful parts of React and treat your components as a tree of pure render functions). http://redux.js.org/ http://redux.js.org/
olmo 10y ago
ReactComponent are also very OO, just the render function is functional
Illniyar 10y ago
Is this same react where your components keep internal state (called state) and every component must be created by extending a base class?
- MindPenguin 10y ago
  Conceptually, components have state, but it's all managed by react, so you only ever write pure functions. Granted, depending on how you update state in event handlers and lifecycle methods, you will need to think about state a lot, but this is an unavoidable fact of UI programming. > every component must be created by extending a base class This is an implementation detail, instead of ES6 classes you can also use React.createClass(), which might as well be named React.createComponent(). These "classes" can't be inherited from.
  - jaegerpicker 10y ago
    Also, now in react (as of 0.14 with stateless function components) you can define components as pure functions that return a jsx dta structure to the render function. IE (coded by memory quickly syntax may be wonky): const test_component = () => { return <H1>Blah!</H1>; } <test_component/>
  - Illniyar 10y ago
    Conceptually is nice. All react code I've seen or wrote of even the most trivial systems have components (and more then a few) that override lifecycle methods - which is by almost definition OO's polymorphism. Buy even if you could write every component with the stateless style it doesn't change the fact that your framework/GUI-library is using OO extensively and in it's fundamental concepts, I think that makes it OO, you seem to disagree.
    - MindPenguin 10y ago
      It's not "overriding" lifecycle methods, it's passing lifecycle methods to a component factory function.
- 10y ago

ebbv 10y ago

I agree with you. Moreover, I think anyone who is rabidly attaching themselves to a programming paradigm of any kind is doing themselves (and anyone who has to work with them) a disservice. It's all just tools. Committing yourself fully to a single tool like functional or OO or whatever is just as silly as a woodworker attaching themselves to only a single form of joinery.

thinkloop 10y ago
Of course limiting oneself to one thing gives less options than two things, but this "tool" analogy (that keeps coming up) is not fair. Better would be to compare to the woodworking shop itself, where there are many tools that together solve a wide class of problems. You can run multiple shops if you like, with varying combinations of tools, and large overlap in the problems they can solve, but the overhead involved is not the same as choosing a screwdriver to screw and a hammer to smash.

chiefalchemist 10y ago

#SpotOn. Tools should match problems. But try telling that to a ego driven programmer. For most, they have a hammer and everything is a nail. Is it any wonder the number of IT projects that go sideways or full on tits up really hasn't changed?

fbonetti 10y ago

> For instance I have yet to see an easy and simple to use (and as such maintainable) functional widget and gui library. I will continue to shill for Elm[1], like I always do. [1] http://elm-lang.org/ http://elm-lang.org/

maaaats 10y ago
But that's not a library. It forces your whole project into a box in which it may not fit. Elm is not without problems as well, although they (him?) are working on the biggest pain-points.
- fbonetti 10y ago
  > It forces your whole project into a box Isn't that the point? Since Elm is a pure, strongly typed language, it introduces a lot of constraints. You can't mutate anything, there are no side effects (only declared effects captured by the type system), and the only architecture you can use is "The Elm Architecture". However, those restrictions will keep your code sane and the compiler almost guarantees that your code will work. It's a pretty fair trade-off if you ask me.

SFJulie 10y ago

Pre Scriptum: For the GUI tcl/tk made the root of all OOP model and no one has been innovating since. Just copying. But, it is not whether a paradigm/language is better than another one. It is about getting shits done. The paradigm/language war/agile are cargo cult science. It is transforming a practice into a religious thinking while it is not the case. All the list he makes about OOP is right, on the other hand, you can admit that objects as a namespace can be a right thing. Like ... well the stringIO, the string and the file or IO objects. But, the data encapsulated these way have finite well known states. I had a lot of pleasure using OOP in Perl, python, PHP because it was easy to remember where things were for some stuffs, and error/resource handling can be done in a nifty way, even though trying to make stuff optimized for speed or memory required to dive into the guts of the implementations or counter-intuitive so called intuitive ways of doing stuffs. I guess the rant can be made about making leaky stateful objects that are coupled. Which is what OOP has been advocated for years now. With every dimension with finite states you couple, your cardinality is the cross product of every dimension and it grows more than linearly, defying very soon the brain cognitive power. But still, people insists on going for more complexity because their «tool» can handle it. The limit is NOT the language. It is the human brain. But the hubris is there. Is Bill built from an Invoice itself built from a Quotation, or are these simple transition applied to a document through the use of functions? The OOP approach may seem simpler for «encapsulation» but as soon as you add the polymorphism to add the payment gateway and the serialization of data ... and have to make it straight with book-keeping while no developers actually understand accounting, this becomes hell to synchronize what should be plain documents that are worthy with objects. Because ... coders are lost in complexity and lose focus about the real world application, and that what they think may be wrong. Very few coders I know check that their model fit the reality : they make assumptions. The Quote/Bill/Invoice is basically no better as a poor document in ascii you can read and is self descriptive with stamps giving the stage. The problem of OOP is documents are «abstracted» as a view on multiple states that are poorly modeled because people are overthinking the implementation and losing the goal : to put $ in the bank and make your accounting/billing/commercial services working. Very soon, the document is very dependent from a database, its view, its controler .... And, while most boss are kind of embezzling. They don't say it this way, they say they want something flexible that can be easily changed. To make an innovation. All our IT is about subtly walking around rules or regulations. Coder are over-specialized in coding, while they should first learn the craft they are modeling. Other times, bosses are overgeneralizing expecting rules (like accounting) to stay the same across country. Well coders being believers they have bugs, not because their code is complex, sometimes because the real world accept no possible automation of tasks. The problem sometimes do not lie in the paradigm or the language but in the excess of confidence people have.

TillE 10y ago

This is a good point. Functional is a really useful model for mostly stateless data processing. When you have lots of state that needs to be mutable, not so much.

whateveracct 10y ago
Even state is easier when modeled purely though imo. Especially once you have to backtrack and rollback state. If you use pure state, it's trivial. If you don't, gl!

pjmlp 10y ago

Lisp with LOOPS, followed by FLAVORS and finally settled on CLOS?

Illniyar 10y ago
What are those?
- pjmlp 10y ago
  OOP in Lisp, since the early days of the language in the mid-70's. As the language was being further used for research at Xerox PARC and Genera.

rubber_duck 10y ago

I think the reason is much more fundamental - even now functional languages are slower - even with all the fancy modern compilers, optimizers, GCs that were not even in the same league 20 years ago or more. OO maps nicely to shared memory model and it's fairly low overhead compared to things like persistent collections data structures. This helps when you are forced to deal with lower level stuff. Nowdays we are IO bound, we moved from single shared memory machine -> distributed services communicatig with messages and the problems are more about data transformation rather than HW management. OO is cumbersome in this context. Functional GUI is easy to do, look at clojure react wrappers.

qwertyuiop924 10y ago
>even now functional languages are slower OCaml is famously faster than C++.
- unscaled 10y ago
  OCaml is quite fast, and I guess it could produce faster code than C++ on some occasions, but it's definitely SLOWER than C++ for most benchmarks, e.g.: benchmarksgame.alioth.debian.org/u64q/compare.php?lang=ocaml&lang2=gpp
  - qwertyuiop924 10y ago
    Ah. Sorry. But yes, Ocaml is quite fast. Which was my point.
    - rubber_duck 10y ago
      That's not a very strong point -those benchmark sources usually look like "C in language X" and not like "idiomatic use of language X" - I'd bet they don't use immutable data structures and hand optimize code avoiding common patterns in functional programming for perf. Which is my point - there are languages that can compile to similar code as C/C++ if you write similar code - but the idiomatic code is still slower because it doesn't map to hardware cleanly and have inherent overhead, this is why functional languages didn't catch on when we were heavily CPU bound, it was common for people to write ASM because they couldn't get good enough perf out of C compilers. Now that we transitioned from vertical to horizontal scaling problem domain maps very nicely to functional languages (actor model/message passing style communication is practically transparent with immutable data function calls).

ltbarcly3 10y ago

I don't have any idea what you're talking about when you say 'functional came before OO'. I'm guessing you are talking about Lisp, but not only are Common Lisp (and the languages it evolved from) not at all functional in any technical sense of the word, many of them only had dynamic scoping, and often used mutation of data structures implicitly. Stop talking nonsense. EDIT: If you are talking about scheme, then the same exact points apply. On top of all of the above points, nobody in the world other than a few extreme language-philes ever use any of the functional languages, and for good reason. Functional programming is nonsense, the only people that talk about it are academics and people who want to seem smart. Functional != Structured Programming, Functional != Procedural, 'functional' has a precise meaning: treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. Neither Schema nor Lisp nor any but a very few quite obscure languages satisfy this.

qwertyuiop924 10y ago
>I don't have any idea what you're talking about when you say 'functional came before OO'. Lambda calculus is technically the first functional language, and predates computers. But if we're talking about actual programming languages, SASL, one of the earliest functional languages actually implemented, was released the same year as Smalltalk, and was influenced by the older ISWIM, which was never implemented. >I'm guessing you are talking about Lisp, but not only are Common Lisp (and the languages it evolved from) not at all functional in any technical sense of the word. The functional style (writing most of your code as pure functions, keeping impure code isolated), however, can be practiced in ANY language. It makes your systems easier to reason about, because you know if state is being modified. And Lisps had many constructs that made FP convenient. Like map. So while Lisp, on the whole, wasn't functional, it was one of the easiest languages to write functional code in for some time. >On top of all of the above points, nobody in the world other than a few extreme language-philes ever use any of the functional languages, and for good reason. On the contrary, FP has heavy use in finance and other places where there is a low tolerance for error, as well as Microsoft and many other conpanies. It has heavy use in programming language research, and a functional programming language was used for program analysis to aid in the optimization of FFTW, which is still one of the fastest implementations of the Fast Fourier Transform. >Stop talking nonsense. As the above demonstrates, you're the only one who's doing that.

jdeisenberg 10y ago

Erlang is a good choice for doing massive parallel computing, and it is a functional language.

eru 10y ago

It took people quite a while to figure out how to compile functional code (especially lazy functional code) to commodity hardware. The research only caught up in the 80s.