[erlang-questions] Erlang4Android

Garrett Smith g@REDACTED
Sun Jan 20 03:04:24 CET 2013 

Apologies, this reference isn't universal and some have asked:

http://en.wikipedia.org/wiki/Dunking

For the record, and as a Puritan, Evan is not a witch and actually
makes an excellent point.

Though it would still be fun to dunk him.

On Sat, Jan 19, 2013 at 7:46 PM, Garrett Smith <g@REDACTED> wrote:
> Wouldn't it be simpler to just dunk Evan under water and see if he's
> *actually* a child of Satan?
>
> On Sat, Jan 19, 2013 at 7:21 PM, Loïc Hoguin <essen@REDACTED> wrote:
>> You are talking about simplicity, but also saying Pmods are great because of
>> arguments passed implicitly. Isn't implicitness the opposite of simplicity?
>> It requires a lot more knowledge and care to get it working properly.
>>
>> The more implicit things you have in a project, the more its complexity
>> increases, because you have to look around all the time, or remember many
>> things to understand how it works. It makes it harder for newcomers of
>> course, but also for you, because the range of things you can mess up
>> increases.
>>
>> In the case of this catchall function, for example, you increase complexity
>> because you will have to also make sure to handle the calls that you don't
>> want. Before you had one problem: writing proper exported functions. Now you
>> have this additional problem: make sure other calls result in an expected
>> error. Because you have two problems now, that means you can't really
>> pattern match the arguments directly, if the pattern match fails you'll end
>> up throwing an undefined function error when you instead wanted a badarg.
>> And that's just the tip of the iceberg.
>>
>> How does increasing the range in which you can make mistakes improve your
>> productivity? If there's more chances for bugs to happen, then you will have
>> more bugs. How is that more maintainable? You maintain it more, for sure,
>> but I don't think that's the intended effect. The most maintainable code is
>> the one you never need to look at again.
>>
>> Call it puritanism if you want. I call it pragmatism.
>>
>>
>> On 01/20/2013 01:30 AM, Evan Miller wrote:
>>>
>>> If folks don't like pmods, -extends(), and error_handler, than ban them
>>> from your organization. Why is it so important to people to prevent
>>> other developers from using them? I love Erlang, but sometimes I feel
>>> oppressed by zealous Puritanism in the community. If you don't like
>>> dancing, gambling, and pmods, then don't do them... but that shouldn't
>>> stop the rest of us from having a good time.
>>>
>>> I've found that Pmods are great for writing callback modules where you
>>> want some arguments always passed in implicitly. -extends() is great if
>>> you have a lot of related callback modules and want to override
>>> functionality in some cases but not in others. It's just a way to manage
>>> code complexity, and I won't apologize for making use of it. Security
>>> and predictability are not the only desiderata in development projects.
>>> Sometimes productivity, simplicity, and manageability are more
>>> important. It all depends on the situation.
>>>
>>> I personally look forward to playing around with error_handler to
>>> GREATLY simplify code generation in BossDB. I consider it a boon to my
>>> productivity, and I think people who don't like it should just look the
>>> other way and go about their own business.
>>>
>>> Evan
>>>
>>>
>>>
>>>
>>>
>>> On Sat, Jan 19, 2013 at 5:33 PM, Tony Rogvall <tony@REDACTED
>>> <mailto:tony@REDACTED>> wrote:
>>>
>>>     I have never used parametrized modules, so I have no clue what you
>>>     talk about,
>>>     but I think $handle_undefined-function may be very useful.
>>>
>>>     I vote for it. :-)
>>>
>>>     /Tony
>>>
>>>     On 20 jan 2013, at 00:16, Robert Virding
>>>     <robert.virding@REDACTED
>>>     <mailto:robert.virding@REDACTED>> wrote:
>>>
>>>>     Isn't that the best reason NOT to implement it. Kill -extends()
>>>>     instead, it sucks.
>>>>
>>>>     Robert
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>         *From:*"Björn Gustavsson" <bgustavsson@REDACTED
>>>>         <mailto:bgustavsson@REDACTED>>
>>>>         *To:*"Anthony Ramine" <n.oxyde@REDACTED
>>>>         <mailto:n.oxyde@REDACTED>>
>>>>         *Cc:*"Erlang-questions" <erlang-questions@REDACTED
>>>>         <mailto:erlang-questions@REDACTED>>
>>>>         *Sent:*Friday, 18 January, 2013 4:57:14 PM
>>>>         *Subject:*Re: [erlang-questions] Erlang4Android
>>>>
>>>>
>>>>         To implement the -extends() attribute that allows the
>>>>         implementation of a module to be extended by
>>>>         inheritance. That used to be implemented in the
>>>>         error_handler. I have removed that code in the same
>>>>         commit that implements $handle-undefined-function.
>>>>
>>>>
>>>>         On Fri, Jan 18, 2013 at 4:36 PM, Anthony
>>>>         Ramine<n.oxyde@REDACTED <mailto:n.oxyde@REDACTED>>wrote:
>>>>
>>>>
>>>>             Out of curiosity, why?
>>>>
>>>>             --
>>>>             Anthony Ramine
>>>>
>>>>             Le 18 janv. 2013 à 16:25, Björn Gustavsson a écrit :
>>>>
>>>>                 We needed that to implement the parse
>>>>                 transformation for parameterized modules
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>         --
>>>>         Björn Gustavsson, Erlang/OTP, Ericsson AB
>>>>
>>>>         _______________________________________________
>>>>         erlang-questions mailing list
>>>>         erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>>>>
>>>>         http://erlang.org/mailman/listinfo/erlang-questions
>>>>
>>>>
>>>>     _______________________________________________
>>>>     erlang-questions mailing list
>>>>     erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>>>>     http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>>     "Installing applications can lead to corruption over time.
>>>     Applications gradually write over each other's libraries, partial
>>>     upgrades occur, user and system errors happen, and minute changes
>>>     may be unnoticeable and difficult to fix"
>>>
>>>
>>>
>>>
>>>     _______________________________________________
>>>     erlang-questions mailing list
>>>     erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>>>
>>>     http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>>
>>>
>>> --
>>> Evan Miller
>>> http://www.evanmiller.org/
>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>
>>
>> --
>> Loïc Hoguin
>> Erlang Cowboy
>> Nine Nines
>> http://ninenines.eu
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions

More information about the erlang-questions mailing list