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...
"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."
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),
...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.
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.
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.
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.
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 - okI 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).
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.
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.
Stating that the creator of Erlang is doing FP wrong is a bold statement.
* 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
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
See masklinn's response for how to avoid stupid responses like this one. Or kvb's. Or even rtdsc's.
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))))