[erlang-questions] Improve $handle_undefined_function

[Yurii Rashkovskii]

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<javascript:>
> > wrote:
>
>> On Tue, Jan 22, 2013 at 6:25 AM, Loïc Hoguin <es...@REDACTED<javascript:>> 
>> 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 <javascript:>
>> > http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>>
>>
>> --
>> Evan Miller
>> http://www.evanmiller.org/
>> _______________________________________________
>> 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/1f0e425b/attachment.htm>