I have been seeing the following, for the past 18 months, every time I use the cpan utility:

$ cpan
Terminal does not support AddHistory.

To fix that, maybe try>  install Term::ReadLine::Perl

cpan shell -- CPAN exploration and modules installation (v2.28)
Enter 'h' for help.

cpan[1]>
[download]

I looked into that briefly (and unsuccessfully) several times; in general, whatever I wanted to install via cpan was more important than AddHistory, which I only use infrequently anyway, so it ended up on my TODO list.

I tried with the suggested module, Term::ReadLine::Perl, as well as a variety of others including: Term::ReadLine::Perl5, Term::ReadLine::Gnu, and Term::ReadLine::Tiny. These all failed, the most common problem being the process hanging when the Term::ReadKey dependency was being installed. Actually, installation of Term::ReadLine::Tiny worked fine but it didn't provide AddHistory.

I spent some hours this morning looking into this and eventually came up with a solution. My basic Perl setup is: Win10 - Cygwin - Perlbrew - Perl 5.32.0. If you're experiencing the same problem, this solution may work for you: I can't make any guarantees as I don't have other systems on which to test this.

The only thing that worked was a completely manual installation.

Download https://cpan.metacpan.org/authors/id/J/JS/JSTOWE/TermReadKey-2.38.tar.gz then run the familiar incantation:

$ tar zxvf TermReadKey-2.38.tar.gz
$ cd TermReadKey-2.38
$ perl Makefile.PL
$ make
$ make test
$ make install
[download]

Download https://cpan.metacpan.org/authors/id/H/HA/HAYASHI/Term-ReadLine-Gnu-1.37.tar.gz then a very similar incantation:

$ tar zxvf Term-ReadLine-Gnu-1.37.tar.gz
$ cd Term-ReadLine-Gnu-1.37
$ perl Makefile.PL
$ make
$ make test
$ make install
[download]

Now I get:

$ cpan

cpan shell -- CPAN exploration and modules installation (v2.28)
Enter 'h' for help.

cpan[1]>
[download]

and moving through the command history and editing is now possible.

If you were experiencing similar problems with a different setup to me — and found this worked as is, worked after some modification, or failed abysmally — please leave a note for the next reader.

Hey there fellow esteemed Monks!

I've come to the Monastery today to ask a favour. I'm just finishing up a very long desired Perl distribution that I should be ready to publish within a day or two, and would like to ask if some of you would review and provide feedback on the README file to see if A) it's easy to understand, B) explains things unambiguously and thoroughly enough, and C) whether there are any features that I may have overlooked.

The doc should provide enough of an understanding of what I'm trying to achieve, but here's a summary:

I have over 50 CPAN distributions published, and many of them are tools to help the developer. I've always wanted a way to automatically manage my distributions from initial creation, inclusion of other features, and an automatic way to perform a release and the subsequent bump to a new development cycle. This distribution does all of this.

The distribution is named Dist::Mgr, and although I've already released a version to the CPAN, it does not work, and was only put there to verify POD formatting etc. The included binary script is named distmgr, which is what the README focuses on.

The link to the README on my repo is right here.

A few years after karlgoethebier it struck me. At age 59 $company laid me off. Good riddance.

After 8 years of not being seen really, being handed around, trying in vain to get a peer programmer at the site, mobbing, bossing, you name it, it is good to depart. There's crucial code I wrote (a pile of, er...) living there which drives part of the business, and there has been no chance for handover. Go figure.

I still feel responsible for all my perpetrations done, and they might come back to me for something something. Meanwhile I am enjoying the quietness of being unconcerned after having lived the quietness of disinterest paired with anxiety about when I will be fired.

Eat it, sucker! you didn't live up to the task, I'm telling myself. As did the TCO, having the psychological sensibility of a tank (not talking about technical skills, at all). Yeah, true, I says, but there's two sides. Flowers don't blossom in the dark, and hurling somebody down the cellar stairs shouting "why are you running?" isn't fair either.

Anyways, I might retire and try to implement perl in FORTH, or else. This is still humbly me at your service, at least at PerlMonks. I might have more time to read and post. The Great Constellation at the tip of Aquarius shows that "the times, they are a'changing".

For the "or else" part, feel free to contact me.

