6 ms·

A Week with Elixir

204 points by gluegadget 13y ago

buster 13y ago
As someone who ever wanted to learn erlang but didn't like the syntax, i'm hoping elixir will do it easy for "non-functional" programmes to enter the world of erlang.
- Ixiaus 13y ago
  Erlang's syntax has little to do with its functional paradigm - you should just bite the bullet and learn functional programming if syntax is what you're worried about. 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).
  - buster 13y ago
    I know, i know. But i have to admit that elixir looks "nicer" to me. Whatever that means...
    - Ixiaus 13y ago
      Well yes. Beauty is often in the eye of the beholder :) If you learn Erlang and understand it I think you would actually grow an appreciation for the why and how of its syntax. It's definitely an acquired taste. I'm also one of those people that think homoiconicity and sexps are beautiful...
toisanji 13y ago
Lets hope that more of these changes make it upstream or that they modify the vm to make it easier for other languages to work on the erlang vm. Erlang has lots of potential but lots of people get scared away from the syntax and other oddities.
davidw 13y ago
It was very enlightening to see one guy who created a language go over someone else's language. The point about versioning source code files is interesting: you can tell Joe would like to be able to make some changes to Erlang itself without worrying about all those lines of code out there in mission critical deployments. Great read, in any case, for anyone interesting in language design.
- lucian1900 13y ago
  I like the way it's done in Clojure, where Leiningen projects declare Clojure itself as a dependency, with an explicit version.
  - nuxlli 13y ago
    Also not sure I like the idea of having it for the. Besides the extra work of maintaining it may imply, I believe that leaving it in the hands of the isolation system dependencies over worked.
  - munificent 13y ago
    The package manager I work on for Dart supports something similar: a package can which version(s) of the Dart SDK itself that it works with.
- lobster_johnson 13y ago
  But it's odd that he brings up XML specifically, and lays so much praise on its designers, given that XML versioning has not mattered much since its inception. Most people still happily use 1.0, where the version declaration is optional.
nuxlli 13y ago
Very good, it's great to see Elixir is aligned with what Joe's vision of good practice and how things should evolve. This can be the start of something that will help both sides, we will follow what will happen.
arianvanp 13y ago
Makes me cringe to hear someone say `|>` is the `pipe operator`. 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.
- _pmf_ 13y ago
  > If you're thinking operators your probably doing it wrong in functional programming. Stating that the creator of Erlang is doing FP wrong is a bold statement.
- jacquesm 13y ago
  > Makes me cringe to hear someone say 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 http://en.wikipedia.org/wiki/Joe_Armstrong_%28programming%29
  - arianvanp 13y ago
    I'm not going to change the way I speak based on who I am speaking to. fine, accuse me of speaking wrongly by telling me why and i'll accept it. I made a bit of a bold statement, an I appreciate people correcting me appropiatly by giving me valid reasons why my statement is wrong. But basing your argument on an appeal to authority is just a logical falacy and is annoying.
    - jacquesm 13y ago
      When in a hole, stop digging.
    - rdtsc 13y ago
      > But basing your argument on an appeal to authority is just a logical falacy(sic) and is annoying. 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!".
waffle_ss 13y ago
A precursor to Elixir, Reia, got me interested in Erlang. After having written Erlang for a little while now, I'm not sure of the benefits of a language like Elixir or Reia anymore (which seem mostly focused on improving syntax). Sure, Erlang syntax is odd starting out, but you get over that very quickly. 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.
- zimbatm 13y ago
  It depends if that newer syntax allows you to handle more things at the same time. Without explicitly measuring and mentioning it that's what these super-set languages are trying to do I think. 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.
- devinus 13y ago
  As a professional Erlang developer who now develops with Elixir, I need to stop this right here. This is NOT just about syntax. Elixir simply is not just a pretty face for Erlang, but enables metaprogramming that is simply NOT possible in Erlang without writing 10x more code. Elixir comes with it's own standard library, HashDict, Reducers, and more and more. I'll have to write another blog post, because this misconception that Elixir is just a prettier syntax is somehow still around.
  - klibertp 13y ago
    So exactly like Coffee - it enables you to do class-based inheritance and mixins which is NOT possible in JavaScript... without writing 10x more code. 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.
