> Unfortunately, Elixir isn’t really built for writing code like this. Therefore, using Witchcraft can also result in:
> A certain amount of unnecessary ceremony
> Performance penalties
> Angry stares from people that read your code
The first point really bothers me. I hate writing boilerplate and I would use Haskell (which I don't know) if I really liked that kind of code (and types.)
I was rolling my eyes when I was reading %Algae.Either.Left and Right in the code examples. That's in part because I'm not familiar with those concepts (see point 3) and in part because it lowers the signal to noise ratio.
The second point could be important but generally is not or I'd be using Go, Rust, C++.
The third one does not apply if all the team agreed to use Witchcraft. If they didn't, you'd better stick to plain Elixir or deserve those looks.
I'm not sure about this. Maybe the example is way too simple but, as the author stated, this can be easily done with already established patterns in Elixir so I don't really see the point/benefit of this. If you want to learn more about working in a Haskell-style there is always Haskell (as is said at the end of the article).
But it is a well written article and easy to follow, so I guess it achieves its goals.
Thanks for the comment, it's not the first time I read this feedback. Perhaps it was a misplay: I wanted to make the first article as accessible and short as possible so I chose something that already exists in Elixir and tried to point out the fact that this generalizes over what you can do with with in Elixir. But I definitely should have also included stuff that goes further.
Will definitely try to do something more awesome next time, sorry!
I think this is akin to the general problem people face when trying to convey why Haskell (or a Haskell-like library) is useful/awesome to them to a target audience that isn't already familiar with the subject.
Simple and straightforward examples struggle to show any benefits that generalizations could/would provide. Complex examples are hard to explain without loosing most of the audience in terminology they don't understand. Or they just go on for way too long because they constantly drift off into explanations that don't really move the overarching subject forward.
> Simple and straightforward examples struggle to show any benefits that generalizations could/would provide.
Using Haskell you can use do-notation (with lists, Maybe and Either) as a simple example that should show the user the advantage of generic monads. (Just don't show them the problems with composability of monads or 'do-notation considered harmful' ;).
Never used Haskell but rather F#/OCaml and immediately fell in love with its maybe monads and partial function application. Couple years later I dipped my toes into Erlang and my initial disappointment with the absence of these constructs was replaced with intoxication upon my discovery of pattern matching. It is interesting to see this attempt at a best of both worlds but it only satisfies a curiousity at this point and not a need - everything just looks like pattern matching envy now.
Actually, I think Elixir's pattern matching is slightly worse than OCaml simply because there's no in-built syntax for multiple matches pointing to the same clause. Ex:
(* In OCaml *)
type t = A | B | C | D
match A with
| A | B -> "something"
| C | D -> "else"
And in elixir:
case :a do
a when a in [:a, :b] -> "something"
a when a in [:c, :d] -> "else"
end
And of course, you lose exhaustiveness from type information, but that's a preference.
But, more to the point, I think what GP's referring to is partial function definitions via pattern matching on the arguments. That is intoxicating, and I wish OCaml had that.
No. Stop. Do not force other language abstractions and paradigms into a programming language.
Just because you created a Haskell-like bastard in Elixir will not help you "bring Haskell or Purescript into company via Elixir" (from Witchcraft empty site)
Just to be clear, I am not a huge fan of forcing paradigms, but I thought that exploring other paradigms is nice, and giving the people to do that while on familiar ground (in Elixir) is also nice.
That's why the article is full of disclaimers of "don't force this on other people in production if they don't want it pls" :)
1) I don't know Haskell
2) I do know Elixir
3) I have no desire to use WitchCraft in a prod system
4) Because of this article I'm now curious about Haskell and its type systems, and would consider giving Haskell a go.
That was a nice article, however with a few caveats:
- I don't understand why you would use either, composed of left and right; where you could use result, composed of ok and err, which would be closer to regular Elixir.
It's historically like that in Haskell, and that's how the library defines it. I agree that Result is much clearer, and would love to use it here. But then I would also have to go through how to use Algae to define the type instead of using it out of the box, which would make the article longer.
Similarly with typechecking -- Elixir is dynamically typed, not everyone uses dialyxir, and to bring that whole story inside would also complicate the article.
I plan to continue exploring this space, and perhaps I will slowly understand how to best introduce these ideas to Elixir people correctly, but right now I am just trying to approach it from different kinds of angles. Thank you for the comments. :)
This is one of the reasons I dislike title case. If you don't use title case, the title would be "Function programming in Elixir with Witchcraft", which makes it obvious that Witchcraft is something or someone and not the activity.
> Unfortunately, Elixir isn’t really built for writing code like this. Therefore, using Witchcraft can also result in:
> A certain amount of unnecessary ceremony
> Performance penalties
> Angry stares from people that read your code
The first point really bothers me. I hate writing boilerplate and I would use Haskell (which I don't know) if I really liked that kind of code (and types.) I was rolling my eyes when I was reading %Algae.Either.Left and Right in the code examples. That's in part because I'm not familiar with those concepts (see point 3) and in part because it lowers the signal to noise ratio.
The second point could be important but generally is not or I'd be using Go, Rust, C++.
The third one does not apply if all the team agreed to use Witchcraft. If they didn't, you'd better stick to plain Elixir or deserve those looks.