4 ms·

1) The language introduction is found under the Getting Started link: http://elixir-lang.org/getting_started/1.html http://elixir-lang.org/getting_started/1.htm

1) The language introduction is found under the Getting Started link: http://elixir-lang.org/getting_started/1.html http://elixir-lang.org/getting_started/1.html 2) Dialyzer works fine on Elixir beam files. You can specify type & spec attributes just like in Erlang. If macros worry you unduly, then Elixir is not for you. I personally prefer to use macros than type lots of boilerplate code, but yes there are some downsides. edit: Actually I should have said reading and typing - reading boilerplate is much worse than writing it. Judicious use of macros can clarify intent for someone reading the code.

colanderman 14y ago
1) A language introduction is not documentation, and is certainly not specification. It's difficult to discuss a new language when you have to guess how it works based on a handful of examples. 2) Dialyzer is a complete, not sound program analyzer. i.e. it will never produce a false positive, but it may allow incorrect programs through. By making definitions first-class, Elixir's module language becomes Turing-complete, moving a whole new class of bugs into Dialyzer's "false negative" category. This problem doesn't exist with second-class definition systems such as OCaml's, because the definition language is not Turing-complete: all definitions and modules may be checked at compile time. 3) I'm not sure where macros come into play? Are you using "macros" to mean "higher-order programming tools"? If so, you're misunderstanding me -- I use metaprogramming tools all the time; I simply prefer ones which aren't Turing-complete and are therefore amenable to analysis.
- davidw 14y ago
  > It's difficult to discuss a new language when you have to guess how it works based on a handful of examples. It sounds like you are more interested in "CS friendly" languages, rather than "get stuff done" languages. Erlang and Elixir tend toward the latter category. I'm generalizing a lot, and that's not to say a language can't be both, but Erlang was born of a practical need, and I think that Elixir is similar: it's not meant to be the most beautiful language out there, it's meant to be a bit more user-friendly way of utilizing the power of Erlang and OTP. In terms of a specification, have a look at Elixir's test suite. Given that it's still being hacked on, it's probably not set in stone.
  - colanderman 14y ago
    It sounds like you are more interested in "CS friendly" languages, rather than "get stuff done" languages. It sounds like you think there's no overlap (despite your next paragraph). Additionally: "CS friendliness" is more pragmatic than you think. Automatic refactoring and automatic code analysis are two huge pragmatic wins (think: saving developer time) that are made possible only by paying heed to analyzability of code. Erlang and Elixir tend toward the latter category. Erlang is my current favorite language. You may not realize it, but it is one of the most "CS friendly" mainstream languages that exist. The fact that it is almost entirely defined by "functional programming" + "actor model" is a big part of this. The existence of Dialyzer is a testament to its amenability to automatic analysis. In terms of a specification, have a look at Elixir's test suite. A test suite isn't a specification (though it's a lot closer than a tutorial): all computer languages contain infinities (e.g. expressions can be arbitrarily large); test suites cannot express infinities. And a test suite certainly isn't a reference document. A good language reference document says "here are all the forms of the language, here is what they all mean". The Erlang Reference Manual is a very good example of such a document. (I'm not trying to be a bear; "There is no language documentation" is a perfectly acceptable answer for me; it just means there is no way for me to discuss the specific benefits Elixir may have.)
    - davidw 14y ago
      > The Erlang Reference Manual is a very good example of such a document. Erlang has had quite a bit longer to produce such a document, though, hasn't it? Why bother doing that when you're still fiddling with the language? In terms of CS friendliness, I get the impression that Haskell is far more popular with that crowd in that it has more things of interest to people doing language hacking. Erlang has "functional" and "actors", but not a lot of other stuff that seems to be of interest to the CS crowd, like types. > "There is no language documentation" is a perfectly acceptable answer for me; it just means there is no way for me to discuss the specific benefits Elixir may have No way at all? I think you can tell a lot about a language without some kind of formal documentation.
      - 14y ago
