[erlang-questions] Improve $handle_undefined_function

Yurii Rashkovskii yrashk@REDACTED
Wed Jan 23 00:11:18 CET 2013 

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, 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, person->name, $person{name}, or 
> >>> 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 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> -- 
> >>> Evan Miller 
> >>> http://www.evanmiller.org/ 
> >>> _______________________________________________ 
> >>> erlang-questions mailing list 
> >>> erlang-q...@REDACTED 
> >>> http://erlang.org/mailman/listinfo/erlang-questions 
> >> 
> >> 
> > 
> > _______________________________________________ 
> > erlang-questions mailing list 
> > erlang-q...@REDACTED <javascript:> 
> > http://erlang.org/mailman/listinfo/erlang-questions 
> > 
> _______________________________________________ 
> 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/14bc666e/attachment.htm>

More information about the erlang-questions mailing list