Respected Monks,

I've come here often to glean knowledge, ask questions, get solutions and at times, just for fun to check things out. Perl and PerlMonks has always stood me in good stead and a great source of knowledge.

I get paid to code in Perl. Which has humor value, because there are many, many Perl programmers who are better coders than I am. For those who might want to move from "Perl as a hobby" to "Perl as a job", my number one recommendation is to read and implement Josh Kaufman's "The Personal MBA" (PMBA).

If you want to program for pay, you are a business. Many of us skipped business school, and few of us can afford to take several years off of life so we can spend a few hundred thousand dollars to "learn business". In PMBA Josh explains the basic functions of business in easily digestible sections. Some of the insights seem basic; like creating an Economically Viable Product. Yet how we perceive ourselves as a producer influences how we present ourselves. For example, a person goes to a hardware store and buys a quarter inch drill bit. They don't really care about having a quarter inch drill bit, but they do care about being able to make quarter inch holes.

Hiring managers have the same perspective. They don't need another programmer, but they want to solve business problems with software. They need the ability to turn business needs into robust and maintainable code in a cost efficient manner. As you market yourself, how can you move from saying "I'm a programmer" to "I solve business problems using computer code"? Does your resume show that? Would your current team (paid or not) recommend you for that ability? If not, spend time resolving that. Build the reputation for solving problems. Build the reputation for being someone others enjoy working with. Write code that others can test and support.

2020 has been a rough year for many of us, and there many problems to be solved. Bring your problem-solving self to the table, the world needs you.

Good localtime, all.

I'm writing on the occasion of my monk-day. Nineteen years have passed since I first joined this little community, based on a recommendation from TheDamian that I read in the pair.com monthly newsletter. At the time, I'd been using Perl for about three years, and wanted to expand my horizons from just a mailing list and the monthly Toronto Perlmongers meetings.

I'm still a little amazed that a language I picked up to 'try a few things in' has ended up supporting me for over twenty years -- but open source can be weird like that.

Remember -- never stop learning. And, whenever possible, be kind. :)

Also posted this on reddit.

So I am trying to transition from using Travis-CI for some of my Perl projects (and no CI at all for the rest) to using Github Actions for all of my Perl projects.

And it looks like I'll also soon be switching all the issue trackers over from RT to Github Issues.

And I'm starting to think now might also be the time to drop support for Perl 5.6, 5.8, and even 5.10.

This doesn't mean that I'll be deliberately breaking anything on them. I'll just stop testing them.

I would probably also include something like this in Makefile.PL:

if ( $ENV{AUTOMATED_TESTING} and $] lt '5.012' ) {
  print "I really don't care.\n";
  exit 0;
}
[download]

Which I believe will earn me "NA" reports from CPAN testers, but still allow regular humans to install the distribution without issues in most cases.

So why do I want to drop support? Mostly because although I'm happy for my modules themselves to support Perl 5.8 (and even in some cases 5.6), getting a modern toolchain including cpanm, prove, etc working, cross-platform, on Perls older than 5.12 is increasingly difficult.

So consider two scenarios:

1. I continue to support those versions of Perl. I have to jump through hoops to do this. You, if you're still actively using those versions of Perl are probably also needing to jump through a lot of hoops to maintain them. We both have to jump through hoops.

2. I stop supporting those versions of Perl. I don't have to jump through hoops. You, the person actively using those versions of Perl, still have to jump through hoops, but you already were. Worst case scenario, I've added maybe one extra hoop.

Why 5.12 in particular?

• 2021 will be the tenth anniversary of Perl 5.12.

• If we're prepared to deliberately break older versions and use v5.12, then:

  • It gives us //.
  • It gives us state.
  • It gives us say.
  • It gives us implicit strictures.

