<div dir="ltr">Honestly this sounds like wanting Elixir. <div><br></div><div>ChicagoBoss and BossDB would still have the benefits of the Erlang VM and also have the style of coding you are looking for.</div><div><br></div>
<div>Tristan</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 22, 2013 at 12:30 PM, Evan Miller <span dir="ltr"><<a href="mailto:emmiller@gmail.com" target="_blank">emmiller@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, Jan 22, 2013 at 6:25 AM, Loïc Hoguin <<a href="mailto:essen@ninenines.eu">essen@ninenines.eu</a>> wrote:<br>

><br>
> As for why Evan would use $handle_undefined_function instead of creating many functions, that's for him to decide. But both implementations of $handle_undefined_function allow all known uses of the feature, yet only one gets error handling and tools support straight.<br>

><br>
<br>
</div>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<br>
$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<br>
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>
anyone-who-has-ever-looked-at-a-programming-language-before-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<br>
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<br>
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_function as a way to resolve Loïc's concerns<br>
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<br>
try represent on this list as best I can.<br>
<br>
Evan<br>
<div class="im"><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>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
<br>
<br>
<br>
</div>--<br>
Evan Miller<br>
<a href="http://www.evanmiller.org/" target="_blank">http://www.evanmiller.org/</a><br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>