Developers of Sympa

[Marc Chantreux <address@concealed>]

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 )

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.

> 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;
    }


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

* 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