5 ms·

The pmod arguments have been a pretty ongoing war[1] on the mailing list, especially since it was announced R16 would be removing official support for them. Wi

by chops 14y ago

The pmod arguments have been a pretty ongoing war[1] on the mailing list, especially since it was announced R16 would be removing official support for them. With ChicagoBoss being one of the highest profile projects to use pmods extensively, Evan Miller has been arguing for them pretty extensively. At least support wasn't completely dropped, since they are providing the parse_transform to re-enable the functionality: https://github.com/erlang/pmod_transform https://github.com/erlang/pmod_transform [1] A friendly war, anyway: http://erlang.org/pipermail/erlang-questions/2013-January/071860.html http://erlang.org/pipermail/erlang-questions/2013-January/07...

codewright 14y ago
The fact that people like Evan Miller aren't taken seriously and heeded is why I only tinker with Erlang and haven't bothered to use it for anything. Once they start taking the little people (so to speak) seriously, I'll revisit the Erlang runtime for an actual project. Until then: Clojure. Clojure has a strong tinkerer culture.
- dieswaytoofast 14y ago
  I think that Evan might object to being considered 'little' :-)
  - codewright 14y ago
    He's the one that named his framework "Chicago Boss" (after Tokyo Tyrant), not me. :P
- rlander 14y ago
  I wish I could upvote this 5x. I love Erlang the language but, paraphrasing tarcieri (& zedshaw), the community around it can sometimes be a ghetto.
  - davidw 14y ago
    I think the problem is that Erlang does some things extremely well, which leads to people getting a bit smug about it, in a way that sometimes reminds me of "photography purists" sniffing at digital photography as being so very clearly sub-par, a few years ago. My reality is that for a lot of the web stuff I do, the faster development time that Rails gives me is worth way more than a bit of speed / better use of resources. I don't need a redundant site with 0 downtime, I need to figure out if there's a market for what I'm working on, and/or pivot and add features as I begin to understand things better. +1 for Chicago Boss, though, it's a solid effort that tries to push Erlang in some interesting directions. I do think I'll be using it for a project soonish, as the specs involve a lot of piping data around, and websockets, stuff that Rails is not as good at.
    - codewright 14y ago
      >as the specs involve a lot of piping data around, and websockets, stuff that Rails is not as good at. I use Python in my day job and when I have need for something like that, I usually resort to Clojure. It's a pretty great experience. Also look into Elixir if you're hellbent on using Erlang.
      - davidw 14y ago
        I'm pretty comfortable with Erlang, actually, having used it on and off for the past 9 years. Elixir looks cool, but a bit too experimental for what I'm working on. Chicago Boss makes me a bit nervous from that point of view too, for that matter... so we'll see what route we end up taking. Evan Miller, for the record, is really great about responding to bug reports and code ideas, so that is a big plus about the project.
  - Ixiaus 14y ago
    The community is anything but a ghetto. Everyone I've interacted with is both highly intelligent, helpful, and very opinionated about the future of the language. One of Erlang's strengths is its stability; they get their stability from being really picky about some things.
  - 14y ago
- mononcqc 14y ago
  There's been countless arguments against PMods, mostly about their implementation, not the concept itself. Here's a list of a few I have compiled on the mailing list in the past: http://erlang.org/pipermail/erlang-questions/2012-August/068575.html http://erlang.org/pipermail/erlang-questions/2012-August/068... Evan has a point regarding the verbosity of many expressions and there have been very complete enhancement proposals that are much better in what they cover and their properties. See for example Richard O'Keefe's 'Frames' proposal: http://www.cs.otago.ac.nz/staffpriv/ok/frames.pdf http://www.cs.otago.ac.nz/staffpriv/ok/frames.pdf This doesn't mean his points and concerns are not valid, and it also doesn't mean that parametrized modules should stay. I think the compromise made (still support them, but not in the main OTP distribution) is a decent one, because it takes little effort to keep old code compatible, stuff still works, but the issues mentioned in my post linked above are no longer a concern of whoever is using or implementing libraries with features that were built on a weird implementations like tuple calls. It also allowed a much simpler error handler with new very interesting mechanisms when similar features were cleaned up.