There are tempting reasons to choose 5.14 instead (keyword API, JSON::PP and HTTP::Tiny in core, s///r, etc) and even 5.16 (big Unicode improvements, __SUB__) or above, but for most distributions, I think 5.12 feels right, and January 2021 seems a good time to introduce that policy.

What do other people think though?

Note: Technically, this post qualifies as paid promotion, because I work for ActiveState. But I volunteered to write about our new Platform and promote it because I think what we're doing is really cool and might be of interest to the Perl community at large.

This is a short excerpt of a longer post that you can read in full on my blog.

TLDR

• We have an entirely new system that supports Windows and Linux (macOS coming soon), providing you binary builds of the Perl core, Perl distros, and supporting C/C++ libraries.
• When you use our State Tool, you can create any number of entirely self-contained virtual environments, one per project. This makes switching between projects trivial and these virtual environments are easily shared across a team or organization.
• No more ActiveState Community License! The only licenses that apply are the original licenses for each open source package we build for you.
• You don't need a Platform account to try this out. But you can play with our system and sign up at any time and keep all the work you've done so far.
• It's usually quite fast. If we've already built a particular distro/language core for the given platform, we use a cached version, so many builds take a few seconds. Entirely new builds are slower, but still faster than doing it by hand locally in many cases, because we distribute work throughout a build farm.
• The core features are all free. Most features are free for public projects. We also have paid features including private projects, build engineering support, support for older platforms, indemnification, and more.
• The Platform has lots of other cool features like revisioned projects, advanced dependency resolution, and more.

Read the rest of the post.

Dear fellow monks,

This is an opinion piece, flames > /dev/null please.

As this crazy year approaches it’s culmination, I would like to reflect on why I still choose Perl (and C) for most, if not all, of MY work. Disclosure: I make a living with Java, Docker, AWS and a lot of tools considered “mainstream”, but I do this because companies are already biased towards what’s popular, not necessarily what’s best. And they pay good money to continue with their suffering.

In my personal endeavours however, I rarely leave the ecosystem of Perl, C, FreeBSD, and PostgreSQL. It’s a sharp contrast to today’s virtualized and SaaS world, and I wonder how these companies are so stupidly herded into working like this. I mean, back in 2006, I was creating Web Services on mod_perl2 that were hitting 6.5K TPS on a single node and I was deploying with FreeBSD Jails, almost identical to what people are doing today with Terraform and Docker, albeit, at a micro fraction of the cost. Today, the best stuff I see with the container-micro-services-mania, is a few hundred TPS at best, and extremely costly and complex. People are probably spending 100x as much as they would have spent, using bare metal and real people.I mean real programmers and sys admins who actually knew what they were doing to fine tune a real architecture.

Something smells really bad.

Sure, the modern environments shiny, somewhat convenient and hip, with SaaS or GUIs for most everything. But it’s costly and stupid. My guess is that companies will start to wake up one day, like from a bad hangover and say: W.T.F. are we doing? And it’s not just AWS, but to me the whole toolchain is broken and just crazy. The amount of waste is just horrendous and unsustainable. Just how many layers of shit are we going to continue to pile up until we realize something smells really, really bad.

Same thing with programming languages. The Java world is honestly laughable, nobody really knows what Java is anymore (most everything relatively useful and “modern” in Java is based on bending the language with generics!), and “portability” is a widely disproven myth. Then you have the plethora of new and hip languages and frameworks and the young coders who think just because Google or Facebook backed it, It must be good. Guess what, most companies are not Google or FB.

But when Netflix wakes up and rewrites their CDN on bare metal with FreeBSD it hardly makes the news.

So back to Why Perl in 2020...

Well first, we finally got rid of the Rakudo shadow(see Note 1 below) Raku and Perl languages were finally separated, lifting the long cast shadow of "Perl 6" on Perl, and Perl 7 is now on it’s way!

I can’t believe we didn’t see this textbook example on how to kill a good existing product: advertise the new one is coming, before it’s even born. There are so many examples in history, of organizations shooting themselves in the foot this way, it’s even stupid. And yet, we did exactly that. The way Perl 6 was managed was really destructive to our beloved language, and our community. Yet here we are. We survived, we are tired and demoralized, yes. But I truly think we can finally start to heal and oxygenate the ecosystem with the coming of Perl 7.

It’s time for a new dawn of The Programming Republic of Perl. Yes, we have lost a few battles, but this is a long term stamina race, not a short term sprint. There is a new saying amongst investors these days: the age of the Unicorns is over, it is now the age of the Camel. I think we should take this one home.

So why Perl in 2020, or 2050 or 3020? Simple: Perl is probably the most malleable language on the planet. I don’t think people realize it, and truly understand the value of this. IMHO, it’s the one thing that no other language can really come close to Perl.

You can start Perl project as a one-off script and then refactor it all the way up to complete Object Model like Moose (contrary to the half-baked Java OM), or you can go the Functional route, or better yet, use both. You can evolve your code using different paradigms and different frameworks (all staying within the same CPAN ecosystem) to address different problems you will encounter along the way. You can hammer out performance bottlenecks over time, even refactor some portions to C, easily! You start out with a simple script and wind up refactoring portions to different frameworks such as POE, Catalyst, Mojolicious, Dancer, etc.

Mojolicioius itself is based on the same principles (start simple, grow and refactor as you need), which is actually a unique feature of the Perl language itself.

There is a plethora of other great tools and frameworks in the ecosystem, for every taste, and you can use the same language for your complete toolchain including operations and sys admin. I mean, how cool is that?

The widespread rumor that that Perl is a write-once language is such bullshit, that people who spread it must have never actually done anything in Perl and probably in any other language, or in their miserable lives for that matter. This unfounded myth cannot be farther from the truth. I have taken all kinds of legacy Perl and slowly transition it to modernize it, or to change it’s structure completely in incremental and iterative phases along the way. All other lagunages I’ve worked with, would require complete re-writes, but not with Perl. With Perl you can gradually transition and solve specific issues you find along the way.

There is no such thing as unreadable Perl. It’s only unreadable if you are ignorant, and as such any language that is not “ for dummies” will not appeal to you. Go code in Python and be happy, but don’t trash talk Perl just because you don’t get it. Perl is for the artists, the coders that truly want to express themselves in the code itself, to make the code beautiful to them, not to anyone else or some academic fool. Perl can create beautiful code that may look ugly to someone else, that’s perfectly fine. Such is art, and programming is an art, no matter how hard we try to define it in any other way.

I haven’t seen much talk about this malleability of Perl, which to me, is frankly unique. I don’t have the academic background in computer languages to formally describe why this is so, but I do have the experience. That is over 30 years of it; not only with Perl, but with MANY other languages. I know what I’m saying is a matter of fact, but I cannot formally describe it or prove it formally. I believe this is a topic that should be studied and formally described, and it’s something that could surely help put Perl back in the place where it belongs: which like C, it’s probably almost the perfect General purpose language.

Today’s startup world is fast paced and very dynamic. Product requirements evolve in real time with actual product usage and software needs to adapt at lighting speed. When I see companies struggling every day with even the simplest of problems, I cannot believe they are not exploiting these capabilities of Perl.

Happy holidays and may the next year bring you all the best!!

Alex

Notes and Errata

Note 1: The original phrase was offensive to Rakudo which was not the intent. Please refer to commentary below for details and clarification.

Note 2: It is worthwhile to read the comments and replies, especially the the deeper nodes because there is A LOT to learn, A LOT MORE than in my OP. It made me realize there is much more to the Perl 6 story than meets the eye. For example, that early on there was mention to the second-system effect and the Apocalypse, "Second System Syndrome Done Right." , etc. There is also mention on the Three Tales of Second System Syndrome where PHP and Python went through similar processes. So please read the full commentary and deeper nodes for wonderful gems of wisdom, from our much wiser fellow monks.

see

• https://blog.plover.com/prog/haskell/monad-search.html
• https://blog.plover.com/prog/monad-search-2.html

Let's say for concreteness that we would like to solve this cryptarithm puzzle:

    S E N D
+   M O R E
-----------
  M O N E Y
[download]

This means that we want to map the letters S, E, N, D, M, O, R, Y to distinct digits 0 through 9 to produce a five-digit and two four-digit numerals which, when added in the indicated way, produce the indicated sum.

the proposed Perl code was actually the semantic translation of some Python code and was indeed clumsy (NB all those curlies at the end)

Now here my solution reusing some work I've done in the past with List Comprehensions

use strict;
use warnings;
use Data::Dump qw/pp dd/;




=pod

https://blog.plover.com/prog/haskell/monad-search.html

https://blog.plover.com/prog/monad-search-2.html

=cut


# --- List comprehension

sub from (&$;$) {
    my ($c_block, undef, $c_tail) = @_;
    my $var = \$_[1];
    sub {
        for ( &$c_block ) {
            $$var = $_;
            $c_tail->()
        }
      }
}

sub when (&$){                          # guard
    my ($c_block, $c_tail) = @_;

    sub { $c_tail->() if &$c_block }
}


# --- rem() Helper function to return digits 0..9 except @_
my %digits;
@digits{0..9}=();

sub rem {                               # set difference
    my %h = %digits;
    delete @h{@_};
    keys %h;
}


my ($send,$s,$e,$n,$d);
my ($more,$m,$o,$r);
my ($money,$y);



my $do =
  # send
  from { rem 0 } $s =>
  from { rem $s } $e =>
  from { rem $s, $e } $n =>
  from { rem $s,$e,$n } $d =>

  # more
  from { rem 0,$s,$e,$n,$d } $m =>
  from { rem $s,$e,$n,$d,$m } $o =>
  from { rem $s,$e,$n,$d,$m,$o } $r =>

  # money
  from { rem $s,$e,$n,$d,$m,$o,$r } $y =>

  # guard
  when { "$s$e$n$d" + "$m$o$r$e" == "$m$o$n$e$y" }

  # output
  sub { pp [ "$s$e$n$d" , "$m$o$r$e" , "$m$o$n$e$y" ] }
  ;

&$do;
[download]

Compilation started at Wed Dec  2 19:11:14

C:/Perl_524/bin\perl.exe -w d:/tmp/pm/send_more_money_monad.pl 
[9567, 1085, 10652]

Compilation finished at Wed Dec  2 19:11:18
[download]

NB: It could be done better and faster, I've just coded this POC from scratch within an hour.

Please note that making it "lazy" is not really a problem, left for the interested reader.

So Monads in Perl are not that complicated ... or what am I missing? ;-)

