[erlang-questions] Improve $handle_undefined_function

Yurii Rashkovskii <>
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 < 
> >     <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 
> >     <> wrote: 
> >      >>> 
> >      >>> On Tue, Jan 22, 2013 at 6:25 AM, Loïc Hoguin 
> >     <> 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 
> >      >>> >  
> >      >>> > http://erlang.org/mailman/listinfo/erlang-questions 
> >     <http://erlang.org/mailman/listinfo/erlang-questions> 
> >      >>> 
> >      >>> 
> >      >>> 
> >      >>> 
> >      >>> -- 
> >      >>> Evan Miller 
> >      >>> http://www.evanmiller.org/ 
> >      >>> _______________________________________________ 
> >      >>> erlang-questions mailing list 
> >      >>>  
> >      >>> http://erlang.org/mailman/listinfo/erlang-questions 
> >     <http://erlang.org/mailman/listinfo/erlang-questions> 
> >      >> 
> >      >> 
> >      > 
> >      > _______________________________________________ 
> >      > erlang-questions mailing list 
> >      >  <javascript:> 
> >      > http://erlang.org/mailman/listinfo/erlang-questions 
> >     <http://erlang.org/mailman/listinfo/erlang-questions> 
> >      > 
> >     _______________________________________________ 
> >     erlang-questions mailing list 
> >      <javascript:> 
> >     http://erlang.org/mailman/listinfo/erlang-questions 
> >     <http://erlang.org/mailman/listinfo/erlang-questions> 
> > 
> > 
> > 
> > _______________________________________________ 
> > erlang-questions mailing list 
> >  <javascript:> 
> > http://erlang.org/mailman/listinfo/erlang-questions 
> > 
>
>
> -- 
> Loïc Hoguin 
> Erlang Cowboy 
> Nine Nines 
> http://ninenines.eu 
> _______________________________________________ 
> erlang-questions mailing list 
>  <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.html>


More information about the erlang-questions mailing list