[erlang-questions] Erlang4Android

Sun Jan 20 02:21:18 CET 2013

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