rubyrescue 13y ago
Joe's points are really good. This drives me crazy in Elixir: 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
- devinus 13y ago
  https://groups.google.com/forum/?fromgroups#!topic/elixir-lang-core/Zop_x5K85XE https://groups.google.com/forum/?fromgroups#!topic/elixir-la... 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.
  - jeremyjh 13y ago
    Its true, but Joe is also correct that this is going to be something people complain about for decades.
  - lobster_johnson 13y ago
    Personally I would rather leave the syntax disambiguation to the programmer when relevant, rather than enforcing a single, awkward-looking syntax for all cases.
  - jallmann 13y ago
    That kind of variable shadowing is a smell. The compiler should warn about it, and/or re-bind the local method as expected (possibly shooting programmer in the foot, but hey... that's why it's a smell, Don't Do It). Forcing an inconsistent syntax to handle one corner case seems like another smell in itself.
D9u 13y ago
Every time I see "Elixir" used in reference to software I'm reminded of Xerox' Elixir circa 1993, when I was forced to learn how to use the proprietary interface - this was before Windows support had been integrated. http://www.outputlinks.com/html/people/Entrepreneurial_Spirit_Basit_Hamid_WYSIWYG_Visionary_and_Elixir_Technologies_Founder_112205111000-639290214.aspx http://www.outputlinks.com/html/people/Entrepreneurial_Spiri... http://www.xerox.com/digital-printing/workflow/printing-software/elixir-design-pro/enza.html http://www.xerox.com/digital-printing/workflow/printing-soft... We used Xerox Elixir to typeset forms pre-press for a Xerox DocuTech.
atombender 13y ago
I was quite surprised by how amicable and positive this blog post was; I expected him to have lots of objections. It's admirable that an old hand like Joe Armstrong can be so open and accepting of something that essentially sets out to improve on his lifework. 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.itesm.mx%3A8005%2Ferlang%2Fcd%2Fdownloads%2Fhopl_erlang.pdf https://docs.google.com/viewer?url=http%3A%2F%2Fwebcem01.cem...
- hosh 13y ago
  I started working with Erlang for work, on and off, for the past year. I had been working with Ruby for a lot longer. I too, liked the Erlang design, but the syntax is a wreck. It's also true, use something long enough and you get used to it. I've noticed long-time Erlang users tend to have this mystical ability to see the underlying elegance expressed by the Erlang syntax while ignoring the syntactic awkwardness. 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.
abraininavat 13y ago
Gut feeling precedes logic. I know when things are right, I don’t know how or why I know, but the explanation of why things are right often comes weeks or years later. Malcolm Gladwell in his book Blink: The Power of Thinking Without Thinking talks about this. Experts in a particular field can often instantly know that something is right, but they can’t explain why. 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/Confirmation_bias http://en.wikipedia.org/wiki/Cherry_picking_(fallacy) http://en.wikipedia.org/wiki/Cherry_picking_(fallacy)
- saraid216 13y ago
  Really? I hear about confirmation bias and cherry-picking far more often than I do about expert intuition. I don't even know what the common name is for the latter phenomenon.
  - abraininavat 13y ago
    I think you missed the point. I wasn't offering confirmation bias+cherry-picking as an interesting phenomenon alongside "expert intuition." I was suggesting that the latter is nothing more than a manifestation of the former.
    - deleted 13y ago
      [deleted]
nivertech 13y ago
I generally like Elixir approach, but find that in many cases it's more verbose than standard Erlang syntax. 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
- lamp 13y ago
  You can explicitly override multiple assignment in elixir by using a carat: a = 1 ^a = 1 - ok ^a = 2 - bad match
  - nivertech 13y ago
    I know, what I said is that multiple assignment should be explicit, when single assignment should be default. I.e. the reverse of what is in Elixr.
topfunky 13y ago
This is great timing. We just recorded a two hour Intro to Elixir with its creator Jose Valim. We'll be publishing it in June at https://peepcode.com https://peepcode.com I 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).
jongraehl 13y ago
I love visually distinct/suggestive operators so long as they're easy to type on a standard layout. So for that reason alone I agree that a ! b is better than a <- b 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).
ibotty 13y ago
see also the discussion on lambda the ultimate http://lambda-the-ultimate.org/node/4754 http://lambda-the-ultimate.org/node/4754

204 points by gluegadget 13y ago

As someone who ever wanted to learn erlang but didn't like the syntax, i'm hoping elixir will do it easy for "non-functional" programmes to enter the world of erlang.

Ixiaus 13y ago
Erlang's syntax has little to do with its functional paradigm - you should just bite the bullet and learn functional programming if syntax is what you're worried about. 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).
- buster 13y ago
  I know, i know. But i have to admit that elixir looks "nicer" to me. Whatever that means...
  - Ixiaus 13y ago
    Well yes. Beauty is often in the eye of the beholder :) If you learn Erlang and understand it I think you would actually grow an appreciation for the why and how of its syntax. It's definitely an acquired taste. I'm also one of those people that think homoiconicity and sexps are beautiful...

