6 ms·

For those not sure what Elixir is, think of it like this: elixir : erlang vm (BEAM) :: clojure : jvm Elixir's syntax is heavily influenced by Ruby but its sem

For those not sure what Elixir is, think of it like this: elixir : erlang vm (BEAM) :: clojure : jvm Elixir's syntax is heavily influenced by Ruby but its semantics and structure is very reminiscent of Clojure. Like Clojure you are constantly reminded you live on JVM, with Elixir you are constantly reminded that Erlang is under the covers and thats OKAY. Its really great stuff and the creator José Valim has really put thought, love and care into every part of the project. I highly suggest you take a look, you might be surprised at what you find.

cursork 13y ago
100% agreed. I've been looking at Elixir occasionally for a year or so... It's getting better and better. It certainly takes a lot from Clojure, but with a real Erlang / OTP twist. (It also recognises that "homoiconicity" doesn't always mean lisp). Elixir's Design Goals are stated here for those who've missed them: http://elixir-lang.org/blog/2013/08/08/elixir-design-goals/ http://elixir-lang.org/blog/2013/08/08/elixir-design-goals/
- rvirding 13y ago
  Elixir isn't homoiconic, it never was, and they no longer make that claim.
  - cursork 13y ago
    Kinda fair - I meant "homoiconic" in the loose sense of having macros that can manipulate expressions as data and which has mechanisms such as quote/unquote to do so. That's what many people see as the reason for homoiconicity after all. I put it in quotes, but maybe I should have said something about how languages can support sophisticated Lisp-like meta-programming without being a Lisp at all. Nonetheless, as I'm still learning (aren't we all?), I would love to hear what a truly homoiconic language has above something like Elixir with its quote, unquote and unquote_splicing. By truly homoiconic I mean that AST is equivalent to the written form. EDIT: I now realise you're not only rvirding, but that you wrote Lisp Flavoured Erlang https://github.com/rvirding/lfe https://github.com/rvirding/lfe so therefore (I hope) are in an even better position to educate!
    - rvirding 13y ago
      I would say that one restriction with the type of macros that elixir has, irrespective of whether we call it homoiconic or not, is that they can only manipulate existing forms in the AST, they can't define new syntactic forms. In elixir this means that you basically work with function calls. There is syntactic support for making the function calls look less like function calls but the macros you define are basically function calls. In Lisp you are free to create completely new syntactic forms. Whether this is a feature of the homoiconicity of Lisp or of Lisp itself is another question as the Lisp syntax is very simple and everything basically has the same structure anyway. Some people say Lisp has no syntax. Trying to build the AST that directly in elixir is quite difficult as the AST is not trivial even if it relatively simple and regular. Quote and unquote in macros do a lot of the work for you. At one level you could do something similar for Erlang but no one has actually gone all the way with it. Erlang uses parse transforms for that. They are more powerful but much more complex to use.
      - alco 13y ago
        I agree with all of the above. I would just like to add that in Elixir meta-programming does not always have to deal with macros. For example, this program somelist = ... # any kind of data, # could be loaded from file defmodule M do for {name, value} <- somelist do def lookup(unquote(name)), do: unquote(value) end end generates a set of functions from arbitrary input. This feature alone greatly improves productivity in certain use cases. While it is true that Erlang's parse transforms are more powerful by default, nothing would stop a willing heart from implementing token-level macros for Elixir. It would be a separate program that would parse source code before passing it on to the Elixir compiler. But given the straightforwardness of code generation in Elixir (as exemplified by the code above), coming up with such a program might prove to be even easier for the user than dealing with parse transforms in Erlang. This is a speculation on my part, so it'd be curious to see if anyone goes in this direction in the future.
      - vertex-four 13y ago
        One language that does support syntax extensions from macros is the Metalua extensions to Lua. There's a bunch of special syntax allowing you to hook into the parser and modify it while it parses a file.
leccine 13y ago
What is the advantage over Erlang? I guess this gives the syntactic sugar on the top of Erlang but I am not sure if this takes away the good parts of the language (pattern matching etc.) as well. Anyways, Erlang has a steep learning curve but if you invest the time it is pretty rewarding.
- rdtsc 13y ago
  It is different. It doesn't have a 100% advantage. In some case it just sort of inverted the choice Erlang made -- lower case variables, vs upper case. Lower case module names vs upper case etc. It has immutable data but not immutable bindings. Erlang has both as immutable. What that means is, you can do x = value1 then x = value2. In Erlang, like in mathematical notation, once you said X=value1 it is value1, it doesn't make sense to say X=value2 (it throws an exception). In either case you can't modify value1 in place for example by saying x[3]=4 or X[3]=4 ( <- I am making up syntax to illustrate here). Some like it one way some like it another. Elixir has better meta-programming, which is nice. In general, Erlang syntax is not the steepest learning curve. The steepest learning curve is to learn to use actors for concurrency and use functional programming for sequential parts. Elixir presents a more familiar syntax but the other learning curve parts are still there.
  - peregrine 13y ago
    I agree with this. Its not a panacea but in general it's way more developer friendly. Especially when a good chunk of developers come to expect to have basics like strings and library/syntax to support them natively. Erlang isn't horrible, and when you learn Elixir you WILL come to learn Erlang and its documentation.
  - leccine 13y ago
    Well you are making variables mutable. This is bad. One of the great features of Erlang and generally any functional programming language is immutability that makes defensive programming unnecessary. I would like to keep that... The rest of the stuff is great but it does not give enough value to me to not to use Erlang. Actors is a basic concept and message passing is definitely the way to go if you are building a distributed system. One of the biggest problems with Ruby and the imperative languages in general that it was designed for local execution so communication and distributing computation is more difficult than for example in Erlang.

cursork 13y ago

100% agreed. I've been looking at Elixir occasionally for a year or so... It's getting better and better. It certainly takes a lot from Clojure, but with a real Erlang / OTP twist. (It also recognises that "homoiconicity" doesn't always mean lisp). Elixir's Design Goals are stated here for those who've missed them: http://elixir-lang.org/blog/2013/08/08/elixir-design-goals/ http://elixir-lang.org/blog/2013/08/08/elixir-design-goals/

rvirding 13y ago
Elixir isn't homoiconic, it never was, and they no longer make that claim.
- cursork 13y ago
  Kinda fair - I meant "homoiconic" in the loose sense of having macros that can manipulate expressions as data and which has mechanisms such as quote/unquote to do so. That's what many people see as the reason for homoiconicity after all. I put it in quotes, but maybe I should have said something about how languages can support sophisticated Lisp-like meta-programming without being a Lisp at all. Nonetheless, as I'm still learning (aren't we all?), I would love to hear what a truly homoiconic language has above something like Elixir with its quote, unquote and unquote_splicing. By truly homoiconic I mean that AST is equivalent to the written form. EDIT: I now realise you're not only rvirding, but that you wrote Lisp Flavoured Erlang https://github.com/rvirding/lfe https://github.com/rvirding/lfe so therefore (I hope) are in an even better position to educate!
  - rvirding 13y ago
    I would say that one restriction with the type of macros that elixir has, irrespective of whether we call it homoiconic or not, is that they can only manipulate existing forms in the AST, they can't define new syntactic forms. In elixir this means that you basically work with function calls. There is syntactic support for making the function calls look less like function calls but the macros you define are basically function calls. In Lisp you are free to create completely new syntactic forms. Whether this is a feature of the homoiconicity of Lisp or of Lisp itself is another question as the Lisp syntax is very simple and everything basically has the same structure anyway. Some people say Lisp has no syntax. Trying to build the AST that directly in elixir is quite difficult as the AST is not trivial even if it relatively simple and regular. Quote and unquote in macros do a lot of the work for you. At one level you could do something similar for Erlang but no one has actually gone all the way with it. Erlang uses parse transforms for that. They are more powerful but much more complex to use.
    - alco 13y ago
      I agree with all of the above. I would just like to add that in Elixir meta-programming does not always have to deal with macros. For example, this program somelist = ... # any kind of data, # could be loaded from file defmodule M do for {name, value} <- somelist do def lookup(unquote(name)), do: unquote(value) end end generates a set of functions from arbitrary input. This feature alone greatly improves productivity in certain use cases. While it is true that Erlang's parse transforms are more powerful by default, nothing would stop a willing heart from implementing token-level macros for Elixir. It would be a separate program that would parse source code before passing it on to the Elixir compiler. But given the straightforwardness of code generation in Elixir (as exemplified by the code above), coming up with such a program might prove to be even easier for the user than dealing with parse transforms in Erlang. This is a speculation on my part, so it'd be curious to see if anyone goes in this direction in the future.
    - vertex-four 13y ago
      One language that does support syntax extensions from macros is the Metalua extensions to Lua. There's a bunch of special syntax allowing you to hook into the parser and modify it while it parses a file.

leccine 13y ago

What is the advantage over Erlang? I guess this gives the syntactic sugar on the top of Erlang but I am not sure if this takes away the good parts of the language (pattern matching etc.) as well. Anyways, Erlang has a steep learning curve but if you invest the time it is pretty rewarding.

rdtsc 13y ago
It is different. It doesn't have a 100% advantage. In some case it just sort of inverted the choice Erlang made -- lower case variables, vs upper case. Lower case module names vs upper case etc. It has immutable data but not immutable bindings. Erlang has both as immutable. What that means is, you can do x = value1 then x = value2. In Erlang, like in mathematical notation, once you said X=value1 it is value1, it doesn't make sense to say X=value2 (it throws an exception). In either case you can't modify value1 in place for example by saying x[3]=4 or X[3]=4 ( <- I am making up syntax to illustrate here). Some like it one way some like it another. Elixir has better meta-programming, which is nice. In general, Erlang syntax is not the steepest learning curve. The steepest learning curve is to learn to use actors for concurrency and use functional programming for sequential parts. Elixir presents a more familiar syntax but the other learning curve parts are still there.
- peregrine 13y ago
  I agree with this. Its not a panacea but in general it's way more developer friendly. Especially when a good chunk of developers come to expect to have basics like strings and library/syntax to support them natively. Erlang isn't horrible, and when you learn Elixir you WILL come to learn Erlang and its documentation.
- leccine 13y ago
  Well you are making variables mutable. This is bad. One of the great features of Erlang and generally any functional programming language is immutability that makes defensive programming unnecessary. I would like to keep that... The rest of the stuff is great but it does not give enough value to me to not to use Erlang. Actors is a basic concept and message passing is definitely the way to go if you are building a distributed system. One of the biggest problems with Ruby and the imperative languages in general that it was designed for local execution so communication and distributing computation is more difficult than for example in Erlang.