[erlang-questions] Erlang4Android
Garrett Smith
g@REDACTED
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 <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