4 ms·

I agree that your second code example is difficult to read, but I think that is more a result of a lot of logic being inlined into one call, than it is a proper

I agree that your second code example is difficult to read, but I think that is more a result of a lot of logic being inlined into one call, than it is a property of the language. % and | are going to be unclear if you're an outsider looking in on the language, but that is true for any sort of specialization. I'd be interested to know what languages you find to be readable, because I can all but guarantee that there's aspects of that language that I'd find arcane -- not because they are, but because I don't know the language. I'm not terribly interested in discussing whether a language is readable or not, because a lot of that is going to come down to subjective opinion, but at the end of the day, I find that Elixir lets me quickly write maintainable code. I'm not entirely sure what you mean by "overloading of atoms to work like pseudo-objects", do you mind elaborating?

aetherson 10y ago
Probably too late to reply, but I mean things like :ets.method or :queue.whatever.
- karmajunkie 10y ago
  What you might be missing is that modules names are just atoms, and thats how you get to erlang libraries/applications in elixir. In "MyApp.whatever" MyApp is also an atom. It's not any kind of overloading or object fakeout at all. The use of __MODULE__ just refers to the current module, and its use is quite common. It's perfectly idiomatic and straightforward to read if you've written enough erlang or elixir to recognize the syntactic elements without the translation hiccup. At this point I find Elixir code a great deal easier to read than a lot of ruby, php, or C++ code I've had to work with in the past. While it may not really be your cup of tea, you can't fairly accuse it of something that has more to go with the reader than the writer.
  - aetherson 10y ago
    I'm not missing it, I just don't like it. It makes the language difficult to understand when any given time you run into an atom, maybe it's being used like a ruby symbol (such as the way the initial :ok gets used in the examples I pasted), but maybe it's being used as a module. My problems with __MODULE__ are, first, it's just super clumsy to have heavily used language constructs with lots of underscores around them, and I don't really understand why anyone ties themselves to that particular semantic. I hate it in Python, too. Almost any other way of distinguishing it from other language elements would be less jarring to read. But second, %__MODULE__{ buffer | size: buffer.size + 1, queue: :queue.push(buffer.queue, whatever) } does some kind of magic that I'd have to look up the details of, but basically copies buffer but overrides some of its elements, right? That's why you don't have to set max_size explicitly? It's a hack that lets you have actually immutable objects but deal with a logically mutable buffer. It's a weird combination of verbose (to copy buffer, I have to write %__MODULE{ buffer, where in another language it might be like buffer.copy()), and compact to the point of overly dense information (I'm putting a lot of expressions on one line), and it's implicit, too -- what parts of buffer are being copied over unchanged? Sorry, better go and look somewhere else. I think this is legitimately hard to get right -- the immutability constraint means that a lot of the standard idioms of programming are a poor fit -- but ultimately this is Elixir's job.
    - sasa555 10y ago
      The atom always means the same thing - a symbolic (named) constant. The dot operator can be used on an atom type to invoke a function from the corresponding module. A capital Foo.Bar is called an alias in Elixir, and it's the same as an atom :"Elixir.Foo.Bar". The usage of __MODULE__ is optional. You can also write %Buffer.Ets{...} if you prefer. There's no hidden magic with %__MODULE__{buffer | ...}. It's an "update" syntax which allows you to take an existing "struct" (essentially a bunch of well-known named fields), and create a transformed version of it with some fields changed. The code %__MODULE__{buffer | size: buffer.size + 1} is therefore the same as %Buffer.Ets{buffer | size: buffer.size + 1}, and it evaluates to a transformed buffer with the size field set to the size of the original buffer incremented by 1. The original buffer is left intact (since you can't do in-place data mutation in Elixir). However, the transformed version is not a full deep copy of the original. It's going to share as much data as possible with the original version. Hope that helps :-)
    - ericmj 10y ago
      There seems to be confusion here about the language semantics. There is no mutability in the expressions you have shown. buffer.copy() would not make sense since the language is immutable, why would you want an explicit copy mechanism when every update is essentially being performed on a copy.

aetherson 10y ago

Probably too late to reply, but I mean things like :ets.method or :queue.whatever.

karmajunkie 10y ago
What you might be missing is that modules names are just atoms, and thats how you get to erlang libraries/applications in elixir. In "MyApp.whatever" MyApp is also an atom. It's not any kind of overloading or object fakeout at all. The use of __MODULE__ just refers to the current module, and its use is quite common. It's perfectly idiomatic and straightforward to read if you've written enough erlang or elixir to recognize the syntactic elements without the translation hiccup. At this point I find Elixir code a great deal easier to read than a lot of ruby, php, or C++ code I've had to work with in the past. While it may not really be your cup of tea, you can't fairly accuse it of something that has more to go with the reader than the writer.
- aetherson 10y ago
  I'm not missing it, I just don't like it. It makes the language difficult to understand when any given time you run into an atom, maybe it's being used like a ruby symbol (such as the way the initial :ok gets used in the examples I pasted), but maybe it's being used as a module. My problems with __MODULE__ are, first, it's just super clumsy to have heavily used language constructs with lots of underscores around them, and I don't really understand why anyone ties themselves to that particular semantic. I hate it in Python, too. Almost any other way of distinguishing it from other language elements would be less jarring to read. But second, %__MODULE__{ buffer | size: buffer.size + 1, queue: :queue.push(buffer.queue, whatever) } does some kind of magic that I'd have to look up the details of, but basically copies buffer but overrides some of its elements, right? That's why you don't have to set max_size explicitly? It's a hack that lets you have actually immutable objects but deal with a logically mutable buffer. It's a weird combination of verbose (to copy buffer, I have to write %__MODULE{ buffer, where in another language it might be like buffer.copy()), and compact to the point of overly dense information (I'm putting a lot of expressions on one line), and it's implicit, too -- what parts of buffer are being copied over unchanged? Sorry, better go and look somewhere else. I think this is legitimately hard to get right -- the immutability constraint means that a lot of the standard idioms of programming are a poor fit -- but ultimately this is Elixir's job.
  - sasa555 10y ago
    The atom always means the same thing - a symbolic (named) constant. The dot operator can be used on an atom type to invoke a function from the corresponding module. A capital Foo.Bar is called an alias in Elixir, and it's the same as an atom :"Elixir.Foo.Bar". The usage of __MODULE__ is optional. You can also write %Buffer.Ets{...} if you prefer. There's no hidden magic with %__MODULE__{buffer | ...}. It's an "update" syntax which allows you to take an existing "struct" (essentially a bunch of well-known named fields), and create a transformed version of it with some fields changed. The code %__MODULE__{buffer | size: buffer.size + 1} is therefore the same as %Buffer.Ets{buffer | size: buffer.size + 1}, and it evaluates to a transformed buffer with the size field set to the size of the original buffer incremented by 1. The original buffer is left intact (since you can't do in-place data mutation in Elixir). However, the transformed version is not a full deep copy of the original. It's going to share as much data as possible with the original version. Hope that helps :-)
  - ericmj 10y ago
    There seems to be confusion here about the language semantics. There is no mutability in the expressions you have shown. buffer.copy() would not make sense since the language is immutable, why would you want an explicit copy mechanism when every update is essentially being performed on a copy.