[erlang-questions] Improve $handle_undefined_function

[Garrett Smith]

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 <yrashk@REDACTED> 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-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>