- jlouis 14y ago
  I think you have it wrong, in my humble opinion. Erlang is not a tinkerers language. If you want to tinker you want Scheme, Clojure or Haskell, which to a far greater extent plays around with new ways of doing things in programming languages. Erlang is about providing a stable platform and controlled additions. The decision to remove parameterized modules must be balanced against the fact that you are maintaining an experimental extension and that it complicates the compiler. So the decision was made to remove them completely from the language in order to pave the way for a better solution. One of Joe Armstrongs ideas is that if you add a new feature to the language, you must remove one as well. So the choice is all about balancing the effort required to keep parts of the implementation working. It isn't that Evan Miller as not been heard and taken seriously. Believe me, the decision is not a quick one made just for the sake of making such a choice. In Erlang, pmods are problematic because the language has no type system and they seriously mess with readability of program code. They also make it harder to grep in code, and there are very simple ways to work around the lack of them. And they are not the feature we need to make the language better. There are a large amount of other features which would be far better to have.
  - rlander 14y ago
    I'm well aware of the technical merits of the decision and generally agree with it (I upvoted you because of the clear explanation, btw). What rubs me the wrong way are comments like (emphasis mine): "And they are not the feature WE need to make the language better" and "Looking over Elixir, I tend to agree with Tristan -- it seems to have all the syntactic sugar that creative, non-hardcore, easily frightened developers might like"[0] Which translate to: just go away, please. [0] http://erlang.org/pipermail/erlang-questions/2013-January/071872.html http://erlang.org/pipermail/erlang-questions/2013-January/07...
    - chrisduesing 14y ago
      You seem to have forgotten to quote the next paragraph which says, "In seriousness, it looks like a nice language -- I wonder if it, or the Ruby, Python, JavaScript "front-end" toolsets, might be a better fit for extending Erlang applications to programmers who are looking for a kinder, gentler syntax?" Garret spends a fair amount of energy trying to make Erlang more accessible. http://e2project.org/erlang.html http://e2project.org/erlang.html http://www.erlang-factory.com/conference/SFBay2013/speakers/GarrettSmith http://www.erlang-factory.com/conference/SFBay2013/speakers/...
- Ixiaus 14y ago
  You're approaching this wrong; they do take the little and big people seriously. It's also a 20(?) year old language with a lot of features! You can't possibly add/remove everything everyone wants - I think the team behind Erlang is doing an exceptional job of maintaining stability while getting new features and cleaned up releases out. Also - my own startup uses Erlang extensively (we use Riak, yes, but our actual application is built on top of Erlang too); I would say 80% of our codebase consists of Erlang. It's rock solid and the concurrency and distribution features (and ease of use) are unmatched. Also - OTP, nothing compares to OTP yet (Akka is trying to get there, but they have a long journey ahead of them).
  - jeffdavis 14y ago
    I've been trying to learn a little erlang for a while. One of the things that holds me back is the external libraries. If it's a part of erlang/OTP, then great, usually I'm happy with it. But it's hard to find, install, and update external libraries compared with many other languages (like haskell/cabal, ruby/gems, etc.). How do you deal with that on a practical level?
    - MetaCosm 14y ago
      There isn't a central clearing house at the moment. But the conventions is to use a tool called "rebar" and you simply add a dependency in your rebar.conf like {cowboy, ".*", {git, "git://github.com/extend/cowboy.git", "master"}} and then it will use cowboy's rebar.conf to download what it requires, in this case ranch. So, you can just link to the top level library you care about it most cases and let rebar deal with it.
      - jeffdavis 14y ago
        Oh, I see. Thank you. After asking around on IRC, I found out about CEAN, which looks like it's trying to be a central clearing house. But it's a little strange looking compared to ones that I'm used to... it doesn't look very community-oriented. I couldn't even find a license file for CEAN itself. But it looks like rebar offers a lot already, so I'll look into that more.

by chops 14y ago

codewright 14y ago

The fact that people like Evan Miller aren't taken seriously and heeded is why I only tinker with Erlang and haven't bothered to use it for anything. Once they start taking the little people (so to speak) seriously, I'll revisit the Erlang runtime for an actual project. Until then: Clojure. Clojure has a strong tinkerer culture.

dieswaytoofast 14y ago
I think that Evan might object to being considered 'little' :-)
- codewright 14y ago
  He's the one that named his framework "Chicago Boss" (after Tokyo Tyrant), not me. :P
rlander 14y ago
I wish I could upvote this 5x. I love Erlang the language but, paraphrasing tarcieri (& zedshaw), the community around it can sometimes be a ghetto.
- davidw 14y ago
  I think the problem is that Erlang does some things extremely well, which leads to people getting a bit smug about it, in a way that sometimes reminds me of "photography purists" sniffing at digital photography as being so very clearly sub-par, a few years ago. My reality is that for a lot of the web stuff I do, the faster development time that Rails gives me is worth way more than a bit of speed / better use of resources. I don't need a redundant site with 0 downtime, I need to figure out if there's a market for what I'm working on, and/or pivot and add features as I begin to understand things better. +1 for Chicago Boss, though, it's a solid effort that tries to push Erlang in some interesting directions. I do think I'll be using it for a project soonish, as the specs involve a lot of piping data around, and websockets, stuff that Rails is not as good at.
  - codewright 14y ago
    >as the specs involve a lot of piping data around, and websockets, stuff that Rails is not as good at. I use Python in my day job and when I have need for something like that, I usually resort to Clojure. It's a pretty great experience. Also look into Elixir if you're hellbent on using Erlang.
    - davidw 14y ago
      I'm pretty comfortable with Erlang, actually, having used it on and off for the past 9 years. Elixir looks cool, but a bit too experimental for what I'm working on. Chicago Boss makes me a bit nervous from that point of view too, for that matter... so we'll see what route we end up taking. Evan Miller, for the record, is really great about responding to bug reports and code ideas, so that is a big plus about the project.
