[erlang-questions] Improve $handle_undefined_function
Yurii Rashkovskii
yrashk@REDACTED
Wed Jan 23 00:29:12 CET 2013
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>, 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
> > >>> > erlang-q...@REDACTED
> > >>> > 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>
> > >>
> > >>
> > >
> > > _______________________________________________
> > > erlang-questions mailing list
> > > erlang-q...@REDACTED <javascript:>
> > > 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>
> >
> >
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-q...@REDACTED <javascript:>
> > 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/f3bb18db/attachment.htm>
More information about the erlang-questions
mailing list