<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>