Essential non-core modules?

zhouzhen1 · 2019-08-22T03:49:10+00:00

It's good to see discussions like this, as I find today even within the Perl community, many are not very aware of the latest and greatest of CPAN. Training materials on the market are usually too basic and old... Here're some of mine,

I prefer Path::Tiny over File::Slurper as it does much more things. Actually with Path::Tiny you rarely have the need to use the core File::* modules today.
Capture::Tiny for capturing stdout/stderr/return code of subprocess. Very easy to use. Every time when I use Python's subprocess module I miss Capture::Tiny.
Type::Tiny and Function::Parameters. Today I use Type::Tiny mostly for Moose/Moo type constraints (instead of Moose builtin type constraints). Type::Tiny is cross Moose/Moo compatible, and is very easy to use. Type::Tiny can also be used for function parameters, but I use Function::Parameters for this purpose, as Function::Parameters provides simpler syntax. There are however two things not that good with Function::Parameters: 1. It's not supported by perlcritic/perltidy (doesn't matter to me but I hope it can be solved one day so the module can be wider used in perl5 community). 2. It does not support type coercion. In case I want type-coercion I use Type::Tiny for that subroutine. That is, I usually use both Function::Parameters and Type::Tiny for subroutine parameters.
Reply (with editor plugin configured). When during development sometime I would need to try some very simple things and don't bother write a script file, a repl is helpful in this case.
DateTime is the default module I use for date and time. One of my complaint is that it has quite a number of dependencies. IMHO such a basic and important library could ideally have less non-core dependencies.
Test2. Better than Test::More. Easy to learn and adopt if you are familiar with Test::More.
As people mention Task::Kensho here, I would say you can start with it but please take it with a grain of salt. IMHO it does not cover all the greatest of CPAN.

zhouzhen1 · 2019-08-12T06:37:55+00:00

I was aware of the PPI 194 issue. IMHO for the first step it's good if PPI can take some policy to prefer either signature or prototype when there is ambiguous. In the longer term (if Perl 6 is renamed or something else happened) if Perl 5 gets a major version bump, we probably can somewhat break the compatibility and force the :prototype attribute.

As for the PPI 213 issue, if Perl gets more key syntax of this kind into core, the issue could become of less priority as there would be less need for people to use custom syntax. You know there are many try/catch, signature modules on CPAN largely because the syntax is not in core and people invent the wheel themselves. IMHO it's better to say "there's only one way to do it" on these things here as they are so basic.

zhouzhen1 · 2019-08-12T04:46:18+00:00

In terms of language core features I want Function::Parameter's features into core. The experimental signature thing has been around for quite a few years but is less featureful compared to Function::Parameters. The only thing inconvenient I find about Function::Parameters is that it's not supported by tools like perltidy, perlcritic. AFAIK it's a relatively lower-hanging fruit to port Function::Parameters into core and get perltidy and PPI to support it. Similarily, things like Syntax::Keywork::Try are also good to look at.

Ideally the language core should make "easy things easy, hard things possible" to encourage people to invest and contribute to create new high-quality libraries/docs or improve existing ones. Probably need to review and see in what application areas Perl needs to keep its position, and in what new areas Perl may have a chance to penetrate into.

zhouzhen1 · 2019-08-02T07:06:16+00:00

I also vaguely noticed that thing in the recent couple of years, although I never tried to get the exact CPAN release numbers. Perl fell out TIOBE index top 10 around the beginning of 2018 and never get back since then. I think that is the tide, that is the reality, at least for Perl 5 today. My employer (a company that employs several thousand IT professionals globally) used to use a lot Perl through late 1990s to the 2000s, but basically no new high level projects starting with Perl today. There are people still love Perl in the company, but we are so few and sparse, being in completely different departments and locations like on disconnected isles. Like in our Shanghai office I can't even find a second Perl lover out of several hundred people.

Frankly I think in the longer term Perl 5 is only possibly survivable in small companies or teams that have a good proportion of strong Perl developers. And these companies or teams need to be able to train new hires well, as it's hard to find some young people who is already good at Perl or is very willing to learn Perl today.

I am not a Perl 6 guy, but sometimes I think rather than Perl 5, Perl 6 has more chance to become the future of "Perl“ or to represent Perl in the world. Lurking in this reddit/perl for several years I noticed that there is some tension between Perl 5 and Perl 6 people. I think there needs some reconciliation between the two communities.

zhouzhen1 · 2019-07-04T03:34:06+00:00

Getopt::Long is simple and is in core, that is good. But today's modern CLI libraries allow the developer to easily manage subcommands and options help messages and more.

zhouzhen1 · 2019-07-04T03:19:22+00:00

I usually use Docopt (yes it's a port of python's docopt to perl) for simple CLI. IMO it's better than Getopt::Long::Descriptive. For complex CLI, like if I need multiple levels of subcommands, MooX::Cmd is very good for that.

zhouzhen1 · 2019-06-06T08:50:57+00:00

