[erlang-questions] Improve $handle_undefined_function

[Tristan Sloughter]

Honestly this sounds like wanting Elixir.

ChicagoBoss and BossDB would still have the benefits of the Erlang VM and
also have the style of coding you are looking for.

Tristan


On Tue, Jan 22, 2013 at 12:30 PM, Evan Miller <emmiller@REDACTED> wrote:

> 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/
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130122/949c533c/attachment.htm>