<div>I apologize, I meant library primitives, such as use of protocols or Elixir records.<br></div><div><br></div><div><div>Elixir compiles to Erlang AST.</div></div><div><br></div><div>Also, writing unicode.ex is a PITA. Possible (of course!) but PITA.<br><br>On Tuesday, January 22, 2013 3:32:47 PM UTC-8, Loïc Hoguin wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I thought Elixir compiled to Erlang (and not even Core Erlang) anyway? <br>How can there be any primitive that aren't available in Erlang? The API, <br>sure, but most of Unicode has nothing to do with an API.<p>On 01/23/2013 12:29 AM, Yurii Rashkovskii wrote:<br>> Many reasons.<br>><br>> Certain API unifications (like 0-based index) are hard to do for<br>> element/setelement — and you can't override those anyway — as it will<br>> break compatibility.<br>> Certain API extensions are much, much easier and enjoyable in Elixir as<br>> opposed to Erlang (see unicode.ex)<br>> Designing an API that benefits from agreed-on primitives in Elixir won't<br>> be possible in Erlang so Elixir would have to use a slightly inferior base.<br>> Elixir contributors like programming in Elixir :)<br>><br>> Yurii.<br>><br>> On Tuesday, January 22, 2013 3:16:15 PM UTC-8, Loïc Hoguin wrote:<br>><br>>     I can understand 1), but what's the point of 2)? Wouldn't it be better<br>>     for that to be in the erlang/otp repository instead so that everything<br>>     can benefit from it?<br>><br>>     On 01/23/2013 12:11 AM, Yurii Rashkovskii wrote:<br>>      > It isn't really much about syntax. It is, however, about 1) macro<br>>      > capabilities, 2) saner and a more consistent stdlib (we already<br>>     have a<br>>      > fairly good and fast Unicode implementation and a faster hash<br>>     dictionary)<br>>      ><br>>      > On Tuesday, January 22, 2013 3:06:19 PM UTC-8, Garrett Smith wrote:<br>>      ><br>>      >     Looking over Elixir, I tend to agree with Tristan -- it seems<br>>     to have<br>>      >     all the syntactic sugar that creative, non-hardcore, easily<br>>     frightened<br>>      >     developers might like :)<br>>      ><br>>      >     In seriousness, it looks like a nice language -- I wonder if<br>>     it, or<br>>      >     the Ruby, Python, JavaScript "front-end" toolsets, might be a<br>>     better<br>>      >     fit for extending Erlang applications to programmers who are<br>>     looking<br>>      >     for a kinder, gentler syntax?<br>>      ><br>>      >     On Tue, Jan 22, 2013 at 4:48 PM, Yurii Rashkovskii<br>>     <<a>yra...@gmail.com</a><br>>      >     <javascript:>> wrote:<br>>      >      > Elixir doesn't have any other "undefined function" handling<br>>      >     beyond of what<br>>      >      > Erlang/OTP provides.<br>>      >      ><br>>      >      ><br>>      >      > On Tuesday, January 22, 2013 11:09:40 AM UTC-8, Tristan<br>>     Sloughter<br>>      >     wrote:<br>>      >      >><br>>      >      >> Honestly this sounds like wanting Elixir.<br>>      >      >><br>>      >      >> ChicagoBoss and BossDB would still have the benefits of the<br>>      >     Erlang VM and<br>>      >      >> also have the style of coding you are looking for.<br>>      >      >><br>>      >      >> Tristan<br>>      >      >><br>>      >      >><br>>      >      >> On Tue, Jan 22, 2013 at 12:30 PM, Evan Miller<br>>      >     <<a>emmi...@gmail.com</a>> wrote:<br>>      >      >>><br>>      >      >>> On Tue, Jan 22, 2013 at 6:25 AM, Loïc Hoguin<br>>      >     <<a>es...@ninenines.eu</a>> wrote:<br>>      >      >>> ><br>>      >      >>> > As for why Evan would use $handle_undefined_function<br>>     instead of<br>>      >      >>> > creating many functions, that's for him to decide. But<br>>     both<br>>      >     implementations<br>>      >      >>> > of $handle_undefined_function allow all known uses of the<br>>      >     feature, yet only<br>>      >      >>> > one gets error handling and tools support straight.<br>>      >      >>> ><br>>      >      >>><br>>      >      >>> Since my name is being thrown around as a sort of<br>>     bugaboo and a<br>>      >     way to<br>>      >      >>> scare programmers' children with night-time stories, I'd<br>>     like to<br>>      >      >>> clarify why exactly I support horrible features like<br>>     Pmods and<br>>      >      >>> $handle_undefined_function in the Erlang run-time.<br>>      >      >>><br>>      >      >>> Most people on this list seem to care about "big-scale"<br>>     issues<br>>      >     like<br>>      >      >>> reliability, predictability, processing kajillions of<br>>     commercial<br>>      >      >>> transactions, and so forth. I happen to care a lot more<br>>     about<br>>      >      >>> "small-scale" issues -- in particular, the programming<br>>      >     experience of<br>>      >      >>> one person just trying to get something to work for the<br>>     first<br>>      >     time and<br>>      >      >>> having the code look nice. I think that's ultimately where<br>>      >     innovation<br>>      >      >>> comes from -- one person experimenting around, seeing if<br>>     things<br>>      >     work,<br>>      >      >>> and not caring whether it's production-ready or fit to<br>>     be seen by<br>>      >      >>> anyone.<br>>      >      >>><br>>      >      >>> I worry that Erlang is missing out on a lot of potential<br>>     developer<br>>      >      >>> talent because the platform's benefits tend to be<br>>     back-loaded:<br>>      >     it's<br>>      >      >>> great for the big-scale stuff, but it can be painful for a<br>>      >     newcomer<br>>      >      >>> just tinkering around and seeing if stuff works. A<br>>     hobbyist has<br>>      >     to be<br>>      >      >>> both extremely tenacious and perhaps delusional to stick<br>>     with<br>>      >     Erlang<br>>      >      >>> long enough to realize the platform's benefits.<br>>      >      >>><br>>      >      >>> For example, Erlang is missing one feature found in<br>>     every other<br>>      >      >>> language that I've used that is missing from Erlang.<br>>     It's the<br>>      >     ability<br>>      >      >>> to write:<br>>      >      >>><br>>      >      >>>    Person.name<br>>      >      >>><br>>      >      >>> Not Person#<a href="http://person.name" target="_blank">person.name</a> <<a href="http://person.name" target="_blank">http://person.name</a>><br>>     <<a href="http://person.name" target="_blank">http://person.name</a>>, not<br>>      >     person:name(Person), not<br>>      >      >>> proplists:get_value, not dict:fetch, just plain old stupid<br>>      >      >>><br>>      >      >>><br>>      ><br>>     anyone-who-has-ever-looked-at-<wbr>a-programming-language-before-<wbr>can-understand:<br>><br>>      ><br>>      >      >>> Person Dot Name. Every other language I can think of has<br>>     something<br>>      >      >>> like this, whether it's <a href="http://person.name" target="_blank">person.name</a> <<a href="http://person.name" target="_blank">http://person.name</a>><br>>     <<a href="http://person.name" target="_blank">http://person.name</a>>,<br>>      >     person->name, $person{name}, or<br>>      >      >>> <a href="http://person.name" target="_blank">person.name</a> <<a href="http://person.name" target="_blank">http://person.name</a>> <<a href="http://person.name" target="_blank">http://person.name</a>>().<br>>     I wonder how many potential<br>>      >     Erlang programmers moved on<br>>      >      >>> to something else because they couldn't find this very<br>>     simple<br>>      >     language<br>>      >      >>> construct while they were playing around with Erlang for<br>>     the first<br>>      >      >>> time.<br>>      >      >>><br>>      >      >>> Thanks to Pmods and some code generation, I was able to<br>>     come up<br>>      >     with<br>>      >      >>> what I felt was acceptable alternative in Erlang:<br>>      >     Person:name(). If<br>>      >      >>> Erlang ever gets any kind of native support for syntax that<br>>      >     looks like<br>>      >      >>> that, I honestly won't care so much about Pmods.<br>>      >      >>><br>>      >      >>> That brings me to $handle_undefined_function. I won't<br>>     actually<br>>      >     use it<br>>      >      >>> in production (much), since I'd rather have compile-time<br>>     checks<br>>      >     for my<br>>      >      >>> generated functions, and I have most of the code<br>>     generation I<br>>      >     need at<br>>      >      >>> this point. But it would have made my life a lot easier<br>>     while I<br>>      >     was<br>>      >      >>> prototyping the library that later became BossDB. So<br>>     that's why I<br>>      >      >>> think it's necessary: to make it easier to experiment<br>>     with ideas<br>>      >      >>> before sweating it out with the dark arts of code<br>>     generation.<br>>      >      >>><br>>      >      >>> I'd like to reiterate my proposal for<br>>      >      >>> $should_handle_undefined_<wbr>function as a way to resolve<br>>     Loïc's<br>>      >     concerns<br>>      >      >>> while preserving the dynamic nature of<br>>     $handle_undefined_function.<br>>      >      >>> Some interesting use-cases that come to mind for me are a<br>>      >     dynamic API<br>>      >      >>> like:<br>>      >      >>><br>>      >      >>>    person:find_by_name("Joseph")<br>>      >      >>><br>>      >      >>> Is that a good API? I don't know, but I'd like to be<br>>     able to<br>>      >      >>> experiment with it, get a feel for it, and move on to<br>>     something<br>>      >     else<br>>      >      >>> quickly if it turns out to be a bad idea. I'm sure<br>>     people will<br>>      >      >>> immediately tell me that the "right" way to do it is<br>>     find(person,<br>>      >      >>> name, "Joseph") or something. But maybe it's not --<br>>     maybe the<br>>      >     increase<br>>      >      >>> in readability is worth the loss in generality.<br>>     Readability and<br>>      >      >>> familiarity are really important for attracting hobbyist<br>>      >     programmers,<br>>      >      >>> who have a lot to contribute to any platform, and whose<br>>      >     interests I<br>>      >      >>> try represent on this list as best I can.<br>>      >      >>><br>>      >      >>> Evan<br>>      >      >>><br>>      >      >>> ><br>>      >      >>> ><br>>      >      >>> > --<br>>      >      >>> > Loïc Hoguin<br>>      >      >>> > Erlang Cowboy<br>>      >      >>> > Nine Nines<br>>      >      >>> > <a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>>      >      >>> > ______________________________<wbr>_________________<br>>      >      >>> > erlang-questions mailing list<br>>      >      >>> > <a>erlang-q...@erlang.org</a><br>>      >      >>> > <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>>     <<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a>><br>>      >     <<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>>     <<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a>>><br>>      >      >>><br>>      >      >>><br>>      >      >>><br>>      >      >>><br>>      >      >>> --<br>>      >      >>> Evan Miller<br>>      >      >>> <a href="http://www.evanmiller.org/" target="_blank">http://www.evanmiller.org/</a><br>>      >      >>> ______________________________<wbr>_________________<br>>      >      >>> erlang-questions mailing list<br>>      >      >>> <a>erlang-q...@erlang.org</a><br>>      >      >>> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>>     <<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a>><br>>      >     <<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>>     <<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a>>><br>>      >      >><br>>      >      >><br>>      >      ><br>>      >      > ______________________________<wbr>_________________<br>>      >      > erlang-questions mailing list<br>>      >      > <a>erlang-q...@erlang.org</a> <javascript:><br>>      >      > <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>>     <<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a>><br>>      >     <<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>>     <<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a>>><br>>      >      ><br>>      >     ______________________________<wbr>_________________<br>>      >     erlang-questions mailing list<br>>      > <a>erlang-q...@erlang.org</a> <javascript:><br>>      > <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>>     <<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a>><br>>      >     <<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>>     <<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a>>><br>>      ><br>>      ><br>>      ><br>>      > ______________________________<wbr>_________________<br>>      > erlang-questions mailing list<br>>      > <a>erlang-q...@erlang.org</a> <javascript:><br>>      > <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>>     <<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a>><br>>      ><br>><br>><br>>     --<br>>     Loïc Hoguin<br>>     Erlang Cowboy<br>>     Nine Nines<br>>     <a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>>     ______________________________<wbr>_________________<br>>     erlang-questions mailing list<br>>     <a>erlang-q...@erlang.org</a> <javascript:><br>>     <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>>     <<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a>><br>></p><p><br>-- <br>Loïc Hoguin<br>Erlang Cowboy<br>Nine Nines<br><a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>______________________________<wbr>_________________<br>erlang-questions mailing list<br><a href="javascript:" target="_blank" gdf-obfuscated-mailto="Twf_jXPMiToJ">erlang-q...@erlang.org</a><br><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br></p><p></p></blockquote></div>