[erlang-questions] Improve $handle_undefined_function

[Evan Miller]

On Tue, Jan 22, 2013 at 6:25 AM, Loïc Hoguin <essen@REDACTED> wrote:
>
> 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.
>

Since my name is being thrown around as a sort of bugaboo and a way to
scare programmers' children with night-time stories, I'd like to
clarify why exactly I support horrible features like Pmods and
$handle_undefined_function in the Erlang run-time.

Most people on this list seem to care about "big-scale" issues like
reliability, predictability, processing kajillions of commercial
transactions, and so forth. I happen to care a lot more about
"small-scale" issues -- in particular, the programming experience of
one person just trying to get something to work for the first time and
having the code look nice. I think that's ultimately where innovation
comes from -- one person experimenting around, seeing if things work,
and not caring whether it's production-ready or fit to be seen by
anyone.

I worry that Erlang is missing out on a lot of potential developer
talent because the platform's benefits tend to be back-loaded: it's
great for the big-scale stuff, but it can be painful for a newcomer
just tinkering around and seeing if stuff works. A hobbyist has to be
both extremely tenacious and perhaps delusional to stick with Erlang
long enough to realize the platform's benefits.

For example, Erlang is missing one feature found in every other
language that I've used that is missing from Erlang. It's the ability
to write:

   Person.name

Not Person#person.name, not person:name(Person), not
proplists:get_value, not dict:fetch, just plain old stupid
anyone-who-has-ever-looked-at-a-programming-language-before-can-understand:
Person Dot Name. Every other language I can think of has something
like this, whether it's person.name, person->name, $person{name}, or
person.name(). I wonder how many potential Erlang programmers moved on
to something else because they couldn't find this very simple language
construct while they were playing around with Erlang for the first
time.

Thanks to Pmods and some code generation, I was able to come up with
what I felt was acceptable alternative in Erlang: Person:name(). If
Erlang ever gets any kind of native support for syntax that looks like
that, I honestly won't care so much about Pmods.

That brings me to $handle_undefined_function. I won't actually use it
in production (much), since I'd rather have compile-time checks for my
generated functions, and I have most of the code generation I need at
this point. But it would have made my life a lot easier while I was
prototyping the library that later became BossDB. So that's why I
think it's necessary: to make it easier to experiment with ideas
before sweating it out with the dark arts of code generation.

I'd like to reiterate my proposal for
$should_handle_undefined_function as a way to resolve Loïc's concerns
while preserving the dynamic nature of $handle_undefined_function.
Some interesting use-cases that come to mind for me are a dynamic API
like:

   person:find_by_name("Joseph")

Is that a good API? I don't know, but I'd like to be able to
experiment with it, get a feel for it, and move on to something else
quickly if it turns out to be a bad idea. I'm sure people will
immediately tell me that the "right" way to do it is find(person,
name, "Joseph") or something. But maybe it's not -- maybe the increase
in readability is worth the loss in generality. Readability and
familiarity are really important for attracting hobbyist programmers,
who have a lot to contribute to any platform, and whose interests I
try represent on this list as best I can.

Evan

>
>
> --
> Loïc Hoguin
> Erlang Cowboy
> Nine Nines
> http://ninenines.eu
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions




--
Evan Miller
http://www.evanmiller.org/