It's unfair to focus on "UI frameworks" when UI frameworks are specifically aimed at supporting client OSes where they have to deal with "preferred frameworks", all of which were developed when OO was all the craze. Functional programming has only been discovered as a practical paradigm quite recently! Besides, implying that "big serious programs" necessarily implies that they are UI programs is completely wrong.
Unsurpisingly, if a given JS UI framework is OO, it is not OO in the traditional sense because JavaScript itself is not OO in the traditional sense. If you make a framework, you use the language of whatever runtime you are targeting.
Functional programming is often used to write server code that must easily parallelize and scale across cores, CPUs and clusters. Mostly because the FP paradigm is more obviously advantageous in that setting, but also because those services have less baggage of trends than UI heavy programs do.
So you are arguing that there is some perceived evidence for OO in UI programming, but I think that could more easily be attributed to historical trends. Note that I'm not necessarily disagreeing with your conclusion, just that your reasoning is flawed.
OOP is well suited to UI programming because it is built around metaphor. FP doesn't quite work because UI programmers like to think in terms of buttons and windows rather than f and g.
> Functional programming is often used to write server code that must easily parallelize and scale across cores, CPUs and clusters. Mostly because the FP paradigm is more obviously advantageous in that setting, but also because those services have less baggage of trends than UI heavy programs do.
As someone who works in a distributed systems team, ha! Where are these functional programmers writing high performance parallel code? Microsoft? Google? Facebook? Maybe map reduce and some pipeline descriptions can count as functional but that's about it (even the UDFs are imperative).
The best HPC programmer I know (and probably one of the best in the world) uses C++ and CUDA, neither very functional.
> FP doesn't quite work because UI programmers like to think in terms of buttons and windows rather than f and g.
This is because people have been educated in thinking in objects for thirty years now. This is again a result of history, not because of the qualities of OO over FP.
Besides, there's no reason why you couldn't do that using functional programming. FP is not (necessarily) object oriented, but that doesn't mean you cannot reason about 'objects' in a different sense.
> As someone who works in a distributed systems team, ha! Where are these functional programmers writing high performance parallel code? Microsoft? Google? Facebook? Maybe map reduce and some pipeline descriptions can count as functional but that's about it (even the UDFs are imperative).
I'm not talking "distributed" systems that do HPC work; functional programming in general cannot achieve that level of low-level performance (as long as you don't count Rust's ambitions). I'm talking 'scalable' systems that do a lot of messaging processing (like web services and queueing systems). Twitter, Walmart, LinkedIn (Scala), Facebook, Whatsapp, dozens of companies in the telecom industry (Erlang) and Jane Street (Haskell, OCaml, F#) are examples.
Functional programming has been known and researched for decades. Mostly what happens is the obviously good features filter down into more mainstream languages, hence the new stream extension in Java 8, and the rest (lazy by default?) gets left behind.
The key selling point of functional languages is not lambdas, but immutable state and referential transparency. People read "advantages of functional programming" and think "anonymous functions" and "they're talking about scary Haskell" which is wrong.
Although lambdas are a big improvement to Java, they are not helping enough to make the language more functional. Java is built upon mutable state to its very core, and will never share FP's redeeming qualities.
Lazy by default is a feature of Haskell, and is not a feature of (or necessary for) functional programming. Scala, OCaml, F# and Lisps are not lazy by default.
I'm going to agree with parent. OO programming is mostly about objects...they have names and identity, with that identity they can have mutable state (would be difficult to have state without identity and aliasing). In pure functional programming land, all values are anonymous, there is no way to tell if you seen something for unless you setup a GUID in the value (which would also require state, but whatever). Those values have no identity, so mutable state is impossible, leading to a very different style of programming.
If you allow for value identities (via GUIDs or if your language is really impure) in your functional code, you wind up with a style of programming that is very similar to programming with objects (messaging those values to do things with their state). Heck, you wouldn't even need overt mutable state to arrive at a very OO style (see clojure).
Hughes didn't disagree with what I said; I would contend that higher-order functions and laziness only improve modularity iff the language was referentially transparent in the first place. The assumption that the theoretical FP language he discusses is referentially transparent is found on page 2 of Hughes' paper.
Java's lambdas only serve to reduce boilerplate; everything done with Java's lambdas was long possible using anonymous classes. Theoretically, they do nothing to present the advantages discussed by Hughes [1].
Hughes also didn't talk about laziness-by-default: his argument still holds if laziness is available somehow (which it is in many FP languages).
[1]: Of course, lambdas might improve the style and expressivity of idiomatic Java enough to make up some ground.
You can make immutable objects in Java. The result is quite, quite unpleasant IMHO, but so are many other things in Java. You just create an object that has final fields and a constructor (or a builder if you have a more complex object).
Now, nothing stops that immutable object containing a mutable object of course, but that's up to you ... Guava has immutable collections if you want them.
Better language support for immutability would not go amiss though.
Let's wait and see if Om inspire others. You know that ideas take time to diffuse, OOP/MVC has been a somehow natural fit for IHM, but like many other ideas (closures?) now that people can see it, maybe they'll change their mind.
