I've been a noticing a trend recently whereby all the standard Erlang advocacy articles, tutorials and feature overviews are taken, have 's/Erlang/Elixir' run on top of them and reposted as if they're all novelties of Elixir.
Author here. My intent was never to say that this feature is something unique to Elixir. The intent was to introduce pattern matching to people new to it with a solid example. It just happened that my choice of language was Elixir and I'm aware that it wouldn't have been possible in Elixir if Erlang didn't had it in the first place :).
Binary pattern matching is commonly used in Erlang/OTP and given Elixir being used in nonspecific-to-Erlang contexts it makes sense to showcase them in the new Elixir language application context.
No duplicity on the part of the author if you ask me :)
I don't know where you got this impression from. It's pretty much never explicitly stated that anything is Elixir-specific. It just so happens that Elixir is the top horse of today for representing the Erlang ecosystem and so that's the vehicle people choose to present the features of that ecosystem, mostly.
> It just so happens that Elixir is the top horse of today for representing the Erlang ecosystem and so that's the vehicle people choose to present the features of that ecosystem, mostly.
On HN maybe, but out there it is erlang ahead by more than just a noselength. Elixir is nice and promising but by no objective measure is it 'the top horse'.
I've been noticing a trend recently whereby all the standard BCPL advocacy articles, tutorials and feature overviews are taken, have 's/BCPL/[some newer language]' run on top of them and reposted as if they're all novelties of [some newer language].
Seriously, though, I don't get this critique? It's not like binary pattern matching was novel in Erlang, either. Personally, I'm just happy to see an article on binary pattern matching (in any language!) on hn.
It's just that the complete lack of mention of Erlang, the jab at OOP languages (which is ironic given the actor model is relatively OO) and presenting the reuse of an Erlang construct as an Elixir novelty reeks of magpie hype. It's like the old joke about Ruby being renamed Rails, I have a feeling Erlang is being renamed to Elixir.
Well, if it is truly unexpected that it doesn't match the data, then you should just blow the process up and have it be automatically restarted by a supervisor. If the pattern is an alternative format, or something that you'll actually want to match, you just define another function with that pattern to test it against.
Elixir code examples seem to come out very concise and elegant. It's similar to Clojure in that way, with the emphasis on dynamic typing, immutability, and functional programming. A major difference is the emphasis on pattern matching (I know Clojure has this in libraries, but it's much more idiomatic in Elixir).
Makes Elixir a nice stepping stone to functional programming from dynamic languages like Ruby and Python.
"Stepping stone" suggests only part of a journey -- is Elixir incomplete or deficient as a functional programming language? What might the next step be?
17 comments
[ 3.2 ms ] story [ 51.6 ms ] threadNo duplicity on the part of the author if you ask me :)
On HN maybe, but out there it is erlang ahead by more than just a noselength. Elixir is nice and promising but by no objective measure is it 'the top horse'.
Seriously, though, I don't get this critique? It's not like binary pattern matching was novel in Erlang, either. Personally, I'm just happy to see an article on binary pattern matching (in any language!) on hn.
It's just that the complete lack of mention of Erlang, the jab at OOP languages (which is ironic given the actor model is relatively OO) and presenting the reuse of an Erlang construct as an Elixir novelty reeks of magpie hype. It's like the old joke about Ruby being renamed Rails, I have a feeling Erlang is being renamed to Elixir.
http://joearms.github.io/2013/05/31/a-week-with-elixir.html
Makes Elixir a nice stepping stone to functional programming from dynamic languages like Ruby and Python.
It's an easier leap than jumping from Ruby into a strict, strongly typed functional language like Haskell, Ocaml, or Scala.