toisanji 13y ago

Lets hope that more of these changes make it upstream or that they modify the vm to make it easier for other languages to work on the erlang vm. Erlang has lots of potential but lots of people get scared away from the syntax and other oddities.

davidw 13y ago

It was very enlightening to see one guy who created a language go over someone else's language. The point about versioning source code files is interesting: you can tell Joe would like to be able to make some changes to Erlang itself without worrying about all those lines of code out there in mission critical deployments. Great read, in any case, for anyone interesting in language design.

lucian1900 13y ago
I like the way it's done in Clojure, where Leiningen projects declare Clojure itself as a dependency, with an explicit version.
- nuxlli 13y ago
  Also not sure I like the idea of having it for the. Besides the extra work of maintaining it may imply, I believe that leaving it in the hands of the isolation system dependencies over worked.
- munificent 13y ago
  The package manager I work on for Dart supports something similar: a package can which version(s) of the Dart SDK itself that it works with.
lobster_johnson 13y ago
But it's odd that he brings up XML specifically, and lays so much praise on its designers, given that XML versioning has not mattered much since its inception. Most people still happily use 1.0, where the version declaration is optional.

nuxlli 13y ago

Very good, it's great to see Elixir is aligned with what Joe's vision of good practice and how things should evolve. This can be the start of something that will help both sides, we will follow what will happen.

arianvanp 13y ago

Makes me cringe to hear someone say `|>` is the `pipe operator`. 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.

_pmf_ 13y ago
> If you're thinking operators your probably doing it wrong in functional programming. Stating that the creator of Erlang is doing FP wrong is a bold statement.
jacquesm 13y ago
> Makes me cringe to hear someone say 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 http://en.wikipedia.org/wiki/Joe_Armstrong_%28programming%29
- arianvanp 13y ago
  I'm not going to change the way I speak based on who I am speaking to. fine, accuse me of speaking wrongly by telling me why and i'll accept it. I made a bit of a bold statement, an I appreciate people correcting me appropiatly by giving me valid reasons why my statement is wrong. But basing your argument on an appeal to authority is just a logical falacy and is annoying.
  - jacquesm 13y ago
    When in a hole, stop digging.
  - rdtsc 13y ago
    > But basing your argument on an appeal to authority is just a logical falacy(sic) and is annoying. 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!".

waffle_ss 13y ago

A precursor to Elixir, Reia, got me interested in Erlang. After having written Erlang for a little while now, I'm not sure of the benefits of a language like Elixir or Reia anymore (which seem mostly focused on improving syntax). Sure, Erlang syntax is odd starting out, but you get over that very quickly. 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.

zimbatm 13y ago
It depends if that newer syntax allows you to handle more things at the same time. Without explicitly measuring and mentioning it that's what these super-set languages are trying to do I think. 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.
devinus 13y ago
As a professional Erlang developer who now develops with Elixir, I need to stop this right here. This is NOT just about syntax. Elixir simply is not just a pretty face for Erlang, but enables metaprogramming that is simply NOT possible in Erlang without writing 10x more code. Elixir comes with it's own standard library, HashDict, Reducers, and more and more. I'll have to write another blog post, because this misconception that Elixir is just a prettier syntax is somehow still around.
- klibertp 13y ago
  So exactly like Coffee - it enables you to do class-based inheritance and mixins which is NOT possible in JavaScript... without writing 10x more code. 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.

rubyrescue 13y ago

