It has. Doesn’t have tab completion or syntax highlighting or anything like that, but has lineediting with linenoise/readline, generally seems to work fine.
I’m not a fan of that “TIMTOWTDI” (There Is More Than One Way To Do It) mantra Damian waxes lyrical about here. It was my least favourite aspect of Perl 5.8, 10+ years ago. Back then TIMTOWTDI permeated much of the community and in my experience ensured that module documentation was often impenetrable. Typically modules would document 2+ ways of calling primitives at the micro level, refusing to recommend one over the other. Simultaneosly they would neglect to document how to use them at the macro level.
For a while there was an emphasis on object-orientated vs procedural interfaces which could be complicated.
Maybe more than any other language Perl can make people use stuff to seem “clever”. Personally, like Conway, I’m happy to be able to use either a traditional loop or a map depending on need or style. The flexibility can lead to bad code, but that’s not really the languages fault.
Well, it was my experience 10+ years ago. I haven’t really used Perl since then. The object-orientated vs proceducal interfaces was exactly it, but often they would have sub-species ISTR. It didn’t affect every module, but it was common enough that I remember it as an issue even after all this time. The two modules you link to looks fine now.
I can’t say you’re wrong. Different module authors have different styles and different approaches to documentation. For good or ill, it’s quite easy to contribute to CPAN.
On the other hand, there’s a module for almost everything, including this delightful little gem:
# A module must return a true value. Traditionally, a module returns 1.
# But this module is a revolutionary one, so it discards all old traditions.
"Liberté, égalité, fraternité ou la mort !";
Perl 6 lets you write code in precisely the way that suits you best, at whatever happens to be your (team’s) current level of coding sophistication, and in whichever style you will later find most readable …and therefore easiest to maintain.
That very aspect is more likely to make your codebase very difficult to maintain unless you are able to maintain a high level of discipline.
That being said, I have a soft spot in my heart for Perl6 and tools that let you express code in the way that’s most natural for the problem at hand. When it comes to “use the best tool for the job”, Perl6 can very often be that tool.
So, basically, he likes TMTOWDI, which really applies to practically any version of Perl. Perl 6 certainly has some interesting idiomatic features but I could find some arbitrary problem to write a clever one-liner in Perl 5, too.
does Perl 6 have a REPL? that is one of the reasons I dont use Perl 5
https://rt.perl.org/Public/Bug/Display.html?id=133969
if you just type: perl6
it goes to REPL mode
https://www.learningperl6.com/2016/10/15/experiment-in-the-perl-6-repl/
It has. Doesn’t have tab completion or syntax highlighting or anything like that, but has lineediting with linenoise/readline, generally seems to work fine.
I haven’t used Perl in a long time, but there are Perl 5 REPLs in CPAN. Not as convenient as having one built-in, but shouldn’t be a show stopper.
I’m not a fan of that “TIMTOWTDI” (There Is More Than One Way To Do It) mantra Damian waxes lyrical about here. It was my least favourite aspect of Perl 5.8, 10+ years ago. Back then TIMTOWTDI permeated much of the community and in my experience ensured that module documentation was often impenetrable. Typically modules would document 2+ ways of calling primitives at the micro level, refusing to recommend one over the other. Simultaneosly they would neglect to document how to use them at the macro level.
That’s not my experience as a Perl user. Of course module quality varies a lot, but many are clearly written and have great examples.
Example: DateTime or Math::Prime::Util.
For a while there was an emphasis on object-orientated vs procedural interfaces which could be complicated.
Maybe more than any other language Perl can make people use stuff to seem “clever”. Personally, like Conway, I’m happy to be able to use either a traditional loop or a
mapdepending on need or style. The flexibility can lead to bad code, but that’s not really the languages fault.Well, it was my experience 10+ years ago. I haven’t really used Perl since then. The object-orientated vs proceducal interfaces was exactly it, but often they would have sub-species ISTR. It didn’t affect every module, but it was common enough that I remember it as an issue even after all this time. The two modules you link to looks fine now.
I can’t say you’re wrong. Different module authors have different styles and different approaches to documentation. For good or ill, it’s quite easy to contribute to CPAN.
On the other hand, there’s a module for almost everything, including this delightful little gem:
https://metacpan.org/pod/DateTime::Calendar::FrenchRevolutionary
From the source:
That very aspect is more likely to make your codebase very difficult to maintain unless you are able to maintain a high level of discipline.
That being said, I have a soft spot in my heart for Perl6 and tools that let you express code in the way that’s most natural for the problem at hand. When it comes to “use the best tool for the job”, Perl6 can very often be that tool.
So, basically, he likes TMTOWDI, which really applies to practically any version of Perl. Perl 6 certainly has some interesting idiomatic features but I could find some arbitrary problem to write a clever one-liner in Perl 5, too.