(This is my first meditation. I am posting in hopes it will help someone down the line! I can't find another node about this, but that doesn't mean there isn't one :) .)

I needed to run a program and then wait for the user to hit Enter. I tried this:

$ perl -e 'system(@ARGV); readline' echo foo
foo
Can't open echo: No such file or directory at -e line 1.
Can't open foo: No such file or directory at -e line 1.
[download]

• Make keyword "my" optional. It MUST be unnecessary to declare all lexical variables as lexical if 'use strict' is ON by default. If 'use strict' is ON then so called 'automine'(Re^4: Opinion: where Perl5 wasn't attractive for me) should be ON by default also. I mean 'my' becomes redundant, isn't it?

this post is a follow up of Module design for loadable external modules containing data but, after I squeezed my mind to spot the core of the problem and after finding some valid approach, I think it is worth a new Meditation.

A dark corner where the problem raise

In the past when I found myself, facing an error or an unexpected behaviour, thinking: "it is perl or it is me?" it was always my fault. This time maybe not. Or maybe this is a problem in the way I imagine new things and perl does not make it easy as usual. What I mean is: modules are intended as an abstraction of behaviours and scripts are generally the incarnation of these behaviours in the real life. A module can be loaded and can export subs or methods. A module can be tested because generally it does nothing but exporting abstract behaviours. Only in few rare cases a module exposes data and if so it is just some bare package variable intended to modify its internal behaviour like $Data::Dumper::Indent and even this simple use can be accomplished in other, nowadays preferred, ways like providing parameters to the constructor and providing accessors for these kind of things.

What happens if I need a new design pattern? I still need an abstraction, obviously, but I also need a serie of incarnations to be loaded indipendently upon request. These are not plugins that extend the main module with new functionalities: they are different incarnations of a mother abstraction.

In the Perl::Teacher example I need the abstraction of Perl::Teacher::Lesson but then I need the incarnation of Perl::Teacher::Lesson::first_lesson and Perl::Teacher::Lesson::second_lesson and so on.

Another project of mine ( my mad and fun Game::Term :) is stucked exactly for the very same reason. Infact I started to code ignoring the above problem and I have designed it to have incarnations (game scenarios in this case) as standalone scripts and this approach lead me to shell out when changing the current scenario, messing the whole thing (shelling out it is always a bad thing and behaves very differently on different platforms like linux and windows).

A note about data: in the current post and in the previous one with data I intend not static data but a possible longish serie of perl data as others objects, anonymous subroutines, mixed with some (few) more static fragments as texts and questions.

Abstraction/Incarnation and OO roles

I was suggested to use a role for this. Honestly I'm not a big fan of OO perl frameworks, or better saying it, I will be a big fan when I will have the need to use all the feautures they provide.
I understand a role as a trasversal behaviour applicable to different kinds of objects, traversing the simple schema of father-children inheritance. The classic example of the breakble role can be consumed by very different classes of objects like bones, cars, cookies.. But I have many incarnations to one and only one abstraction. So no transversal roles to compose. Well.. I can transform my Perl::Teacher::Lesson into a role, let say Perl::Teacher::Teachable but I cannot see any advantage over a simple inheritance.

A new design pattern?

What I imagined is an orchestrator, a super-object (in this case of the Perl::Teacher class, but the same is valid for the Game::Term project) instantiated inside a perlteacher.pl program shipped within the main distribution.

This super-object will be able to do many things related to all teaching activities (reading configuration file, interact with the user..) and its Perl::Teacher distribution will include the abstraction of what a course, a lesson, a talk, a question and a test are. But the main activity will be to load a course and its lessons in sequence.

Real courses are just containers of real lessons and are shipped separetly from the main distribution. Here is the new design pattern I see.

If you look at solution I provide below, you will see I prefere to use the constructor of the incarnation module to ship the meat to the super object. This pattern is vaguely similar to routes in modern web frameworks: fatty subroutines of behaviours and data. Well... in web programming we were told to separate the logic from the presentation and this sounds sane. I think my case is a bit different because I have mainly perl data (objects of other classes like Perl::Teacher::Test or Perl::Teacher::Question filling a lesson) in my incarnations. There is not static data to serve (as templates of html in the case of web programming) and for this reason I dislike the idea to have external, yaml or json, files containing the data to be served. Infact to use static external files I have to strictly describe their format and I loose the flexibility of a perl module (for example a lesson can provide a special kind of test defining a custom sub or loading another module).

Here I present some sketch of my approaches, for sake of semplicity not in seprated .pm files but I think you will get an idea.

Possible approaches

First option: use the constructor of the incarnation module

This is my preferred one.
The abstraction module ( My::Lesson in this example ) defines methods usable by its children. Children (incarnation modules) use the new constructor to fill in the object with all the data it needs. Filling the object is done using methods provided by the abstraction module My::Lesson

use strict;
use warnings;

# ABSTRACTION
package My::Lesson;
    
    sub new{
        my $class = shift;
        return bless { steps => [] }, $class;
    }
    
    sub add_step{
        my $self = shift;
        push @{ $self->{ steps }}, @_;
    }



# INCARNATION
package My::Lesson::Example;
    our @ISA = ( 'My::Lesson' );
    sub new{
        my $class = shift;
        my $self = $class->SUPER::new;
        $self->add_step('one','two');
        
        return $self;
    }

# USAGE
# Please note that this is only an example of usage. The real one will
+ be done by an object of the Perl::Teacher class, like in
#
# $teacher->current_lesson( My::Lesson::Example->new )
#
# or something similar
package main;

my $lesson = My::Lesson::Example->new;
[download]

Second option: using a bare EXPORT in the incarnation module to provide data

The abstraction module does not need to provide methods to its children. The abstraction module becomes an incarnation loading a data structure from My::Lesson::Example

# INCARNATION
package My::Lesson::Example;

    require Exporter;
    our @ISA = qw( Exporter );
    our @EXPORT = qw( @steps );
    
    my @steps = ( 'three', 'four' );


# ABSTRACTION
package My::Lesson;

    use Module::Load 'autoload';
    # or CPAN Module::Runtime
    
    sub new{
        my $class = shift;
        my %opts = @_;
        
        # here must be some logic to load the appropriate incarnation 
+module.
        # paying attention to the @steps array (?)
        #
        # autoload from Module::Load should be the right tool (not tes
+ted)
        # autoload $opts{lesson};
        warn "autoloading $opts{lesson}";
        
        return bless { steps => [ @steps ] }, $class;
    }
    
# USAGE    
package main;

my $lesson = My::Lesson->new( lesson => 'My::Lesson::Example' );
[download]

Note: first and second approach can be mixed letting the incarnation module authors to use the interface they prefere. Something like this should be enough:

# ABSTRACTION
package My::Lesson;

    use Module::Load 'autoload';
    
    sub new{
        my $class = shift;
        my %opts = @_;
        
        if ( $class->isa( 'My::Lesson' ) ){
            return bless { steps => [] }, $class;
        }
        elsif ( $class->isa( 'Exporter' ) ){
            # autoload $opts{lesson};
            warn "autoloading $opts{lesson}";
            return bless { steps => [ @steps ] }, $class;
        }
        else{
            die "incarnation method not recognized for class [$class]!
+";
        }        
    }
[download]

third option: static data

File::ShareDir::Install allows you to install read-only data files from a distribution and File::ShareDir will be able to retrieve them. For reasons explained above I dont intend to use this solution for the Perl::Teacher project, but can be a viable solution, for example, to provide static maps to my scenarios in the Game-Term project. Thanks to kcott to show these modules. Anyway I dont see any advice against using __DATA__ in a module (if it is not a enormous amount of data): it will be accessible from within the module itself or from outside specifying the package name as described in Special Literals (taking care to close the filehandle when finished).

Conclusions

It seems very weird to me that this design problem does not occured before. As always there is the possibility that it is me :)
I tend to imagine very complex designs with a super-object able to rule and load a plethora of incarnations. In a ideal world my perlteacher.pl will consists of a mere use Perl::Teacher; my $teacher = Perl::Teacher->new(); $teacher->run;

