3 ms·
Oh, lots of people are using functional programming. They just don't use the paradigm exclusively nor do they use a purely functional programming language. Let'
by hintymad 6y ago
Oh, lots of people are using functional programming. They just don't use the paradigm exclusively nor do they use a purely functional programming language. Let's see,
- Supporting higher order functions in programming languages. Check.
- Usual operations on higher-order functions like currying? Check.
- Functional reactive programming. Check. Rx was a big thing a few years ago.
- Purely functional data structures. Check. Even Java has a few reasonably popular libraries that support such data structures.
- Using referential transparency whenever we can. Check.
- Using CPS (continuation-passing style) in daily programming. Check.
- Using recursion in production. This is not functional programming per se, but given that so many people mention recursion whenever they mention functional programming, it's worth listing recursion here. And mutual recursion and tail recursion, two of the hallmarks of entry-level functional programming techniques? Check and check. For instance, RxJava implements trampoline just to support tail-recursion, as it is necessary to implement cleanly some of RxJava's operators.
- Common techniques seen in functional programming, particularly the ones that involve map, reduce, scan, left-fold and right-fold. Check.
This is just the items that are on top of my mind. I'm sure I missed plenty. The gist is that people have been adopting functional programming. They just don't necessarily move to a purely functional programming language for practical reasons: platform, support, community, ecosystems, or even marketing. Programming paradigm is just one factor among many when people choose their programming languages.
- sweeneyrod 6y agoWho uses CPS in daily programming? Or do you mean using a compiler that uses it?
- hintymad 6y agoDefinitely in compiler, but also in daily JavaScript as a way to avoid deeply nested callbacks.
- Twisol 6y agoThe Visitor pattern is not much more than a CPS-style transform that lets you represent sum types in a language without them. A CPS transform for a computation of type `X` gives a computation of type `forall A. (X -> A) -> A`. That is, instead of evaluating to ("returning") a value of type `X`, you take a function that you deliver a valid of type `X` to, and return whatever it returns. CPS-transforming a sum type `X + Y` gives `forall A. (X + Y -> A) -> A`, and if you distribute over the sum you get `forall A. ((X -> A) * (Y -> A)) -> A`. The visitor is the pair of functions you pass in, `(X -> A) * (Y -> A)`, and the value decides which method to call. In either event, it returns whatever the chosen visitor method returns. (Dropping into Java syntax, this is the type of the `visit` method: `<A> A visit(Visitor<A> visitor)` -- and the Visitor is `interface Visitor<A> { A onX(X x); A onY(Y y); }`.)
- skrishnamurthi 6y agoCallback hell in JavaScript.
- emsal 6y agoI'm no expert but I think that the async-await pattern is quite similar to CPS.
- agumonkey 6y agoI cannot claim it is, but async/await, at least in ES seems to be a continuation monad without the do notation.
- hintymad 6y agoAnd I forgot to mention all kinds of monads in various languages.
- zelphirkalt 6y agoOne's missing out on a lot of advantages though, if one does not apply the paradigm quite broadly in a code base. Mostly referential transparency, how do you test your code, if you cannot be sure, that something is without side effects and have to check every single procedure? It takes away a lot of the appeal. If I write a program in functional style, I want some guarantees in return, which I don't get from half baked things. Easy testability, simple parallelization, composability of functions.