Luc 14y ago
> If macros worry you unduly, then Elixir is not for you. Really? It seems interesting, but I'd simply choose not to use macros in my own code. Seems like they can be avoided in most situations. There's even a heading in the introduction that says 'Don't write macros': http://elixir-lang.org/getting_started/5.html http://elixir-lang.org/getting_started/5.html
- jeremyjh 14y ago
  Macros are more for writing libraries than applications, so certainly what you are saying is correct. However, some people don't like that capability to exist at all - they are afraid it will be abused in code they support or rely on.

colanderman 14y ago

1) A language introduction is not documentation, and is certainly not specification. It's difficult to discuss a new language when you have to guess how it works based on a handful of examples. 2) Dialyzer is a complete, not sound program analyzer. i.e. it will never produce a false positive, but it may allow incorrect programs through. By making definitions first-class, Elixir's module language becomes Turing-complete, moving a whole new class of bugs into Dialyzer's "false negative" category. This problem doesn't exist with second-class definition systems such as OCaml's, because the definition language is not Turing-complete: all definitions and modules may be checked at compile time. 3) I'm not sure where macros come into play? Are you using "macros" to mean "higher-order programming tools"? If so, you're misunderstanding me -- I use metaprogramming tools all the time; I simply prefer ones which aren't Turing-complete and are therefore amenable to analysis.

davidw 14y ago
> It's difficult to discuss a new language when you have to guess how it works based on a handful of examples. It sounds like you are more interested in "CS friendly" languages, rather than "get stuff done" languages. Erlang and Elixir tend toward the latter category. I'm generalizing a lot, and that's not to say a language can't be both, but Erlang was born of a practical need, and I think that Elixir is similar: it's not meant to be the most beautiful language out there, it's meant to be a bit more user-friendly way of utilizing the power of Erlang and OTP. In terms of a specification, have a look at Elixir's test suite. Given that it's still being hacked on, it's probably not set in stone.
- colanderman 14y ago
  It sounds like you are more interested in "CS friendly" languages, rather than "get stuff done" languages. It sounds like you think there's no overlap (despite your next paragraph). Additionally: "CS friendliness" is more pragmatic than you think. Automatic refactoring and automatic code analysis are two huge pragmatic wins (think: saving developer time) that are made possible only by paying heed to analyzability of code. Erlang and Elixir tend toward the latter category. Erlang is my current favorite language. You may not realize it, but it is one of the most "CS friendly" mainstream languages that exist. The fact that it is almost entirely defined by "functional programming" + "actor model" is a big part of this. The existence of Dialyzer is a testament to its amenability to automatic analysis. In terms of a specification, have a look at Elixir's test suite. A test suite isn't a specification (though it's a lot closer than a tutorial): all computer languages contain infinities (e.g. expressions can be arbitrarily large); test suites cannot express infinities. And a test suite certainly isn't a reference document. A good language reference document says "here are all the forms of the language, here is what they all mean". The Erlang Reference Manual is a very good example of such a document. (I'm not trying to be a bear; "There is no language documentation" is a perfectly acceptable answer for me; it just means there is no way for me to discuss the specific benefits Elixir may have.)
  - davidw 14y ago
    > The Erlang Reference Manual is a very good example of such a document. Erlang has had quite a bit longer to produce such a document, though, hasn't it? Why bother doing that when you're still fiddling with the language? In terms of CS friendliness, I get the impression that Haskell is far more popular with that crowd in that it has more things of interest to people doing language hacking. Erlang has "functional" and "actors", but not a lot of other stuff that seems to be of interest to the CS crowd, like types. > "There is no language documentation" is a perfectly acceptable answer for me; it just means there is no way for me to discuss the specific benefits Elixir may have No way at all? I think you can tell a lot about a language without some kind of formal documentation.
    - 14y ago

Luc 14y ago

> If macros worry you unduly, then Elixir is not for you. Really? It seems interesting, but I'd simply choose not to use macros in my own code. Seems like they can be avoided in most situations. There's even a heading in the introduction that says 'Don't write macros': http://elixir-lang.org/getting_started/5.html http://elixir-lang.org/getting_started/5.html

jeremyjh 14y ago
Macros are more for writing libraries than applications, so certainly what you are saying is correct. However, some people don't like that capability to exist at all - they are afraid it will be abused in code they support or rely on.