A Week with Elixir
joearms.github.io
joearms.github.io
In fact, if you look at his paper on the development of Erlang [1] while at Ericsson, which is coincidentally a juicy, fascinating read, Armstrong is being very forthcoming about the struggle to develop the language, in particular developing a good syntax, and also very forthcoming about the involved parties' lack of experience with language design; in particular, the Prolog-like syntax seems less of a planned decision than a side-effect of the first implementations being written in Prolog itself, and following the path of least resistance. Also, it worked.
At any rate; it seems clear to me that Armstrong values the principles behind Erlang's design (concurrency, immutability, fault tolerance and so on) more than the actual syntax. I wonder, at this point, how amenable he would be to larger syntax changes to Erlang itself, or if he is happy with the fact that Elixir is a completely separate project.
(There is something weird about the effusive tone and surreal humour in the blog post, though. Is this his new "Erlang evangelist voice", or has he always been writing in this way?)
[1] https://docs.google.com/viewer?url=http%3A%2F%2Fwebcem01.cem...
Elixir brings a lot of good stuff onto the table. I hope the Elixir community incorporates the changes Joe Armstrong suggests.
One in particular: f.() makes perfect sense in the Ruby world because everything is an object (we're sending the '()' message to the 'f' object); but things are built out of functions in the Erlang world, and f() makes more sense there. There are no objects or messages to send them, so 'f.()' gets parsed as an extra dot at the end of the name. I think Armstrong's other suggestions follow in the same vein.
The point isn't to try to make Elixir have a Ruby-like syntax so much as, having distilled the syntax design principles developed in the Ruby community, apply it in Elixir.
It's just practice. It no longer trips me up, but I still find it klunky and unpleasant after nigh on 6 years of medium-duty usage.
lists:map(fun (X) -> X + 1 end, [1, 2])
map (+1) [1, 2]
IdentifierA = operationA(ArgA),
IdentifierB = operationB(IdentifierA, Something),
... case Something of
{ok, Val} ->
do_something();
_Error ->
barf()
end,
[ N + 1 || N <- [1,2] ]. "Today there is an unhealthy concentration on language and
efficiency and NOT on how things fit together and
protocols - teach protocols and not languages.
And teach ALGORITHMS."
No higher praise is there, in my book...
I can't help but compare it to CoffeeScript. Sure, CoffeeScript papers over some inconveniences of JavaScript, but at the end of the day I find myself writing JavaScript in a disciplined way instead of reaching for yet another abstraction. I realize it's not a good comparison as CoffeeScript compiles to JS while Elixir and Erlang both compile to a shared VM (BEAM), but I don't think Elixir has added enough new ideas to warrant focusing on it in favor of Erlang, yet (for me at least). That may change in time.
With CoffeeScript I always end up translating to JavaScript into my head so cognitively it's more effort for me. Another JavaScript super-set might liberate me from thinking of otherwise trivial things and leave more room for planning or "registry" access.
Standard library of Elixir should be available to pure Erlang too, right? From what I recall from interoperability docs.
Could you post a tiny little example of metaprogramming in Elixir that would appeal to quite experienced Erlang developer who knows about parse transforms? I am NOT dismissing Elixir, I know too little about it and I want to finally learn about some feature that would convince me to learn some Elixir.
2) Yes, interoperability is there and, just like you can use Scala libraries from Java, you just need the Elixir runtime in your path.
3) My favorite is from the String.Unicode module:
defmodule String.Unicode do
# ...
def upcase(""), do: ""
lc { codepoint, upper, _lower, _title } inlist codes, upper && upper != codepoint do
def upcase(unquote(codepoint) <> rest) do
unquote(upper) <> upcase(rest)
end
end
def upcase(<< char, rest :: binary >>) do
<< char >> <> upcase(rest)
end
# ...
endAs for Scala and CoffeeScript... well, that's a tough one. On some level they are very similar, but the differences are huge. I'd say they both, and Elixir, are in the same class of things with CS being on the lower level than Scala and Elixir.
[1]: http://pragprog.com/book/elixir/programming-elixir [2]: http://www.youtube.com/watch?v=m32CGvzixrQ
As an aside, have you seen Joxa? It's a LISP for the Erlang VM. I'm really not trying to be a downer about this, I think it's great that the Erlang VM is having these new languages pop up and José Valim is one of my favorite Ruby programmers, so I have high hopes for Elixir. I hope after I get better at Erlang I can revisit Elixir and appreciate the things you are talking about.
I like Erlang way of using lowercase for atoms and uppercase for variables, in Elixir they use ':' sigil to denote atoms like in Ruby, this makes code much more verbose, since atoms are widespread in Erlang and also used for module names.
Elixir should take good parts of Ruby, not sigils, which are inherited from Perl. They are the reason I dislike Ruby's internal DSLs, b/c they are not English, but English with sigils.
If possible I would get rid of commas, I.e. [1 2 3] instead of [1,2,3] .
I agree about f.() being ugly. if function names were lowercase and variables uppercase - there would be no need to introduce new fun call syntax.
Also agree about docstrings moved inside the functions (like in Python and Clojure). Same apply to dialyzer typespecs.
I think single assignment should be default, but there are should be way to explicitly override it, i.e.:
a = 1
a = 2 - bad match, but
'a = 2 - ok a = 1
^a = 1 - ok
^a = 2 - bad matchI think it will be a good companion to the books from Pragmatic Programmers and O'Reilly. Jose works through a real-world project. You can see how he writes code with Elixir, uses metaprogramming, converts code to run concurrently, etc.
I was impressed with the syntactical consistency that makes more sense than Ruby, such as putting "do" after "def". You can write native-looking structures in Elixir that wouldn't be possible in Ruby (such as an if-then).
If you are irritated by the idea/syntax implementation of pattern matching, folds/unfolds, recursion, immutability, function guards, partial function application, function currying, and higher-order functions then you won't enjoy any language that has as its basis, the functional paradigm.
Once you grok the functional idioms used in Erlang, the syntax becomes "not that bad". Granted Elixir is great, its meta-programming features are awesome, but it doesn't "get rid of that yucky functional programming stuff" (which I don't think is yucky at all, after Haskell I can't think in anything BUT the functional paradigm).
I'm also one of those people that think homoiconicity and sexps are beautiful...
With many punctuation infix operators (see Scala for an extreme case) people who don't use the language won't understand the code, and you'll have to use an appropriate search engine or emacs mode to look up docs, but it's worth it for what you get in exchange.
It would be nice for the community to standardize on unicode glyphs for enhanced visual representation of ascii-art operators like |> <- etc. (so that online syntax highlighters / code review / diff interfaces show the same as your editor). Pretty glyphs instead of mere ASCII could really help readers (the source code should still be ASCII).
http://www.outputlinks.com/html/people/Entrepreneurial_Spiri...
http://www.xerox.com/digital-printing/workflow/printing-soft...
We used Xerox Elixir to typeset forms pre-press for a Xerox DocuTech.
iex(1)> f = fn x -> x + 1 end
#Function<erl_eval.6.82930912>
iex(2)> f()
(UndefinedFunctionError) undefined function(stack trace trimmed...)
iex(2)> f.(1)
2
This was José Valim's rationale on the mailing list. Once you understand what's involved, f.() begins to look like a pretty good compromise.
Funny, no one talks about the other phenomenon. The one where experts think things are right and then they turn out not to have been. I guess that phenomenon just isn't as interesting.
http://en.wikipedia.org/wiki/Confirmation_bias http://en.wikipedia.org/wiki/Cherry_picking_(fallacy)
If you're thinking operators your probably doing it wrong in functional programming.
It's simply another higher-order function that enables function composition. g |> f = λx → f (g (x))
edit: My reasoning might be really flawed as I have no idea if erlang/elixr can define functions that look like `operators` and therefore don't know if `|>` is built in. Yet, you shouldn't assume |> is some magical thing, but respect it as a higher-order function in my opinion.
Stating that the creator of Erlang is doing FP wrong is a bold statement.
Do you have an inkling of who the 'someone' is in this case?
Let me help you, in case you don't:
http://en.wikipedia.org/wiki/Joe_Armstrong_%28programming%29
But you are also making statements full of adjectives and subjective descriptions such "makes me cringe" and "probably doing it wrong". That is quite a bit of flair for someone expecting logical and nice refutation of their own statements.
If you jump in the middle of the discussion, throwing around "you're wrong, you're wrong, you're wrong" at everyone then don't be surprised you get replies that are equally accusatory and harsh.
BTW I still don't see what is really so cringe-worthy in calling it an operator. It is just syntactic sugar. Call it green tomatoes if you want. Joe calls it an operator. I understand what Joe means. It is like yelling at someone talking about function default arguments and saying "ha! bit it is all assembler underneath, all this is wrong, it is just registers and pointers!".
P(author_doing_fp_wrong) < P(author_doing_fp_wrong | author_invented_erlang)
This is incorrect. An appeal to an authority is a valid argument. The fallacy is an appeal to a false authority.
When you make a statement like "it makes me cringe", you are making an appeal to your own authority. Cringe-worthiness has nothing to do with reasoning or logic: it's only relevant if your opinion matters, and your opinion only matters if you're (1) the audience of the argument or (2) an authority. If you do not claim to be an authority, you are dismissing your own argument: you acknowledge its own fallaciousness.
This is always the case, though. If I say, "Fish need water, fish are good, so we should provide water," you have to independently verify my claims yourself or choose to accept the assertion.
No claim is exempt from this.
> I think many eod consider that a fallacy.
Sorry, I don't know what an "eod" is.
Unless you mean "end of day", in which case you're making an argument from popularity which, I'm sure you know, is a fallacious argument because popularity isn't a valid authority for determining whether or not something is a fallacy.
Regardless of whether the statement was an appeal to authority, regardless of whether Joe Armstrong or arianvanp are "true authorities" or if that's even objectively determinable, regardless of whether we consider inductive arguments as persuasive... regardless of all that.. we have brains. You can see what Joe Armstrong wrote. You can pick up Erlang and Elixir and use them yourself. You can see what arianvanp wrote. Some of us (excepting jacquesm, of course) have the capacity to use our own brains to consider the validity of the arguments at hand without having to resort to the lazy inductive argument that Joe Armstrong is smart about Erlang and therefore is probably right.
If you have a brain, use it instead of checking it in at the door.
That's why I wrote the comment. arianvanp brought them up, was pedantic, and also wrong about their usage.
See masklinn's response for how to avoid stupid responses like this one. Or kvb's. Or even rtdsc's.
Because when you make a bunch of rude and unfounded accusations against not 'an' authority in the field but 'the' authority in the field you come across as not having done your homework.
It would be like telling PG what hackernews is supposed to be (I think we've had that one) or to tell Abelson why he doesn't understand the basics about lisp or scheme.
At some point appeals to authority are perfectly ok, not every dumb point made in an insulting and rude way needs to be refuted by textbook rules.
And really, not being aware who the players are and attempting to play the game is a-ok with me, just make sure that you have your t's crossed and your i's dotted when you do and nobody will call you out for making a fool of yourself.
And yes, it does matter whether it is Joe Armstrong or not, and how matters regardless of who it is.
But why? In the same situation but talking to a non-expert, do you magically come across as having done your homework?
What's wrong with telling Abelson he doesn't understand the basics about lisp? Are these people infallible? Does your hero-worship allow for all-knowing experts to sometimes forget shit? Does senility factor into the equation, or do we drop to our knees at every utterance until they die?
I had a similar thought when reading the article, unaware to who wrote it... I wondered how currying and the like factored into the language, and thought that comparing |> to unix pipes was a big simplification. And whilst this simplification might be intentional for the article's purpose of giving an overview, it instead read - to me at least prior to realising who the author was - like the author was not fully informed on its use in other FP languages.
Sorry to see mr. Armstrong does not meet your requirements, would you like to take the matter up with mr. McCarthy instead?
> And this particular thread seems to be more grounded in discussing FP concepts than Erlang.
So? That makes it ok to speak in a disparaging manner about someone who did more for reliability of complex FP systems than anybody else that I'm currently aware of? And to fail to even do the author the courtesy of checking his/her credentials before firing off an ill thought out rant?
Really, not recognizing your elders and betters, -5 points, not knowing who they are, -50 points and being dead wrong on top of all that -500. The article is interesting for one reason only, it's Joe Armstrong writing about a new entrant on the VM that he designed and for those that are interested in such stuff his opinion carries a lot of weight. To dismiss his writings as the drivel of just another anonymous 'someone' who couldn't be bothered to do his homework about FP is ridiculous.
Anyway, I'm done with this thread.
I'm glad you've decided to follow your own advice and stop digging.
Ignoring your original reply to arianvanp, you'll see that interesting discussion has arisen in response to their original bold statement. This is why I read HN.
You have entered this thread, seemingly to show off your superior knowledge of PL creators, without actually contributing to the discussion. My attempt to diffuse things clearly had the opposite effect (FWIW, I was trying to point out that the words used in the article could lead to the interesting discussion that has happened, and certainly wasn't defending an attack on Joe Armstrong - an attack that you have read into but I don't feel is there).
Instead, what has been achieved?
To go meta for a moment, this is the problem with with HN that gets discussed from time to time (and I am well aware that I'm replying to a highly active user). Why do people feel the need to be so combative, just to win internet points (something someone is down 555 of by your count)? Perhaps after having pointed out who the author was, you could have explained why that matters. Maybe we aren't all as clever as you are.
Yes, arianvanp's original post was also phrased in a somewhat combative way, but at least it sparked interesting discussion. This subthread is the antithesis of that.
I'm sorry but that simply makes no sense. Yes, many FP languages have custom & customizable operators. They still have built-in operators which are actual operators for real. And there are also FP languages which do not have custom & customizable operators. Erlang is one of the latter.
> My reasoning might be really flawed as I have no idea if erlang/elixr can define functions that look like `operators`
It can not.
* Erlang, nor Elixir, has currying. And they can't define their own infix identifiers/operators. This severely limits the way the language works, and you need built in support. * the |> notion is not even a higher-order combinator in Elixir. It is a special-case built-in you cannot redefine.
I agree with you that this is a bad design decision if you are to evolve the Erlang language :P
I can say:
plus_one = &1 + 1
Enum.map [1,2,3], plus_one
Shouldn't Joe Armstrong know what function composition is when he sees it? (Although it is really weird that it slots into the first argument position.)
do x <- f
y <- g
return $ h (x + y)
f >>= (\x -> g >>= (\y -> return (h (x+y))))