[erlang-questions] Erlang4Android

Sun Jan 20 03:01:58 CET 2013

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.
>
>
Implicitness is not the opposite of simplicity.

"Lust conquered shame, audacity fear, madness reason" -Cicero

The verb is implicit in the last two clauses of that sentence, but there is
no confusion as to the sentence's meaning, and its style is the epitome of
simplicity. Removing the unnecessary verbs enhances one's understanding of
the sentence's parallel structure. In a similar way, the parameter list of
a pmod reinforces the concept that the module's functions are executed in a
similar context. When used with intention, it imparts understanding.

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.
>

How do you know this is true 100% of the time? It's not true in my
experience, and a Pmod design can make life considerably easier for
newcomers in some circumstances. I don't know how you can be confident
about sweeping generalizations like these.

>
> 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.
>

Ok, well they're MY problems, and let me deal with them. I am absolutely
certain that I can find applications where the catchall function will let
me produce more functionality in less time with fewer bugs. Why do you care
if I use something that you consider to be bad style? Why can't I decide
for myself if a technique's benefits outweigh the costs?

>
> 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.
>

The elimination of bugs is not the sole purpose of programming. The purpose
is to provide functionality with an acceptable defect rate. My productivity
increases because I can provide more functionality in less time by trading
security for flexibility. For some projects I use Erlang, for others C, for
others Perl. Sometimes maintainability is important, sometimes it's not.
Sometimes I'm writing code just for fun and I plan to throw it away! I like
having a lot of options, and it's important to me to have the liberty to
choose what I think are appropriate design decisions in a given situation.

>
> Call it puritanism if you want. I call it pragmatism.
>
>
What's pragmatic for you is not necessarily pragmatic for me.

Evan

>
> 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**solutions.com<robert.virding@REDACTED>
>>     <mailto:robert.virding@REDACTED**solutions.com<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@**erlang.org<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@**
>>> erlang.org <erlang-questions@REDACTED>>
>>>
>>>         http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
>>>
>>>
>>>     ______________________________**_________________
>>>     erlang-questions mailing list
>>>     erlang-questions@REDACTED <mailto:erlang-questions@**erlang.org<erlang-questions@REDACTED>
>>> >
>>>     http://erlang.org/mailman/**listinfo/erlang-questions<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@**erlang.org<erlang-questions@REDACTED>
>> >
>>
>>     http://erlang.org/mailman/**listinfo/erlang-questions<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<http://erlang.org/mailman/listinfo/erlang-questions>
>>
>>
>
> --
> Loïc Hoguin
> Erlang Cowboy
> Nine Nines
> http://ninenines.eu
>

-- 
Evan Miller
http://www.evanmiller.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130119/9a22ce81/attachment.htm>