- Ixiaus 14y ago
  The community is anything but a ghetto. Everyone I've interacted with is both highly intelligent, helpful, and very opinionated about the future of the language. One of Erlang's strengths is its stability; they get their stability from being really picky about some things.
- 14y ago
mononcqc 14y ago
There's been countless arguments against PMods, mostly about their implementation, not the concept itself. Here's a list of a few I have compiled on the mailing list in the past: http://erlang.org/pipermail/erlang-questions/2012-August/068575.html http://erlang.org/pipermail/erlang-questions/2012-August/068... Evan has a point regarding the verbosity of many expressions and there have been very complete enhancement proposals that are much better in what they cover and their properties. See for example Richard O'Keefe's 'Frames' proposal: http://www.cs.otago.ac.nz/staffpriv/ok/frames.pdf http://www.cs.otago.ac.nz/staffpriv/ok/frames.pdf This doesn't mean his points and concerns are not valid, and it also doesn't mean that parametrized modules should stay. I think the compromise made (still support them, but not in the main OTP distribution) is a decent one, because it takes little effort to keep old code compatible, stuff still works, but the issues mentioned in my post linked above are no longer a concern of whoever is using or implementing libraries with features that were built on a weird implementations like tuple calls. It also allowed a much simpler error handler with new very interesting mechanisms when similar features were cleaned up.
jlouis 14y ago
I think you have it wrong, in my humble opinion. Erlang is not a tinkerers language. If you want to tinker you want Scheme, Clojure or Haskell, which to a far greater extent plays around with new ways of doing things in programming languages. Erlang is about providing a stable platform and controlled additions. The decision to remove parameterized modules must be balanced against the fact that you are maintaining an experimental extension and that it complicates the compiler. So the decision was made to remove them completely from the language in order to pave the way for a better solution. One of Joe Armstrongs ideas is that if you add a new feature to the language, you must remove one as well. So the choice is all about balancing the effort required to keep parts of the implementation working. It isn't that Evan Miller as not been heard and taken seriously. Believe me, the decision is not a quick one made just for the sake of making such a choice. In Erlang, pmods are problematic because the language has no type system and they seriously mess with readability of program code. They also make it harder to grep in code, and there are very simple ways to work around the lack of them. And they are not the feature we need to make the language better. There are a large amount of other features which would be far better to have.
- rlander 14y ago
  I'm well aware of the technical merits of the decision and generally agree with it (I upvoted you because of the clear explanation, btw). What rubs me the wrong way are comments like (emphasis mine): "And they are not the feature WE need to make the language better" and "Looking over Elixir, I tend to agree with Tristan -- it seems to have all the syntactic sugar that creative, non-hardcore, easily frightened developers might like"[0] Which translate to: just go away, please. [0] http://erlang.org/pipermail/erlang-questions/2013-January/071872.html http://erlang.org/pipermail/erlang-questions/2013-January/07...
  - chrisduesing 14y ago
    You seem to have forgotten to quote the next paragraph which says, "In seriousness, it looks like a nice language -- I wonder if it, or the Ruby, Python, JavaScript "front-end" toolsets, might be a better fit for extending Erlang applications to programmers who are looking for a kinder, gentler syntax?" Garret spends a fair amount of energy trying to make Erlang more accessible. http://e2project.org/erlang.html http://e2project.org/erlang.html http://www.erlang-factory.com/conference/SFBay2013/speakers/GarrettSmith http://www.erlang-factory.com/conference/SFBay2013/speakers/...
Ixiaus 14y ago
You're approaching this wrong; they do take the little and big people seriously. It's also a 20(?) year old language with a lot of features! You can't possibly add/remove everything everyone wants - I think the team behind Erlang is doing an exceptional job of maintaining stability while getting new features and cleaned up releases out. Also - my own startup uses Erlang extensively (we use Riak, yes, but our actual application is built on top of Erlang too); I would say 80% of our codebase consists of Erlang. It's rock solid and the concurrency and distribution features (and ease of use) are unmatched. Also - OTP, nothing compares to OTP yet (Akka is trying to get there, but they have a long journey ahead of them).
- jeffdavis 14y ago
  I've been trying to learn a little erlang for a while. One of the things that holds me back is the external libraries. If it's a part of erlang/OTP, then great, usually I'm happy with it. But it's hard to find, install, and update external libraries compared with many other languages (like haskell/cabal, ruby/gems, etc.). How do you deal with that on a practical level?
  - MetaCosm 14y ago
    There isn't a central clearing house at the moment. But the conventions is to use a tool called "rebar" and you simply add a dependency in your rebar.conf like {cowboy, ".*", {git, "git://github.com/extend/cowboy.git", "master"}} and then it will use cowboy's rebar.conf to download what it requires, in this case ranch. So, you can just link to the top level library you care about it most cases and let rebar deal with it.
    - jeffdavis 14y ago
      Oh, I see. Thank you. After asking around on IRC, I found out about CEAN, which looks like it's trying to be a central clearing house. But it's a little strange looking compared to ones that I'm used to... it doesn't look very community-oriented. I couldn't even find a license file for CEAN itself. But it looks like rebar offers a lot already, so I'll look into that more.