Let's not forget Python. Python is quite versatile as it has about everything for FP (but also OOP). JS as well.
More on point, I quite like Elixir - which is one step better for FP than even Erlang. I love FP all the way, though sadly it's not promoted enough in my circles :(
Most Python users are unfamiliar with Lisp or Scheme, so the name is confusing; also, there is a widespread misunderstanding that lambda can do things that a nested function can't
And how can Elixir "be better for FP" than Erlang? Elixir may provide additional creature comforts but that has little to do with FP. Both implement FP as a means to an end, not an end in itself.
Elixir is "better for FP" as an argument to the value of a platform that primarily oriented towards FP. Some arguments against late-day FP adoption are the performance of FP languages (well, less the language itself but the underlying platform). Elixir comes with some improvements, including better use of concurrency (without noticeable performance degradation) under BEAM.
Maybe Guido van Rossum had a thing against FP. But despite that article from 2005, all those functions are faring well in Python. They do what they're meant to do so the support is there. But there's an argument to be had about what it means for a language to be a FP language. Map-reduce (with extended map/reduce/filter) is a pattern. If the language provides the implementation of the pattern, that's great but as long as it can be implemented without productivity or performance penalties, that's fine by me.
Go has nowhere near the same support for FP patterns (oficially) but there are quite a few libraries providing monads in Go. Guess what, it works :)
Elixir comes with some improvements, including better use of concurrency (without noticeable performance degradation) under BEAM.
Both Erlang and Elixir use the same BEAM so there is likely no performance difference. The Elixir compiler would have to produce AST/bytecode that is somehow more efficient than Erlang's output - and I somehow doubt that. The entire point of the BEAM is to create a highly concurrent (and resilient/fault tolerant) operating environment; using FP was motivated by the benefits afforded by "immutability by default" (and consequently persistent data structures) in a Shared Nothing architecture. Even back in a 2014 Talk Bryan Hunter claimed that
60% of the world's mobile traffic is going through Erlang
… obviously with a fairly limited pool of developers.
Robert Virding
@rvirding
@YungTseTech @jlouis666 Well then, just more cases where it's in wide use but you don't see it or know about it. It's really great it's being used but a bit depressing that no one knows about it as you continually hear "what's Erlang, why should I learn/use it as no one uses it?"
11:36 AM - 13 Jun 2019
One of the more notable improvements in Elixir are hygenic macros - but that has nothing to do with FP.
… and perhaps they all have a point that Python isn't an ideal foundation for "functional programming" - while the occasional "functional tactic/trick" can be helpful.
JS has the advantage that Brendan Eich had Scheme on the brain when he designed it, so it can lend itself to some Scheme-y approaches but JS is still an imperative language as in general neither immutability nor recursion are particularly efficient.
there are quite a few libraries providing monads in Go. Guess what, it works :)
The beauty of algebraic structures is that they are like patterns with superpowers. Implement an algebraic structure to strictly conform to its specific set of "laws" and you get some implicit and powerful benefits.
The problem is that using these implementations without the safety net of a language or environment that yells at you when you start to "break those laws" can get you into trouble when you need those guarantees the most.
Absolutely, but the subject was more about languages with support for the practice. JS and Python are truly multi paradigm, other aspects notwithstanding. I wouldn't use Python (performance issues mainly) , but doesn't change the point.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Let's not forget Python. Python is quite versatile as it has about everything for FP (but also OOP). JS as well.
More on point, I quite like Elixir - which is one step better for FP than even Erlang. I love FP all the way, though sadly it's not promoted enough in my circles :(
Thank you for sharing your insight 🙏❤
Guido van Rossum was never in support for the functional approach - so I would expect that support would be superficial at best.
The fate of reduce() in Python 3000:
And how can Elixir "be better for FP" than Erlang? Elixir may provide additional creature comforts but that has little to do with FP. Both implement FP as a means to an end, not an end in itself.
Elixir is "better for FP" as an argument to the value of a platform that primarily oriented towards FP. Some arguments against late-day FP adoption are the performance of FP languages (well, less the language itself but the underlying platform). Elixir comes with some improvements, including better use of concurrency (without noticeable performance degradation) under BEAM.
Maybe Guido van Rossum had a thing against FP. But despite that article from 2005, all those functions are faring well in Python. They do what they're meant to do so the support is there. But there's an argument to be had about what it means for a language to be a FP language. Map-reduce (with extended map/reduce/filter) is a pattern. If the language provides the implementation of the pattern, that's great but as long as it can be implemented without productivity or performance penalties, that's fine by me.
Go has nowhere near the same support for FP patterns (oficially) but there are quite a few libraries providing monads in Go. Guess what, it works :)
Both Erlang and Elixir use the same BEAM so there is likely no performance difference. The Elixir compiler would have to produce AST/bytecode that is somehow more efficient than Erlang's output - and I somehow doubt that. The entire point of the BEAM is to create a highly concurrent (and resilient/fault tolerant) operating environment; using FP was motivated by the benefits afforded by "immutability by default" (and consequently persistent data structures) in a Shared Nothing architecture. Even back in a 2014 Talk Bryan Hunter claimed that
… obviously with a fairly limited pool of developers.
One of the more notable improvements in Elixir are hygenic macros - but that has nothing to do with FP.
The "hostility" continues to this day, e.g.:
… and perhaps they all have a point that Python isn't an ideal foundation for "functional programming" - while the occasional "functional tactic/trick" can be helpful.
JS has the advantage that Brendan Eich had Scheme on the brain when he designed it, so it can lend itself to some Scheme-y approaches but JS is still an imperative language as in general neither immutability nor recursion are particularly efficient.
The beauty of algebraic structures is that they are like patterns with superpowers. Implement an algebraic structure to strictly conform to its specific set of "laws" and you get some implicit and powerful benefits.
The problem is that using these implementations without the safety net of a language or environment that yells at you when you start to "break those laws" can get you into trouble when you need those guarantees the most.
Thanks for sharing all this useful information 📚👍
Functions are very expensive in python. The only truly performant python libraries are written in C.
Thanks for the input 😉👍
Absolutely, but the subject was more about languages with support for the practice. JS and Python are truly multi paradigm, other aspects notwithstanding. I wouldn't use Python (performance issues mainly) , but doesn't change the point.
JavaScript as well which is a multi-paradigm language
Indeed, very much so