The ability to switch from an incarnation to another, at runtime, in Perl is only available through modules. So I need an easy way to provide this mechanism and a clear interface to propose to incarnation modules authors, if any.

I think my preferred solution, providing the meat in the incarnation module constructor, it is not so nice as interface for eventual authors but is the more perlish one I found at the moment.

Any comment, suggestion, inspiration will be welcome.

Thanks for reading.

L*

Learning difficult topics like programming languages, human languages, or the thought processes of the opposite gender can be challenging. Over time, too much challenge can be discouraging and can end the effort before success is achieved.

In my own learning efforts I have found great success in mapping out the core topics for my next level. Doing so lets me focus on what I need right now and avoid stress about not learning things beyond my current level goal. In Perl, for example, I should really know the syntax and uses of hash references before I dig into object oriented web frameworks. While the idea seems simple, and it is, it does not seem common. For me it has helped in everything from programming languages to things like human languages, shooting sports, writing fiction, and searching for new jobs. Pretty much every aspect of my life has been helped by making a good plan for the next step and ignoring everything else. Except for the "opposite gender" bit, I'm still working on that one...

Here's my learning plan for becoming a well rounded Perl Apprentice. The goal is to have the basics down solidly so that I can begin my journeymanship. Until these topics are firmly embedded in my head and skills, I do not need to be trying to do Expert Perl stuff.