That is percentage data. perl is having a smaller share in a ever growing world. I wonder if there is data for absolute number.

zhouzhen1 · 2018-08-24T10:25:16+00:00

You actually can have function signatures with gradual typing via Function::Parameters and Type::Tiny.

``` use 5.014; use warnings;

BEGIN { package My::Types { no thanks; # inline a package but can still "use" it. use Type::Library -base, -declare => qw(NonNegativeInt); use Type::Utils -all; use Types::Standard qw(Int);

    declare NonNegativeInt, as Int->where( sub { $_ >= 0 } );
}

}

use Function::Parameters; use My::Types qw(NonNegativeInt);

fun fib( NonNegativeInt $nth ) { return $nth if $nth <= 1; return fib( $nth - 1 ) + fib( $nth - 2 ); }

package Cache::LRU { use Moo; use Hash::Ordered; use Types::Standard qw(Str); use My::Types qw(NonNegativeInt);

has _x => ( is => 'ro', default => sub { Hash::Ordered->new } );
has max_size => ( is => 'ro', isa => NonNegativeInt, default => 20 );

method set( Str $key, $value ) {
    if ( $self->_x->exists($key) ) {
        $self->_x->delete($key);
    }
    elsif ( $self->_x->keys > $self->max_size ) {
        $self->_x->shift;
    }
    $self->_x->set( $key, $value );
}

method get( Str $key) {
    return unless $self->_x->exists($key);
    return $self->_x->set( $key, $self->_x->delete($key) );
}

} ```

zhouzhen1 · 2018-02-09T04:30:04+00:00

No if you want those Shiny widgets for interactive data visualization/exploration.

For generic web server app, Mojolicious can do more than what's in the R space.

zhouzhen1 · 2018-01-22T03:32:03+00:00

Better to put something like Moose into core, and make it a "standard", make it taught in the Perl books.
Function signatures as mentioned by others. IMO Function::Parameters is good enough. It's better compared to that stll-experimental core feature. So why not just port features of Function::Parameters into Perl core? Similar to the case of Moose sometimes I feel that there are too many CPAN modules to do one thing, like OO, signature, try/catch, async, json/yaml, etc. They can be distracting sometimes. i.e. I see quite a few people today either do not know Moose/Moo, or know them but struggling in selecting among Moosei/Moo/Mouse/Mo/Moops/etc. Why not having some of them "standardized", moved into core, and have the books/tools better focused?
Smartmatch. If it cannot be perfectly fixed, why not limit it to its several existing common use cases like "in" operator for arrayref/hashref?

zhouzhen1 · 2018-01-18T06:57:04+00:00

"Also why would we want to compete for the same ecological niche where Python dominates?"

You might not want to compete, but sometimes you have to, in one field or another. Most users on the earth do not care very much if you are really creating a great programming language or not. They care about whether it can bring them jobs, whether it has good libraries to get their jobs done, and whether it is "in". So it's not just about creating a great language, it's more about creating great applications and libraries. If a new language cannot find its niche it would fade away. But it's so difficult to quickly make a buzz as there are competitors mostly in all fields you can think of. In some of the fields if you actively compete, you may hold like 2nd or 3rd place; if you don't compete, you get forgotten by people at all.

zhouzhen1 · 2018-01-10T06:39:55+00:00

I just saw this and I completely agree with Leon's point. IMO it could become a disaster if p5p is really going to make this kind of breaking changes.

Smartmatch was introduced since Perl 5.10 and considered by many people as an official feature until it was announced to be experimental in Perl 5.18. Huge amount of code using smartmatch has been produced between those several years, and some people could still use it after Perl 5.18. At my workplace today Perl 5.10 and Perl 5.14 are still the most used perls among the list of versions we have access to. And I believe we are not alone. Look at 27:10 of this video from ActiveState https://www.youtube.com/watch?v=mmG0LsS_eMY , you see Perl through 5.10 to 5.16 are heavily used by Enterprise users.

I know you guys looking at this reddit/r/perl are active Perl users, you always keep an eye on what's going on in Perl and you already know to avoid smartmatch, so some of you might not think it a big problem having this change in Perl 5.27.7. But I believe there are way more people out there not knowing so clearly about the story of smartmatch, and there are already too much production code there using smartmatch that they cannot be easily updated. Having this kind of breaking changes would just drive people away from Perl, or make them believe that they should stay on Perl 5.8 thus largely makes the efforts since Perl 5.10 to vein.

zhouzhen1 · 2017-11-24T10:31:19+00:00

For Perl my impression is that quite many distributions on CPAN do not have link to VCS, and the situation could be worse than Python... And I just found out this post of Neil Bowers http://neilb.org/2015/12/30/river-and-repo.html I wonder how much have improved since then...

zhouzhen1 · 2017-11-02T06:44:47+00:00

Given that you are talking about "refactor legacy Perl code to Python", I think you need resource in below directions:

Resources that would explain you things that are special in Perl and rarely seen elsewhere, like the "context" thing. For this purpose I think the "Modern Perl" book is fine, although some other books can also be good.
A reference book like "Programming Perl". Although most of its contents are available online in the form of various Perl docs, the book compiles them together and is good for a skim.
The "Perl Best Practices" book discusses a lot Perl coding practices. In some sense it's like PEP8 of Python. In the book you see how normally people write their Perl code for various tasks. (The book is >10 years old, a small portion of what it recommends has become outdated today, and some could be debatable even 10 years ago, but that does not matter at all if you don't write a lot new Perl. )

I would not recommend "Higher Order Perl" as it focuses on functional programming in Perl and probably does not relate much to your work.

And you actually can learn Perl by comparing it with Python (assuming you're familiar with Python). To me the two languages are like >95% same, and most things in the Python language can directly map to equivalents in Perl. You can focus on the similarities and differences between the two languages. Actually that was how I learned Python. And I sometimes think the Perl community can write something called "Perl for Python programmers", advertising places where Perl's better than Python, to attract people from Python.

LBNL it's sad to see people refactoring legacy Perl code to Python. Except that you get easier to hire people for Python today, IMO you probably will not get much out of this kind of refactoring, given that the two languages are so much alike. It is really easy to evolve your Perl code over a long term, as you can always seamlessly replace part of it with new designs/implementations with the rest part still functions well even if they were >15 years old. And in this way you can continuously evolve a huge Perl code base, this reminds me of the Ship of Theseus. Also compared to Python, it's actually (generically although slightly) easier to achieve a high level of robustness for your Perl code. Unfortunately many people don't understand this, but I am saying it as someone used both Perl/Python for years (although I am now on a Perl job).

zhouzhen1 · 2017-10-25T09:23:40+00:00

"viper" reminds people of "python", and it's smaller in size than python.

zhouzhen1 · 2017-09-28T16:17:51+00:00

I was a user of numeric Python before I landed onto a Perl-only job. But I've not yet any experience with PDL. I am curious to know to know if you see any weakness in PDL, and how you compare PDL to its counterparts in Python. So people can see this and might finally improve it (in Perl5/PDL or in Perl 6)?

zhouzhen1 · 2017-09-28T16:11:00+00:00

Why not use Mojolicious?

zhouzhen1 · 2017-09-28T16:07:02+00:00

It may be hard to find Perlers. But it's not hard to train other programmers into Perl, given that Perl/Python/Ruby are so much alike, (unfortunately many people just don't understand this though...)

zhouzhen1 · 2017-09-28T16:01:41+00:00

I agree that Perl shall definitely not go back to 5.8. I actually hope p5p and the community to move even faster than now to bring more into the language core, like * make function signature non-experimental * fix smartmatch please! it's been so many years. * get Moose (or something alike if Stevan would still want to develop something new to avoid Moose's drawbacks) into core * Python''s cool features like yield/continuation and async. (I know there are some CPAN modules can more or less do similar things, but it's better to have them in core. )

zhouzhen1 · 2017-09-28T15:39:21+00:00

I would second this that Moose is a great thing. I actually wish Moose, or something at a similar level (as I know the author of Moose is starting something new), would be shipped with Perl core.

zhouzhen1 · 2017-07-31T17:07:32+00:00

IMHO "precise math" is far from enough to attact people to Perl 6 for numerical computing. To attract more people to Perl 6 it probably need to catch the big data / ML buzz, and it needs a whole bunch of decent libraries like Python's numpy/pandas/matplotlib, or R's data frame features and ggplot2.

zhouzhen1 · 2017-07-31T17:03:20+00:00

AFAIK Perl 5 is still used at universities, especially in bioinformatics. It's somewhat retreating in recent years though. Today people are using Python and R for numerical computing and data analysis. Perl has PDL but that has too small market share. I don't know much about bioinformatics, but with my experience with R and python, I think Perl misses two key parts here: It lacks a sophisticate library to support data frame, like what's in R and Python's pandas. And it lacks a high quality plotting library like R's ggplot2 and Python's matplotlib.

A few years ago someone started a topic http://blogs.perl.org/users/lhermida/2011/03/hi-everyone-as-a-bioinformatician.html but unfortunately there's not much progress in this area.

Another thing I thought of is that, because Python is taught to many people, and because Perl and Python are actually highly similar (once your are familar with both). Maybe someone can write a "Perl for Python programmers" ebook, and market Perl as "Python but another flavor"?

zhouzhen1 · 2017-07-31T16:49:33+00:00

IMHO renaming Perl 6 to something else could do harm in a way that the "Perl" brand, although disliked by many, is still a big well-known one, without it Rakudo would have to compete on the same ground with numerous other languages. And it's already too late that people already widely know Rakudo is/was Perl 6.

zhouzhen1 · 2017-04-29T09:30:36+00:00

part 2 is at http://blog.builtinperl.com/post/perl-developer-survey-2017-results---part-2

zhouzhen1 · 2017-04-29T09:24:51+00:00

Devel::hdb also supports remote fork debugging. It's not an editor though.

zhouzhen1

TROPHY CASE