<div dir="ltr"><div class="gmail_extra">On Sat, Jan 19, 2013 at 7:21 PM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.<br>
<br></blockquote><div><br></div><div style>Implicitness is not the opposite of simplicity.</div><div style><br></div><div style><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:13px;line-height:19px">"Lust conquered shame, audacity fear, madness reason" -Cicero</span><br>
</div><div style><br></div><div style><font color="#000000" face="sans-serif"><span style="line-height:19px">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.</span></font></div>
<div style><font color="#000000" face="sans-serif"><span style="line-height:19px"><br></span></font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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.<br>
</blockquote><div><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
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.<br>
</blockquote><div><br></div><div style>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?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
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.<br>
</blockquote><div><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Call it puritanism if you want. I call it pragmatism.<div class="im"><br></div></blockquote><div><br></div><div style>What's pragmatic for you is not necessarily pragmatic for me.</div><div style><br></div><div style>
Evan</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
<br>
On 01/20/2013 01:30 AM, Evan Miller wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
If folks don't like pmods, -extends(), and error_handler, than ban them<br>
from your organization. Why is it so important to people to prevent<br>
other developers from using them? I love Erlang, but sometimes I feel<br>
oppressed by zealous Puritanism in the community. If you don't like<br>
dancing, gambling, and pmods, then don't do them... but that shouldn't<br>
stop the rest of us from having a good time.<br>
<br>
I've found that Pmods are great for writing callback modules where you<br>
want some arguments always passed in implicitly. -extends() is great if<br>
you have a lot of related callback modules and want to override<br>
functionality in some cases but not in others. It's just a way to manage<br>
code complexity, and I won't apologize for making use of it. Security<br>
and predictability are not the only desiderata in development projects.<br>
Sometimes productivity, simplicity, and manageability are more<br>
important. It all depends on the situation.<br>
<br>
I personally look forward to playing around with error_handler to<br>
GREATLY simplify code generation in BossDB. I consider it a boon to my<br>
productivity, and I think people who don't like it should just look the<br>
other way and go about their own business.<br>
<br>
Evan<br>
<br>
<br>
<br>
<br>
<br>
On Sat, Jan 19, 2013 at 5:33 PM, Tony Rogvall <<a href="mailto:tony@rogvall.se" target="_blank">tony@rogvall.se</a><br></div><div class="im">
<mailto:<a href="mailto:tony@rogvall.se" target="_blank">tony@rogvall.se</a>>> wrote:<br>
<br>
I have never used parametrized modules, so I have no clue what you<br>
talk about,<br>
but I think $handle_undefined-function may be very useful.<br>
<br>
I vote for it. :-)<br>
<br>
/Tony<br>
<br>
On 20 jan 2013, at 00:16, Robert Virding<br>
<<a href="mailto:robert.virding@erlang-solutions.com" target="_blank">robert.virding@erlang-<u></u>solutions.com</a><br></div>
<mailto:<a href="mailto:robert.virding@erlang-solutions.com" target="_blank">robert.virding@erlang-<u></u>solutions.com</a>>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
Isn't that the best reason NOT to implement it. Kill -extends()<br>
instead, it sucks.<br>
<br>
Robert<br>
<br></div><div class="im">
------------------------------<u></u>------------------------------<u></u>------------<br>
<br>
*From:*"Björn Gustavsson" <<a href="mailto:bgustavsson@gmail.com" target="_blank">bgustavsson@gmail.com</a><br></div>
<mailto:<a href="mailto:bgustavsson@gmail.com" target="_blank">bgustavsson@gmail.com</a>><u></u>><div class="im"><br>
*To:*"Anthony Ramine" <<a href="mailto:n.oxyde@gmail.com" target="_blank">n.oxyde@gmail.com</a><br></div>
<mailto:<a href="mailto:n.oxyde@gmail.com" target="_blank">n.oxyde@gmail.com</a>>><br>
*Cc:*"Erlang-questions" <<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<mailto:<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@<u></u>erlang.org</a>>><br>
*Sent:*Friday, 18 January, 2013 4:57:14 PM<br>
*Subject:*Re: [erlang-questions] Erlang4Android<div class="im"><br>
<br>
To implement the -extends() attribute that allows the<br>
implementation of a module to be extended by<br>
inheritance. That used to be implemented in the<br>
error_handler. I have removed that code in the same<br>
commit that implements $handle-undefined-function.<br>
<br>
<br>
On Fri, Jan 18, 2013 at 4:36 PM, Anthony<br></div>
Ramine<<a href="mailto:n.oxyde@gmail.com" target="_blank">n.oxyde@gmail.com</a> <mailto:<a href="mailto:n.oxyde@gmail.com" target="_blank">n.oxyde@gmail.com</a>>><u></u>wrote:<div class="im"><br>
<br>
Out of curiosity, why?<br>
<br>
--<br>
Anthony Ramine<br>
<br>
Le 18 janv. 2013 à 16:25, Björn Gustavsson a écrit :<br>
<br>
We needed that to implement the parse<br>
transformation for parameterized modules<br>
<br>
<br>
<br>
<br>
<br>
--<br>
Björn Gustavsson, Erlang/OTP, Ericsson AB<br>
<br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br></div>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a> <mailto:<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@<u></u>erlang.org</a>><div class="im">
<br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
<br>
<br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br></div>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a> <mailto:<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@<u></u>erlang.org</a>><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
</blockquote><div class="im">
<br>
"Installing applications can lead to corruption over time.<br>
Applications gradually write over each other's libraries, partial<br>
upgrades occur, user and system errors happen, and minute changes<br>
may be unnoticeable and difficult to fix"<br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br></div>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a> <mailto:<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@<u></u>erlang.org</a>><div class="im">
<br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
<br>
<br>
<br>
<br>
--<br>
Evan Miller<br>
<a href="http://www.evanmiller.org/" target="_blank">http://www.evanmiller.org/</a><br>
<br>
<br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
<br>
</div></blockquote>
<br>
<br>
-- <br><div class=""><div class="h5">
Loïc Hoguin<br>
Erlang Cowboy<br>
Nine Nines<br>
<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Evan Miller<br><a href="http://www.evanmiller.org/">http://www.evanmiller.org/</a>
</div></div>