4 ms·

If you truly think "functional programming is natively supported in almost all modern languages" then you really don't know what modern FP is about. For instan

If you truly think "functional programming is natively supported in almost all modern languages" then you really don't know what modern FP is about. For instance implementations of monadic control flow, effect systems, higher kinded types, algebraic data types, exhaustive pattern matching etc are all laughably unergonomic or entireley missing in most "popular"/"enterprise" languages. Just having a labmda doesn't FP make. To me, FP in modern functional languages provides abstractions that enable much more straightforward problem solving and understandable code with fearless refactoring. Haskell and Ocaml are the pragmatic leaders here I think, with honorable mentions for things like Scala3, F#, and (kindof?) clojure. (edit spelling)

lolinder 4y ago
I've spent more time studying programming languages than anyone else I know, and I understand FP very well. The argument that I'm making is not that FP has nothing to offer (I dearly hope that many more features from FP languages make it into the mainstream!), it's that FP comes with a set of restrictions on what can and cannot be done, and those restrictions do not seem justified to the majority of programmers. It is as uncomfortable for them to work with Haskell as it is to work with Rust, but unlike with Rust they can't see why they should bother. The author of the article hopes to build a new functional programming language that will finally get traction by making a few different choices. I think that this is a mistake because a single-paradigm language will never reach mainstream adoption. Pragmatically multi-paradigm languages have historically been the only ones to get traction, and I believe that the reason is because they explicitly endorse multiple possible approaches, even if their support for any given approach isn't as strong as a specialized tool. They may not support FP as well as Haskell or OO as well as Smalltalk, but by sacrificing purity they buy pragmatism, and allow programmers more flexibility in problem solving.
- igouy 4y ago
  > They may not support FP as well as Haskell or OO as well as Smalltalk… The Smalltalk Collection enumeration protocol was probably the first time I'd seen anything like (1 to: 100) select: [ :n | n isPrime ] https://cuis-smalltalk.github.io/TheCuisBook/Fun-with-collections.html#index-block https://cuis-smalltalk.github.io/TheCuisBook/Fun-with-collec... (Now I recall, I had been required to write some Tower of Hanoi snippet in either Lisp or Prolog, and I'd used Prolog.)
bjourne 4y ago
> For instance implementations of monadic control flow, effect systems, higher kinded types, algebraic data types, exhaustive pattern matching etc are all laughably unergonomic or entireley missing in most "popular"/"enterprise" languages. You don't need all that garbage in most languages because they allow mutation. In Haskell you can't have a class instance with a few variables so you end up with all these endofunctors, monomorphisms, and applicatives. And I would argue that, say, implementing Chaitin's algorithm, which involves filling and emptying a stack and destructuring a graph is not at all straightforward in a functional language.
lelanthran 4y ago
> To me, FP in modern functional languages provides abstractions that enable much more straightforward problem solving and understandable code with fearless refactoring. Maybe, but they remove other abstractions. The lack of Haskell's popularity is a clear indication that the abstractions added are not as valuable to programmers as the abstractions removed.
- ParetoOptimal 4y ago
  > The lack of Haskell's popularity is a clear indication that the abstractions added are not as valuable to programmers as the abstractions removed. No it's not. At most it's an indication that of the group programmers familiar with Hakell's abstractions that they aren't enough to try the language more. For it to be a clear indication those programmers would actually have to learn to effectively use Haskell's abstractions and compare it to a version in their former language that doesn't utilize the abstractions. Almost nearly no one does this however... I can recall one instance that comes close: http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-replacement-for-0install/ http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-r... However that's not a comparision of abstractions.
  - lelanthran 4y ago
    > For it to be a clear indication those programmers would actually have to learn to effectively use Haskell's abstractions and compare it to a version in their former language that doesn't utilize the abstractions. No one tries everything, there's just no time to try all the possible alternatives. Lack of popularity may not mean that the unpopular thing is bad, but it ain't a indication that further study would reveal it to be good. In this particular case, Haskell isn't selling painkillers, it's selling vitamins. Few who have tried it go on to adopt it - it clearly isn't solving any immediate problem.

lolinder 4y ago

I've spent more time studying programming languages than anyone else I know, and I understand FP very well. The argument that I'm making is not that FP has nothing to offer (I dearly hope that many more features from FP languages make it into the mainstream!), it's that FP comes with a set of restrictions on what can and cannot be done, and those restrictions do not seem justified to the majority of programmers. It is as uncomfortable for them to work with Haskell as it is to work with Rust, but unlike with Rust they can't see why they should bother. The author of the article hopes to build a new functional programming language that will finally get traction by making a few different choices. I think that this is a mistake because a single-paradigm language will never reach mainstream adoption. Pragmatically multi-paradigm languages have historically been the only ones to get traction, and I believe that the reason is because they explicitly endorse multiple possible approaches, even if their support for any given approach isn't as strong as a specialized tool. They may not support FP as well as Haskell or OO as well as Smalltalk, but by sacrificing purity they buy pragmatism, and allow programmers more flexibility in problem solving.

igouy 4y ago
> They may not support FP as well as Haskell or OO as well as Smalltalk… The Smalltalk Collection enumeration protocol was probably the first time I'd seen anything like (1 to: 100) select: [ :n | n isPrime ] https://cuis-smalltalk.github.io/TheCuisBook/Fun-with-collections.html#index-block https://cuis-smalltalk.github.io/TheCuisBook/Fun-with-collec... (Now I recall, I had been required to write some Tower of Hanoi snippet in either Lisp or Prolog, and I'd used Prolog.)

bjourne 4y ago

> For instance implementations of monadic control flow, effect systems, higher kinded types, algebraic data types, exhaustive pattern matching etc are all laughably unergonomic or entireley missing in most "popular"/"enterprise" languages. You don't need all that garbage in most languages because they allow mutation. In Haskell you can't have a class instance with a few variables so you end up with all these endofunctors, monomorphisms, and applicatives. And I would argue that, say, implementing Chaitin's algorithm, which involves filling and emptying a stack and destructuring a graph is not at all straightforward in a functional language.

lelanthran 4y ago

> To me, FP in modern functional languages provides abstractions that enable much more straightforward problem solving and understandable code with fearless refactoring. Maybe, but they remove other abstractions. The lack of Haskell's popularity is a clear indication that the abstractions added are not as valuable to programmers as the abstractions removed.

ParetoOptimal 4y ago
> The lack of Haskell's popularity is a clear indication that the abstractions added are not as valuable to programmers as the abstractions removed. No it's not. At most it's an indication that of the group programmers familiar with Hakell's abstractions that they aren't enough to try the language more. For it to be a clear indication those programmers would actually have to learn to effectively use Haskell's abstractions and compare it to a version in their former language that doesn't utilize the abstractions. Almost nearly no one does this however... I can recall one instance that comes close: http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-replacement-for-0install/ http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-r... However that's not a comparision of abstractions.
- lelanthran 4y ago
  > For it to be a clear indication those programmers would actually have to learn to effectively use Haskell's abstractions and compare it to a version in their former language that doesn't utilize the abstractions. No one tries everything, there's just no time to try all the possible alternatives. Lack of popularity may not mean that the unpopular thing is bad, but it ain't a indication that further study would reveal it to be good. In this particular case, Haskell isn't selling painkillers, it's selling vitamins. Few who have tried it go on to adopt it - it clearly isn't solving any immediate problem.