Many reasons. <div><br></div><div>Certain API unifications (like 0-based index) are hard to do for element/setelement — and you can't override those anyway — as it will break compatibility. </div><div>Certain API extensions are much, much easier and enjoyable in Elixir as opposed to Erlang (see unicode.ex)</div><div>Designing an API that benefits from agreed-on primitives in Elixir won't be possible in Erlang so Elixir would have to use a slightly inferior base.</div><div>Elixir contributors like programming in Elixir :)<br><br>Yurii.</div><div><br>On Tuesday, January 22, 2013 3:16:15 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 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 

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

<br>> fairly good and fast Unicode implementation and a faster hash 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 to have

<br>>     all the syntactic sugar that creative, non-hardcore, easily frightened

<br>>     developers might like :)

<br>>

<br>>     In seriousness, it looks like a nice language -- I wonder if it, or

<br>>     the Ruby, Python, JavaScript "front-end" toolsets, might be a better

<br>>     fit for extending Erlang applications to programmers who are looking

>     for a kinder, gentler syntax?

<br>>

<br>>     On Tue, Jan 22, 2013 at 4:48 PM, Yurii Rashkovskii <<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 Sloughter

<br>>     wrote:

<br>>      >>

>      >> Honestly this sounds like wanting Elixir.

<br>>      >>

<br>>      >> ChicagoBoss and BossDB would still have the benefits of the

<br>>     Erlang VM and

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

<br>>      >>> > creating many functions, that's for him to decide. But both

<br>>     implementations

<br>>      >>> > of $handle_undefined_function allow all known uses of the

<br>>     feature, yet only

>      >>> > one gets error handling and tools support straight.

<br>>      >>> >

<br>>      >>>

<br>>      >>> Since my name is being thrown around as a sort of bugaboo and a

<br>>     way to

<br>>      >>> scare programmers' children with night-time stories, I'd like to

<br>>      >>> clarify why exactly I support horrible features like Pmods and

>      >>> $handle_undefined_function in the Erlang run-time.

<br>>      >>>

<br>>      >>> Most people on this list seem to care about "big-scale" issues

<br>>     like

<br>>      >>> reliability, predictability, processing kajillions of commercial

<br>>      >>> transactions, and so forth. I happen to care a lot more about

<br>>      >>> "small-scale" issues -- in particular, the programming

<br>>     experience of

<br>>      >>> one person just trying to get something to work for the 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 things

<br>>     work,

<br>>      >>> and not caring whether it's production-ready or fit to be seen by

<br>>      >>> anyone.

<br>>      >>>

<br>>      >>> I worry that Erlang is missing out on a lot of potential developer

<br>>      >>> talent because the platform's benefits tend to be 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 hobbyist has

<br>>     to be

<br>>      >>> both extremely tenacious and perhaps delusional to stick with

<br>>     Erlang

>      >>> long enough to realize the platform's benefits.

<br>>      >>>

<br>>      >>> For example, Erlang is missing one feature found in every other

<br>>      >>> language that I've used that is missing from Erlang. 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>>, not

<br>>     person:name(Person), not

<br>>      >>> proplists:get_value, not dict:fetch, just plain old stupid

<br>>      >>>

<br>>      >>>

<br>>     anyone-who-has-ever-looked-at-<wbr>a-programming-language-before-<wbr>can-understand:

<br>>

<br>>      >>> Person Dot Name. Every other language I can think of has 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>>     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>>(). I wonder how many potential

<br>>     Erlang programmers moved on

<br>>      >>> to something else because they couldn't find this very simple

<br>>     language

<br>>      >>> construct while they were playing around with Erlang for the first

<br>>      >>> time.

<br>>      >>>

<br>>      >>> Thanks to Pmods and some code generation, I was able to 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

>      >>> that, I honestly won't care so much about Pmods.

<br>>      >>>

<br>>      >>> That brings me to $handle_undefined_function. I won't actually

<br>>     use it

<br>>      >>> in production (much), since I'd rather have compile-time checks

<br>>     for my

<br>>      >>> generated functions, and I have most of the code generation I

<br>>     need at

<br>>      >>> this point. But it would have made my life a lot easier while I

<br>>     was

<br>>      >>> prototyping the library that later became BossDB. So that's why I

<br>>      >>> think it's necessary: to make it easier to experiment with ideas

>      >>> before sweating it out with the dark arts of code generation.

<br>>      >>>

<br>>      >>> I'd like to reiterate my proposal for

<br>>      >>> $should_handle_undefined_<wbr>function as a way to resolve Loïc's

<br>>     concerns

>      >>> while preserving the dynamic nature of $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 able to

<br>>      >>> experiment with it, get a feel for it, and move on to something

<br>>     else

<br>>      >>> quickly if it turns out to be a bad idea. I'm sure people will

<br>>      >>> immediately tell me that the "right" way to do it is find(person,

<br>>      >>> name, "Joseph") or something. But maybe it's not -- maybe the

<br>>     increase

<br>>      >>> in readability is worth the loss in generality. 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

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

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

<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>>     ______________________________<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>> ______________________________<wbr>_________________

<br>> erlang-questions mailing list

<br>> <a href="javascript:" target="_blank" gdf-obfuscated-mailto="71m43JJW6OUJ">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>>

<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 href="javascript:" target="_blank" gdf-obfuscated-mailto="71m43JJW6OUJ">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></blockquote></div>