It isn't really much about syntax. It is, however, about 1) macro capabilities, 2) saner and a more consistent stdlib (we already have a fairly good and fast Unicode implementation and a faster hash dictionary)<div><br>On Tuesday, January 22, 2013 3:06:19 PM UTC-8, Garrett Smith wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">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 href="javascript:" target="_blank" gdf-obfuscated-mailto="4sXwqQ0x8D8J">yra...@gmail.com</a>> wrote:

<br>> Elixir doesn't have any other "undefined function" handling beyond of what

<br>> Erlang/OTP provides.

<br>>

<br>>

<br>> On Tuesday, January 22, 2013 11:09:40 AM UTC-8, Tristan Sloughter wrote:

<br>>>

>> Honestly this sounds like wanting Elixir.

<br>>>

<br>>> ChicagoBoss and BossDB would still have the benefits of the 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 <<a>emmi...@gmail.com</a>> wrote:

<br>>>>

<br>>>> On Tue, Jan 22, 2013 at 6:25 AM, Loïc Hoguin <<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 implementations

<br>>>> > of $handle_undefined_function allow all known uses of the 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 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 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 experience of

<br>>>> one person just trying to get something to work for the first time and

<br>>>> having the code look nice. I think that's ultimately where innovation

<br>>>> comes from -- one person experimenting around, seeing if things 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: it's

<br>>>> great for the big-scale stuff, but it can be painful for a newcomer

<br>>>> just tinkering around and seeing if stuff works. A hobbyist has to be

<br>>>> both extremely tenacious and perhaps delusional to stick with 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 ability

<br>>>> to write:

<br>>>>

<br>>>>    Person.name

<br>>>>

<br>>>> Not Person#<a href="http://person.name" target="_blank">person.name</a>, not person:name(Person), not

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

<br>>>>

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

<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>, person->name, $person{name}, or

<br>>>> <a href="http://person.name" target="_blank">person.name</a>(). I wonder how many potential Erlang programmers moved on

<br>>>> to something else because they couldn't find this very simple 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 with

<br>>>> what I felt was acceptable alternative in Erlang: Person:name(). If

<br>>>> Erlang ever gets any kind of native support for syntax that 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 use it

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

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

<br>>>> this point. But it would have made my life a lot easier while I 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 concerns

>>> while preserving the dynamic nature of $handle_undefined_function.

<br>>>> Some interesting use-cases that come to mind for me are a 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 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 increase

<br>>>> in readability is worth the loss in generality. Readability and

<br>>>> familiarity are really important for attracting hobbyist programmers,

<br>>>> who have a lot to contribute to any platform, and whose 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>>>>

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

<br>>>

<br>>

<br>> ______________________________<wbr>_________________

<br>> erlang-questions mailing list

<br>> <a href="javascript:" target="_blank" gdf-obfuscated-mailto="4sXwqQ0x8D8J">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>______________________________<wbr>_________________

<br>erlang-questions mailing list

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