[erlang-questions] Erlang4Android

Loïc Hoguin <>
Sun Jan 20 12:37:08 CET 2013


On 01/20/2013 03:01 AM, Evan Miller wrote:
> On Sat, Jan 19, 2013 at 7:21 PM, Loïc Hoguin <
> <mailto:>> 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.

No! It helps understanding only when you read the full sentence. If you 
arrive in the middle of the sentence, you cannot understand anything 
that is said. When reading code you rarely read the whole module, only 
fragments, and if some of them are implicitly in other modules, or 
implicitly handled by a catchall, then good luck understanding it.

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

Pmods are confusing. They break expectations. First you learn that:

   Module = my_module, Module:some_function().

will call my_module:some_function(). Pmods though:

   Pmod = {my_module, blabla}, Pmod:some_function().

will call my_module:some_function({my_module, blabla}). WTF? How is that 
supposed to be simple if a) it's completely different to your initial 
expectations and b) is resolved dynamically, which can allow for errors 
like:

   Pmod = {ok, {my_module, blabla}}, Pmod:some_function().

and now you call ok:some_function({ok,...}) instead.

But this is more of an issue of tuple calls, not parameterized modules, 
which I probably wouldn't mind if they didn't break expectations in this 
way.

So perhaps this implementation of Pmods make the easy cases easier, but 
they sure make harder things harder.

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

It's not about you. It's about trying to prevent insane features from 
getting into the language. And this above is some of the reasons why.

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

The elimination of bugs isn't the sole purpose of programming, indeed. 
But I'm pretty sure adding ways to hang yourself with isn't the purpose 
of programming either. And again I'm not against this feature per se, I 
only talked about the *implementation*. This implementation is bad, 
IMHO. And I'm well allowed to say it.

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


-- 
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu



More information about the erlang-questions mailing list