[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