[erlang-questions] Improve $handle_undefined_function

Yurii Rashkovskii yrashk@REDACTED
Wed Jan 23 00:34:41 CET 2013


I apologize, I meant library primitives, such as use of protocols or Elixir 
records.

Elixir compiles to Erlang AST.

Also, writing unicode.ex is a PITA. Possible (of course!) but PITA.

On Tuesday, January 22, 2013 3:32:47 PM UTC-8, Loïc Hoguin wrote:
>
> I thought Elixir compiled to Erlang (and not even Core Erlang) anyway? 
> How can there be any primitive that aren't available in Erlang? The API, 
> sure, but most of Unicode has nothing to do with an API.
>
> On 01/23/2013 12:29 AM, Yurii Rashkovskii wrote:
> > Many reasons.
> >
> > Certain API unifications (like 0-based index) are hard to do for
> > element/setelement — and you can't override those anyway — as it will
> > break compatibility.
> > Certain API extensions are much, much easier and enjoyable in Elixir as
> > opposed to Erlang (see unicode.ex)
> > Designing an API that benefits from agreed-on primitives in Elixir won't
> > be possible in Erlang so Elixir would have to use a slightly inferior 
> base.
> > Elixir contributors like programming in Elixir :)
> >
> > Yurii.
> >
> > On Tuesday, January 22, 2013 3:16:15 PM UTC-8, Loïc Hoguin wrote:
> >
> >     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
> >     <yra...@REDACTED
> >      >     <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
> >      >     <emmi...@REDACTED> wrote:
> >      >      >>>
> >      >      >>> On Tue, Jan 22, 2013 at 6:25 AM, Loïc Hoguin
> >      >     <es...@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 <http://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>
> >     <http://person.name>,
> >      >     person->name, $person{name}, or
> >      >      >>> person.name <http://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
> >      >      >>> > erlang-q...@REDACTED
> >      >      >>> > http://erlang.org/mailman/listinfo/erlang-questions
> >     <http://erlang.org/mailman/listinfo/erlang-questions>
> >      >     <http://erlang.org/mailman/listinfo/erlang-questions
> >     <http://erlang.org/mailman/listinfo/erlang-questions>>
> >      >      >>>
> >      >      >>>
> >      >      >>>
> >      >      >>>
> >      >      >>> --
> >      >      >>> Evan Miller
> >      >      >>> http://www.evanmiller.org/
> >      >      >>> _______________________________________________
> >      >      >>> erlang-questions mailing list
> >      >      >>> erlang-q...@REDACTED
> >      >      >>> http://erlang.org/mailman/listinfo/erlang-questions
> >     <http://erlang.org/mailman/listinfo/erlang-questions>
> >      >     <http://erlang.org/mailman/listinfo/erlang-questions
> >     <http://erlang.org/mailman/listinfo/erlang-questions>>
> >      >      >>
> >      >      >>
> >      >      >
> >      >      > _______________________________________________
> >      >      > erlang-questions mailing list
> >      >      > erlang-q...@REDACTED <javascript:>
> >      >      > http://erlang.org/mailman/listinfo/erlang-questions
> >     <http://erlang.org/mailman/listinfo/erlang-questions>
> >      >     <http://erlang.org/mailman/listinfo/erlang-questions
> >     <http://erlang.org/mailman/listinfo/erlang-questions>>
> >      >      >
> >      >     _______________________________________________
> >      >     erlang-questions mailing list
> >      > erlang-q...@REDACTED <javascript:>
> >      > http://erlang.org/mailman/listinfo/erlang-questions
> >     <http://erlang.org/mailman/listinfo/erlang-questions>
> >      >     <http://erlang.org/mailman/listinfo/erlang-questions
> >     <http://erlang.org/mailman/listinfo/erlang-questions>>
> >      >
> >      >
> >      >
> >      > _______________________________________________
> >      > erlang-questions mailing list
> >      > erlang-q...@REDACTED <javascript:>
> >      > http://erlang.org/mailman/listinfo/erlang-questions
> >     <http://erlang.org/mailman/listinfo/erlang-questions>
> >      >
> >
> >
> >     --
> >     Loïc Hoguin
> >     Erlang Cowboy
> >     Nine Nines
> >     http://ninenines.eu
> >     _______________________________________________
> >     erlang-questions mailing list
> >     erlang-q...@REDACTED <javascript:>
> >     http://erlang.org/mailman/listinfo/erlang-questions
> >     <http://erlang.org/mailman/listinfo/erlang-questions>
> >
>
>
> -- 
> Loïc Hoguin
> Erlang Cowboy
> Nine Nines
> http://ninenines.eu
> _______________________________________________
> erlang-questions mailing list
> erlang-q...@REDACTED <javascript:>
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130122/5b8db902/attachment.htm>


More information about the erlang-questions mailing list