[erlang-questions] Improve $handle_undefined_function

Loïc Hoguin <>
Wed Jan 23 00:16:15 CET 2013


I can understand 1), but what's the point of 2)? Wouldn't it be better 
for that to be in the erlang/otp repository instead so that everything 
can benefit from it?

On 01/23/2013 12:11 AM, Yurii Rashkovskii wrote:
> 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)
>
> On Tuesday, January 22, 2013 3:06:19 PM UTC-8, Garrett Smith wrote:
>
>     Looking over Elixir, I tend to agree with Tristan -- it seems to have
>     all the syntactic sugar that creative, non-hardcore, easily frightened
>     developers might like :)
>
>     In seriousness, it looks like a nice language -- I wonder if it, or
>     the Ruby, Python, JavaScript "front-end" toolsets, might be a better
>     fit for extending Erlang applications to programmers who are looking
>     for a kinder, gentler syntax?
>
>     On Tue, Jan 22, 2013 at 4:48 PM, Yurii Rashkovskii <
>     <javascript:>> wrote:
>      > Elixir doesn't have any other "undefined function" handling
>     beyond of what
>      > Erlang/OTP provides.
>      >
>      >
>      > On Tuesday, January 22, 2013 11:09:40 AM UTC-8, Tristan Sloughter
>     wrote:
>      >>
>      >> 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
>     <> wrote:
>      >>>
>      >>> On Tue, Jan 22, 2013 at 6:25 AM, Loïc Hoguin
>     <> 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 <http://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 <http://person.name>,
>     person->name, $person{name}, or
>      >>> person.name <http://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
>      >>> > 
>      >>> > http://erlang.org/mailman/listinfo/erlang-questions
>     <http://erlang.org/mailman/listinfo/erlang-questions>
>      >>>
>      >>>
>      >>>
>      >>>
>      >>> --
>      >>> Evan Miller
>      >>> http://www.evanmiller.org/
>      >>> _______________________________________________
>      >>> erlang-questions mailing list
>      >>> 
>      >>> http://erlang.org/mailman/listinfo/erlang-questions
>     <http://erlang.org/mailman/listinfo/erlang-questions>
>      >>
>      >>
>      >
>      > _______________________________________________
>      > erlang-questions mailing list
>      >  <javascript:>
>      > http://erlang.org/mailman/listinfo/erlang-questions
>     <http://erlang.org/mailman/listinfo/erlang-questions>
>      >
>     _______________________________________________
>     erlang-questions mailing list
>      <javascript:>
>     http://erlang.org/mailman/listinfo/erlang-questions
>     <http://erlang.org/mailman/listinfo/erlang-questions>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions
>


-- 
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu



More information about the erlang-questions mailing list