[erlang-questions] Erlang4Android

Garrett Smith <>
Sun Jan 20 02:46:50 CET 2013


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 <> 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 <
>> <mailto:>> 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
>>     <
>>     <mailto:>> wrote:
>>
>>>     Isn't that the best reason NOT to implement it. Kill -extends()
>>>     instead, it sucks.
>>>
>>>     Robert
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>         *From:*"Björn Gustavsson" <
>>>         <mailto:>>
>>>         *To:*"Anthony Ramine" <
>>>         <mailto:>>
>>>         *Cc:*"Erlang-questions" <
>>>         <mailto:>>
>>>         *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< <mailto:>>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
>>>          <mailto:>
>>>
>>>         http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>>     _______________________________________________
>>>     erlang-questions mailing list
>>>      <mailto:>
>>>     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
>>      <mailto:>
>>
>>     http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>>
>>
>> --
>> Evan Miller
>> http://www.evanmiller.org/
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> 
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
>
> --
> Loïc Hoguin
> Erlang Cowboy
> Nine Nines
> http://ninenines.eu
>
> _______________________________________________
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions



More information about the erlang-questions mailing list