[erlang-questions] Improve $handle_undefined_function
Loïc Hoguin
essen@REDACTED
Wed Jan 23 00:32:47 CET 2013
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
More information about the erlang-questions
mailing list