Joe's points are really good. This drives me crazy in Elixir: 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

devinus 13y ago
https://groups.google.com/forum/?fromgroups#!topic/elixir-lang-core/Zop_x5K85XE https://groups.google.com/forum/?fromgroups#!topic/elixir-la... 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.
- jeremyjh 13y ago
  Its true, but Joe is also correct that this is going to be something people complain about for decades.
- lobster_johnson 13y ago
  Personally I would rather leave the syntax disambiguation to the programmer when relevant, rather than enforcing a single, awkward-looking syntax for all cases.
- jallmann 13y ago
  That kind of variable shadowing is a smell. The compiler should warn about it, and/or re-bind the local method as expected (possibly shooting programmer in the foot, but hey... that's why it's a smell, Don't Do It). Forcing an inconsistent syntax to handle one corner case seems like another smell in itself.

D9u 13y ago

Every time I see "Elixir" used in reference to software I'm reminded of Xerox' Elixir circa 1993, when I was forced to learn how to use the proprietary interface - this was before Windows support had been integrated. http://www.outputlinks.com/html/people/Entrepreneurial_Spirit_Basit_Hamid_WYSIWYG_Visionary_and_Elixir_Technologies_Founder_112205111000-639290214.aspx http://www.outputlinks.com/html/people/Entrepreneurial_Spiri... http://www.xerox.com/digital-printing/workflow/printing-software/elixir-design-pro/enza.html http://www.xerox.com/digital-printing/workflow/printing-soft... We used Xerox Elixir to typeset forms pre-press for a Xerox DocuTech.

atombender 13y ago

I was quite surprised by how amicable and positive this blog post was; I expected him to have lots of objections. It's admirable that an old hand like Joe Armstrong can be so open and accepting of something that essentially sets out to improve on his lifework. 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.itesm.mx%3A8005%2Ferlang%2Fcd%2Fdownloads%2Fhopl_erlang.pdf https://docs.google.com/viewer?url=http%3A%2F%2Fwebcem01.cem...

hosh 13y ago
I started working with Erlang for work, on and off, for the past year. I had been working with Ruby for a lot longer. I too, liked the Erlang design, but the syntax is a wreck. It's also true, use something long enough and you get used to it. I've noticed long-time Erlang users tend to have this mystical ability to see the underlying elegance expressed by the Erlang syntax while ignoring the syntactic awkwardness. 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.

abraininavat 13y ago

Gut feeling precedes logic. I know when things are right, I don’t know how or why I know, but the explanation of why things are right often comes weeks or years later. Malcolm Gladwell in his book Blink: The Power of Thinking Without Thinking talks about this. Experts in a particular field can often instantly know that something is right, but they can’t explain why. 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/Confirmation_bias http://en.wikipedia.org/wiki/Cherry_picking_(fallacy) http://en.wikipedia.org/wiki/Cherry_picking_(fallacy)

saraid216 13y ago
Really? I hear about confirmation bias and cherry-picking far more often than I do about expert intuition. I don't even know what the common name is for the latter phenomenon.
- abraininavat 13y ago
  I think you missed the point. I wasn't offering confirmation bias+cherry-picking as an interesting phenomenon alongside "expert intuition." I was suggesting that the latter is nothing more than a manifestation of the former.
  - deleted 13y ago
    [deleted]

nivertech 13y ago

I generally like Elixir approach, but find that in many cases it's more verbose than standard Erlang syntax. 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

lamp 13y ago
You can explicitly override multiple assignment in elixir by using a carat: a = 1 ^a = 1 - ok ^a = 2 - bad match
- nivertech 13y ago
  I know, what I said is that multiple assignment should be explicit, when single assignment should be default. I.e. the reverse of what is in Elixr.

topfunky 13y ago

This is great timing. We just recorded a two hour Intro to Elixir with its creator Jose Valim. We'll be publishing it in June at https://peepcode.com https://peepcode.com I 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).

jongraehl 13y ago

I love visually distinct/suggestive operators so long as they're easy to type on a standard layout. So for that reason alone I agree that a ! b is better than a <- b 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).

ibotty 13y ago

see also the discussion on lambda the ultimate http://lambda-the-ultimate.org/node/4754 http://lambda-the-ultimate.org/node/4754