Developers of Sympa

[David Verdin <address@concealed>]

Hi Marc,

I have a few remarks.


On 21/02/2018 08:57, Marc Chantreux wrote:
> hello everyone,
>
> On Mon, Feb 19, 2018 at 07:26:05PM +0900, IKEDA Soji wrote:
> > I think Sympatic is a sort of syntax suger, syntax suger is useful
> > and I'll accept anything reasonable.
> yes. Here are some motivations:
>
> Sympa is written in Perl and it will be hard to change that. Plus:
> I love perl, i really do, and i spent last years with people who don't
> (coming from ruby, python and mindshare).
>
> This experience really helped me a lot to understand the problem with
> Perl and i can synthetize here:
>
> * Perl becomes impopular when the basic knowlegde of IT people became
>    using windows, using procedural php and then learning java at college.
>    back then, SQL was the only store and most of our colleages where
>    betting on XML to exchange things. a foreach/push combo was thought
>    "much more readable" than a map/grep expression.
Then again, I don't know many people thinking that that a grep/map is 
easier to read than procedural.
> * Because of its unix culture legacy, Perl often behave exactly at
>    the opposite of the other langages. unpacking structures are very new
>    features in python (3.6) and javascript when it was the default in
>    Perl. on the other hand, signatures are official since 5.26 when
>    everyone got it from the begining.
>
> * also, i have to admit that even if ruby failed to become the "perl
>    made right" (because it missed some important points for perl
>    mongers), the use of operators to set and modify properties are
>    really pleasant once you get the habit.
>
>      $list += $subscriber
>
>    instead of
>
>      $list->add_subscriber( $subscriber )
Not from where I stand.
I think the second form is way more readable, in addition to being 
consistent with $list->update_subscriber(), $list->get_subscriber(), etc.
> As everything i saw and heard as "cool features" are available in perl,
> once you explained those differences and provide pointers to the good
> modules, perl seems much more acceptable for the newbies and people who
> miss those features from other langages.

> Sympatic is just a "put it all together" module to have all those
> goodness from a single line.
Not really. What Sympatic does is including modules, mainly.
What you propose is enforcing a coding style. these are two different 
things.
> > However, I don't understand how it is used.
> I started to write a guide that will be online ASAP
And everybody can read already the readme in 
https://github.com/sympa-community/p5-sympatic
A lot of things are discussed here.
> > I can't neither disagree nor agree to what I havn't understood.
> i give more explainations about how to use it in a talk at fosdem:
>
> https://fosdem.org/2018/schedule/event/sympa_sympatic/
>
> if don't like talks, i'll keep you informed when the doc will be ready.
>
> > First of all, I'd like to see how it is used in the practical code.
> Sure: i'll use it in the sympa7 branch so people could have a better
> insight on real world usage of sympatic.
>
> > The changes this module will bring are non-trivial: People beginning
> > to read the code cannot be aware that accessor can be defined using
> > "has", function using "fun" or "method", ... and especially,
> > Perl builtin functions can suddenly die.  They will be aware only
> > after reading Sympatic.pm and finding Moo, Function::Parameter and
> > autodie.
> That's why i really expect the documentation of Sympatic to be well
> crafted as a single entry point for newcomers.
>
> > To audit, read or modify the code, it seems not always true that
> > hiding pragmatic modules is convenient way: People cannot touch the
> > code without reading the "user manual" of Sympatic module, in
> > addition to the code itself.
> usually, occasionnal contributors just don't read guidelines and those
> kinds of documents. if you come from other langages, i really do think
> that
>
>      method add ( Int $x ) { $self->value += $x }
>
> is easier to read than
>
>      sub add {
>          my ( $self, $x ) = @_;
>          $self->isa(__PACKAGE__)
>              or die "$self should be an instance of ${\__PACKAGE__}";
>          satisfy_int $x
>              or die "first argument ($x) was expected to be an Int";
>          $$self{value} += $x;
>      }
Except that if they don't read any guidelines, they won't know what 
"method" means.
And what soji says is that people will indeed not read guidelines, so 
they will be surprised by the sudden death of a program due to autodie 
which is the subject of this thread.

> > > Second: autodie. it's included in Sympatic. Using this modules will
> > > The argument in favour of this module is the decreasing number of lines
> > > to maintina to raise exceptions.
> > I don't understand why lazy programmers are punished by death of
> > program.  Honestly, I feel it hardly pays.
> i see autodie as a seat belt, not as a punishment :). As perldoc
> perlintro says
>
>      "Perl by default is very forgiving. In order to make it more
>      robust it is recommended to start every program with the
>      following lines"
>
> it was about
>
>      use strict;
>      use warnings;
>
> and i really think we all like it. i see autodie just as one step
> further: die sooner is die better as it avoids painfull hours of
> debug.
>
> tell me if i'm wrong but most of us are writting code with the purpose
> in mind so i really think that the default behavior should avoid
> distraction.
That's a very valid point.
However, I'm still not autodie is the answer.
> >    | unless (open $fh, '<', $file) {
> >    |    ...
> >    | }
> > but autodie looks requesting more.
> > Possiblly I'm wrong. If there is simple way with autodie, please tell
> > me. Please.
> https://github.com/sympa-community/p5-sympatic/blob/master/t/11_use_autodie.t
>
> show some ways to use it. eval should be replaced by a try/catch module
> (i found none that looks good to me but Dancer2 comes with Try::Tiny so
> i think this is a sad but reasonable choice).
Cool. I strongly agree with that proposal.
> > > I think we should maintain a minimum level of hand-made exceptions with
> > > explicit exception typing to be able to handle them correctly; the idea
> > > is that, in some cases, exceptions should make Sympa die, and in other
> > > cases it should not.
> so i am.
>
> > Currently, Sympa::Crash generates traceback and "uncaught
> > exceptions" can be tracked.
> and shouldn't from my point of view: we need to avoid the NIH syndrome
> because it means more code to debug, document and test. when i tested
> autodie, i made some try with Carp::Always and it works like a charm
> (i previously used Devel::SimpleTrace which was an inspiration for
> Carp::Always).
what is the NIH syndrom?
> > On the other hand, if autodie aims to implement exception-oriented
> > programing style, it is very unsatisfactory implementation, I think.
> > I once have tried implement more with autodie. However I don't
> > want to use such thing.
> > See: 
> > https://listes.renater.fr/sympa/arc/sympa-developpers/2013-10/msg00010.html
> why not using well crafted and documented stuff available on CPAN?
> there is no gain to write your own one.
Except it is already there and working.
On my opinion, replacing a module with CPAN must come with an added value.
> About "exception-oriented" programming: i think this is just the
> standard way to handle errors in perl and autodie makes perl just more
> consistent but I can't give you my opinion on it as:
>
> * you haven't described yet what's wrong with exception handling?
Soji agrees with exception handling.
He just does not agree with autodie. That's what he did not want to use 
again.
If you read the mail if linked, his proposal was about having a 
try/catch solution.
> * i'm really curious about a standard policy to test errors. i see many
>    options but all the descent ones comes with extra costs. I'm really a
>    fan of the haskell/rust way (the Result structure with Ok and Err) but
>    we can't afford to create such a structure for all the returns
>    especially if we want to split functions into small, testable, easier
>    to reason about ones.
>
> thanks for sharing.
> regards
> marc

--
"Mieux vaut viser la perfection et la rater que viser la médiocrité et 
l'atteindre."
- Francis Blanche

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature