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.
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.
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.
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.
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.:
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).
I did look at the source and it seemed that way (imperative code using flat arrays) but I don't know enough OCaml to say with certainty.
I have worked with other functional languages (Clojure) and I have optimized GCed code and it mostly boils down to what I said - writing C/C++ like code in language X to get as close to hardware memory model (avoiding GC by pooling, increasing cache coherence, using value types or manually unfolding data structs, etc.)
I haven't seen a magical way for high level data structures based on trees (used for persistant strucutres) to outperform arrays
No, that won't happen, but a lot of the code that you write in a functional language can be optimized far better than another language, because the compiler has more, stronger guarantees about your code.
There's some truth to this, but "can be optimized" is not the same as "there exists a compiler that optimizes".
Your statement gets repeated a lot (and similarly about the JVM: it has run-time information that compilers don't have, so can optimize better), and yet C++ and Fortran continue to come out on top.
Indeed, because C++ and Fortran get the money and time, and they're closer to the metal to begin with. Also, C++'s "Nasal Demons on UB" problem helps a lot.
But yes, OCaml is quite fast, and probably could be faster. Does it really beat C++ in all contexts? Probably not, but it's still pretty fast.
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.
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!
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.
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.
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>;
}
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".
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".
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.
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/
#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?
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.
>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.
The lambda calculus was also the first OO language. (William Cook pointed this out in http://web.engr.oregonstate.edu/~walkiner/teaching/cs583-sp1... and I'd noticed the same thing. I just want to bring in a neat observation here, not fight for either side of the OO/FP culture war. I wish we humans wouldn't do that.)
Not really? The claim that functional programming predates OO would require that functional programming languages existed before OO languages, which is clearly false. If anything they were both developed at approximately the exact same time, which has more to do with hardware coming into existence and wider use that could support higher level languages.
ISWIM did exist, even if the compiler wasn't there. The lisp community did a lot of work with FP-style code, even if the language as a whole wasn't functional: the idea was still there.
But your main point was that FP was useless, deriding it, and claiming that, "only people that talk about it are academics and people who want to seem smart," which is demonstrably not true.
Where are the software projects that are built using functional languages?
I'll call out XMonad. What can you come up with? Obscure companies doing obscure things, or else people using Common Lisp in a nonfunctional way.
What major project or product is built using Haskel or Ocaml? There aren't any! The only thing I have ever used that were written in those languages are XMonad and csvtool respectively.
map, filter, etc are not 'functional'. 'functional' doesn't mean 'functions'. It is all about side effects, and that the procedures in the language are like mathematical functions: without state or side effects.
Using your definition, virtually every language in use today is 'functional', all the way down to Fortran 77, since really any language you can get a pointer or other handle to a function or callable object would let you implement map, filter, etc.
Really the existence of map, filter, etc are not a clue to a language being 'functional'. Yes, you would need such things, but they are not sufficient. C is not a 'functional language', even though technically you can write C that is completely functional in style.
In fact, almost any modern language can be used in a 100% functional style, avoiding side effects and state completely. Nobody does this.
Even if it is one of your favorite things, virtually no one uses functional languages. This isn't because people are dumb, it's because functional languages are cumbersome and inefficient.
I would not think passing procedure pointers in C makes it able to support functional programming. That's very shallow.
C lacks (last I looked) nested functions, closures, functions as first class data types, ...
> Really the existence of map, filter, etc are not a clue to a language being 'functional'.
'Functional Programming' isn't black and white. There are pure languages which ENFORCE functional programming like Haskell. It's their many paradigm, the language and its library make heavy use of FP and one has to actively manage side-effects.
Then there are language which SUPPORT some forms of functional programming, for example by providing a subset in the language and its libraries which can be used side-effect free, makes use of higher-order functions, etc.
At the bottom are languages which ENABLE some basic functional programming idioms. Though most of the language and its libraries are not using FP, the user can still use some FP constructs like nested functions, closures, etc.
Generally I agree, that pure FP is not that much used in the real world because of a lot actual problems (difficult to learn/use/maintain, efficiency might be achievable by experts, needs understanding of slightly advanced mathematical concepts, ...). There are some more or less used implementation languages of more or less pure FP (GHC, OCAML, F#, ..., Clojure) languages. I'd guess that the main applications are in domains where they have highly skilled people: finance, data analytics, verification/specification, ...
I sometimes see that companies advertise use of FP languages, but in reality that's marketing in recruiting to look cool and to attract clever people (who then have to work on Java jobs, mostly).
I wasn't making the point that map and filter were functional, I was trying to say that those were concepts originating in FP. And that they appear in so many languages demonstrates some of FP's influence.
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.
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.
I'm pretty familiar with Tcl/Tk but not entirely clear what you mean about Tcl/Tk and OOP. It seemed like you said the Tk container hierarchy was the model that OOP platforms copied. I'd agree that Tk's widget model is very useful as a way to build GUIs, but it doesn't have the abstraction features found in Java, etc.
Tk could be seen as a predecessor of DOM and CSS (as widget-building paradigm), possibly other widget libraries like GTK as well. In Tcl, OOP has evolved along other, if overlapping lines, as can be seen in the core oo::* namespace.
Advantages and disadvantages of various OO systems for Tcl have been discussed for a couple of decades. Issues around all of the aspects of OOP reviewed in the article were evident and the focus of disagreements, which showed the limitations of any particular approach and, as usual, that no free lunch or perfect answer can ever be found.
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.
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.
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.