pmjoe
Where Elixir fits in the functional programming world?
I don’t want this thread to become a flamewar, but I was having some huge discussions with a few friends regards functional programming. First of all, my background is in imperative languages, I understand the benefits and value proposition of FP, but I don’t have a math background, nor the academic interest to learn all the bases and proofs of FP.
Do you see Elixir a “less qualified” FP language than something like Haskell? Looks like lately FP means having an effect system and being statically typed, which kinda of rules out most of the languages apart from Haskell and a handful others. Even languages like Scala and Ocaml have lots of escape valves and they can fall into a imperative approach and do effects anywhere without the compiler knowing it, so it’s best effort at the end of the day.
Most Liked
gregvaughn
I know the kinds of conversations and opinions you’re talking about. It’s important to realize that Haskell has come out of the academic community, and they’re exploring/implementing advanced computer science features. Elixir comes from Erlang, which was created to solve a business problem and focused on pragmatism (resilient systems even in the face of hardware failure) over purity. They have different goals and different language design tradeoffs, but they both treat functions as first class. I wish the academics had some other phrase besides “pure”/“purity” to distinguish their language goals, but then again I suspect that terminology helps them feel superior, so they have little motivation to change it.
jam
IMO, elixir sits in the sweet spot. It’s what I see as FP-lite or pragmatic FP. I have a bias though to keep things simple and easy to reason about. “True” FP with monads and the like always struck me as prioritizing purity to the point where the code becomes difficult to grok. Perhaps there is a nirvana moment after spending substantial time with it.
100%
murrgelb
This is a very interesting discussion. We’ve seen effect-systems and immutability as characteristics (and even type systems - huh?).
I do 100% agree, that immutability is a differentiator for functional languages. However, what is also important is that functions are first-class. Passing functions as if they’re values and enabling higher order functions is the game-changer. This is what’s fundamental to implement different effect systems with ease. Monads? Sure just do it. Dependency injection? Free.
There are different ways to control side-effects. The trend in Haskell went from monad-transformers (which don’t compose) to free monads, to imitating an algebraic effect system. Man, the complexity. Scala did the same with catz and scalaz.
Elixir tends to be more pragmatic. What do we want to achieve? Is it for testing? Maybe use mocking or dependency injection? Is it for abstraction? Yeah, you can achieve 99% and implement composable abstraction without knowing category theory. We can do that, since we functions as first-class.
That said, I’d go with what @jam and @dimitarvp said: Elixir is a pragmatic functional programming language (as is e.g. clojure - no one will ever challenge clojure for not being functional).
Popular in Discussions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #javascript
- #code-sync
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








