[erlang-questions] Improve $handle_undefined_function
Loïc Hoguin
essen@REDACTED
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 <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-questions@REDACTED
> 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