Data types and sigils

• scalar, list, aray, hash, subrouting, references, objects
• Variable assignment and Scope
• Context
• Autovivication

Control Structures

• if, for, foreach, until, while, ...

Pattern Matching

• Just the basics

Files

• reading and writing
• tests and operations
• Directories

Modules

• Loading and using Standard Library modules
• Using CPAN

POD

• Documenting code

Testing

• Writing and using basic tests
• Debugging

CLI

• Input and output

Process Management

Wow! I am truly humbled and indebted to all of you who took the time to help me out on my earlier questions. This was my first post here so I was a bit hesitant as I only joined a few weeks ago and wanted to ensure I did my homework before posting. Apologies if I was not able to respond to everyone’s replies but I feel that I must digest everything you’ve provided.

(I'm posting this here because I was getting embarrassed by how long my other thread was getting.)

I’m still a novice programmer and even more of an apprentice when it comes to Perl. Reading through the documentation, my head is starting to spin. My question originated because I was trying to come up with my own subroutine to determine permutations of elements in a array and I was getting lost in how to structure the subroutine using recursion (rest assured, questions on that topic are forthcoming!) But it appears to me that I still have more of the fundamentals to learn.

If I’m honest, some of the shine of Perl is starting to fade but the quality and quantity of help I have received here are motivating me to continue!