Developers of Sympa

["Stefan Hornburg (Racke)" <address@concealed>]

On 02/21/2018 08:57 AM, 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.
> 
> * 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 )

My impression is that we can do that in Perl with operator overloading.

> 
> 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.
> 
>> However, I don't understand how it is used.
> 
> I started to write a guide that will be online ASAP
> 
>> 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.
> 

I like talks, but docs are faster and also easier to find.

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

BTW: If you add code to Sympa 6/7 please use pull requests unless it is
really trivial change.

>> 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;
>     }
> 
> 
>>> 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.
> 
>>   | 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).
> 
>>> 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).
> 
>> 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.
> 
> 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:
> 

So as a typical use case when I open a file and it doesn't exist with autodie?

if (open (...)) {
    found ... proceed
} elsif ( "File not found" ) {
    sure, we look elsewhere
} else {
    log the error and handle the problem
}

Actually a better version would be with try and catch - but how does autodie
handle that?

Regards
         Racke


> * you haven't described yet what's wrong with exception handling?
> * 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
> 


-- 
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration. Provisioning with Ansible.