Developers of Sympa

[IKEDA Soji <address@concealed>]

Marc and all,

On Wed, 21 Feb 2018 08:57:28 +0100
Marc Chantreux <address@concealed> 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 )
> 
> 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.

I'll wait.


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

My concern is that "put it all together" module might prevent commit
by occasionnal contributors and newcommer, as I wrote.

Note that this concern is not related to how that module provides
good programming experiences.  To enjoy such experience, why can't
we simply write as below at the beginning of each source?

  | use strict;
  | use warnings;
  | use English qw<-no_match_vars>;
  | use feature qw<say>;
  | use Function::Parameters;
  | use Moo;
  | use MooX::LvalueAttribute;
  | use utf8::all;

(Naturally, magic spell like -oo is unnecessary, too.)


> > > 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 feel solutions described in 11_use_autodie.t were unnecessary if
autodie was not used.

We simply want to check the result of function when we should do.
But what autodie does is blindly kills program whenever some
function returns faulty (Note: it does _not_ always mean fault of
code) value.

Here is a list of affected functions (with ':default' profile) used
in current code of Sympa.  Would you investigate if autodie helps
according to usage in real code?

  - binmode
  - chdir
  - chmod
  - chown
  - close
  - closedir
  - fork
  - kill
  - mkdir
  - open
  - opendir
  - pipe
  - readlink
  - rename
  - rmdir
  - seek
  - symlink
  - truncate
  - unlink
  - utime

  - (umask seems removed from recent version of autodie)


> > > 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 think exception (or its equivalent) will be useful and it may be
adopted, _if_ reliable implementation is provided.  But I can't find
such thing.  I try to implement it but I couldn't get satisfied
thing.

Anyway, you didn't think introducing autodie is sort of exception-
oriented style (If you thought, you found autodie is sufficient).

So, discussion about this topic seems useless for me.


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

Haven't you see what I have been doing on the code, and how code has
been changed in this one year?  Haven't you read my post at 1 Dec?

We took pains over because we can't do what we want to do soon,
don't we?

                                *

Other topic I want to discuss:

I feel utf8::all is timely.  I think Perl's (one of a few) mistake
is that it tried to upgrade byte string to character string.  The
mess caused by this trial is going to blow over, and we might really
switch to Unicode.  However, I suppose there are some points to care.

I may post on another day.


Regards,
-- Soji


> thanks for sharing.
> regards
> marc


-- 
株式会社 コンバージョン
ITソリューション部 システムソリューション1グループ 池田荘児
〒140-0014 東京都品川区大井1-49-15 アクセス大井町ビル4F
e-mail address@concealed  TEL 03-6429-2880
https://www.conversion.co.jp/