I've decided that it really would be better for there to be a new, separate PerlMonks for Perl 6, when it goes mainstream.

I know that, from a Perl 5 / Existing PerlMonks perspective, there are good arguments to be made for keeping the "Perl Community" unified. However:

1. Having a separate site for Perl 6 does not imply that the Perl Community is fractured. As it is, there are plenty of Perl-related sites. What's one more? ;-)

2. Looking forward to that glorious future when "Perl" means "Perl 6", it would be kind of a drag to have the principal Perl community site encumbered with so much Perl 5 baggage: multitudes of Q&A, documentation, tutorials, contributed code, etc., etc., pertaining to a language which is no longer of any interest but archeological.

3. Perhaps most importantly, we are now more than painfully aware that the architecture of PerlMonks suffers from serious problems, flaws, and kludgities. In many ways, this is analogous to the situation with Perl 5 which inspired @Larry to rewrite the next version of Perl from scratch.

I see the passing of the torch to Perl 6 as the perfect opportunity to re-invent PerlMonks as well. To make it new, better.

So I propose that we, Perl Monks, officially, start drafting a roadmap, a spec, for a new PerlMonks. We want to capture everything that's good about PerlMonks, everything that makes it "work". And we also want to take note of what's bad, what's broken, so that we may consciously avoid those problems in the next version.

One of the really great things about the current incarnation of PerlMonks is that the engine is written in Perl (5). The users of the language can maintain the site in their own language. (Or, to put it another way, the site's maintainers are drawn from the site's users.) It is a stellar example of a language community successfully eating their own dogfood. (And it may, conversely, go a long way toward explaining the failure of Java Junkies, for example.) Therefore:

A Perl 6 community site should be written in Perl 6.

Of course, this presumes the existence of a decent web site framework written in Perl 6...

Hey Arunbear, if you got your ears on.... moritz mentioned that you were working on a rewrite from scratch. True? If so, what is the status of that? Even if it's comatose, perhaps you could contribute its roadmap or other foundational artifacts.

Getting Started with Moose

I recently decided to get with the program and use Moose in my current/impending projects. All the cool kids are doing it!

I immediately hit a roadblock: I'm using ActiveState Perl, and their repository does not have Moose. (Apparently they had some problems building it.)

So I went searching, got help, and resolved my problems. Now I have Moose installed. Here's how I did it, and below are links to essential Moose-related resources.

But first, I want to mention something which I found confusing: MooseX. What is MooseX? How is it different from Moose?

MooseX is a namespace for Moose eXtensions which are not part of the Moose package proper. You will find a large number of Moose extensions in the MooseX namepace on CPAN.

Windows: ActiveState Perl 5.8

1. If you don't already know how to, read A guide to installing modules for Win32.
2. Add the following repository to your configuration:
   http://theoryx5.uwinnipeg.ca/ppms/package.xml
   You can name it "kobes".
3. While viewing all packages (vs. viewing installed packages), find "Moose" in the list, and install it. (Type  ppm install Moose to circumvent the gui.)

Alternative ppm repositories are available; see http://theoryx5.uwinnipeg.ca/ppms/ for some suggestions.

Windows: ActiveState Perl 5.10

1. If you don't already know how to, read A guide to installing modules for Win32.
2. Add the following repository to your configuration:
   http://cpan.uwinnipeg.ca/PPMPackages/10xx/package.xml
   You can name it "kobes".
3. While viewing all packages (vs. viewing installed packages), find "Moose" in the list, and install it. (Type  ppm install Moose to circumvent the gui.)

Alternative ppm repositories are available; see http://cpan.uwinnipeg.ca/PPMPackages/10xx/ for some suggestions.

Other platforms, including Strawberry Perl on Windows

ActiveState Perl has its own way of doing things; the rest of the world uses a module installation tool called cpan.
Please read A Guide to Installing Modules if you are not familiar with it.

Install Moose by typing   install Moose at the cpan> prompt.
This will install Moose and a number of dependencies directly from CPAN.

Windows: Camelbox Perl

If you're using Camelbox, you're in luck: Moose is pre-packaged with the perl installation. However, you may still wish to install some Moose extensions, which are not-prepackaged with Camelbox.

Resources

• The Moose's Mouth, so to speak
• The Moose::Cookbook
• Moose Quick-Ref Card (PDF, 100kb)
• Type Constraints for Perl Intrinsic Types (for those who already know something about Moose)
• IRC channel #moose on irc.perl.org
• Programming with Moose - online book

perlhacktut?

Once upon a time, Simon Cozens wrote a document intended to help novice perl5-porters get up to speed. He called it "perlhacktut", and posted it to the p5p mailing list.
That early version says that the document would be available at http://perlhacker.org/p5p-faq — perlhacker.org being Simon's own web site.
One instance of the document is cached at the Wayback Machine as http://perlhacker.org/articles/perlhacktut.html.
Other google searches for perlhacktut track it to locations like http://justanother.perlhacker.org/, also on Simon's server.
Unfortunately, sometime in/before 2001/04, the server was permanently lost, as memorialized here.
Sometime after 2017/02, the perlhacker.org domain registration was lost, and is now being squatted upon.

A version of that early article appeared in the first issue of The Perl Review. It's now gone from that site, but the Wayback Machine has a copy.

At some point the name of the document was changed to "perlhack", since the perl doc naming convention stipulates that name be no longer than 8 characters (something to do with the DOS 8.3 stricture). So if you were looking for "perlhacktut", you want "perlhack".

After the demise of perlhacker.org, Simon set up a new website, and the document lived there until that site followed its predecessor into oblivion. The latest version The Wayback has is from 2009/03.

The document (perlhack) is now in the standard documentation set, and is even linked prominently on the the main perl5 dev site, as How to hack on Perl.
It can be linked from PerlMonks as [doc://perlhack]

Originally posted as a reply to How Low Can I Go?

Update: Despite what you may hear to the contrary, there is no node 17.

When I asked vroom about it, he said:

#perlmonks [2007-10-18 11:49:50] <vroom> the real answer is paco's younger brother, who has since been erased from perlmonks history

(I prefer /msges to replies, whenever practical.)

(RFC) Arrays: A Tutorial/Reference

Array is a type of Perl variable. An array variable is an ordered collection of any number (zero or more) of elements. Each element in an array has an index which is a non-negative integer. Perl arrays are (like nearly everything else in the language) dynamic:

1. they grow as necessary, without any need for explicit memory management;
2. they are heterogeneous, or generic, which is to say, an array doesn't know or enforce the type of its elements.

The values of Perl array elements can only be scalars. This may sound like a limitation, if you think of scalars only as comprising numbers and strings; but since scalars can be references to the compound variable types (array and hash), arbitrarily complex data structures are possible. Other scalar types, such as filehandles and the special undef value, are also naturally allowed.

So, given a data structure like that, what kinds of things would you want to do with it? That is, what operations should be able to act on it? You might conceive different sets of operations, or interfaces, depending on how you expect to use an array in your program:

1. as a monolithic whole;
2. as a stack or queue — that is, only working with its ends;
3. as a random access table of scalars — that is, working with all of its elemental parts.

PS: This RFC has been converted into an actual tutorial, Arrays: A Tutorial/Reference.

Those looking for a wiki in Perl might be interested in Socialtext (sourceforge, wiki).

It has an astonishing amount of features and capabilities. The only thing left to wonder about is how easy it is to install.... ;-)

Every now and then I hear people say I might have an "XY problem". What is that?

"XY Problem" explanations by various people:

---

You want to do X, and you think Y is the best way of doing so. Instead of asking about X, you ask about Y.

— from Re: sequencial file naming by Abigail

---

You're trying to do X, and you thought of solution Y. So you're asking about solution Y, without even mentioning X. The problem is, there might be a better solution, but we can't know that unless you describe what X is.

— from Re: How do I keep the command line from eating the backslashes? by revdiablo

---

Someone asks how to do Y when they really want to do X. They ask how to do Y because they believe it is the best way to accomplish X. People trying to help go through many iterations of "try this", followed by "that won't work because of". That is, depending on the circumstances, other solutions may be the way to go.

— from Re: Re: Re: Re: regex to validate e-mail addresses and phone numbers by Limbic~Region

---

To answer question Y, without understanding larger problem (the context) X, will most likely *not* help them entirely with X.

— from <m18zt5muq9.fsf_-_@halfdome.holdit.com> by merlyn. Message can be found here.

---

A.k.a. "premature closure": the questioner wanted to solve some not very clearly stated X, they concluded that Y was a component of a solution, and now they're asking how to implement Y.

— from <Pine.GHP.4.21.0009061210570.8800-100000@hpplus03.cern.ch> by Alan J. Flavell

---

The XY problem is when you need to do X, and you think you can use Y to do X, so you ask about how to do Y, when what you really should do is state what your X problem is. There may be a Z solution that is even better than Y, but nobody can suggest it if X is never mentioned.

— from <slrn89um8j.5g9.tadmc@magna.metronet.com> by Tad McClellan

---

When people come [in here] asking how to do something stupid, I'm never quite sure what to do. I can just answer the question as asked, figuring that it's not my problem to tell people that they're being stupid. . . . But if I do that, people might jump on me for being a smart aleck, which has happened at times. ("Come on, help the poor guy out; if you know what he really need why don't you just give it to him?")
. . .
On the other hand, I could try to answer on a different level, present a better solution, and maybe slap a little education on 'em. That's nice when it works, but if it doesn't it's really sad to see your hard work and good advice ignored. Also, people tend to jump on you for not answering the question. ("Who are you to be telling this guy what he should be doing? Just answer the question.")
. . .
I guess there's room for both kinds of answer. Or maybe there isn't room for either kind.

— from <6lnb70$lct$1@monet.op.net> by MJD

MJD also posted an earlier diatribe on the subject, which has become a USENET classic: Re: I never get answers to questions in newsgroups.
It has been updated several times over the years; one version appears to have been the origin of the famous "Retardo!" quote.
His latest version is on his website: TIP: How to post good questions.

---

Too bad that the more general problem, X, is often considered off topic for this forum. Y has more of a chance to look like a Perl problem.

— from <bkocrs0rtjcuh95l96pdbatffbpu1plk4h@4ax.com> by bart

---

Men.

— by me, just now.

---

See Also

ESR's How to ask questions the smart way includes a Q: How can I use X to do Y?

In XYZ Questions, chromatic suggests that people try to answer both the X and the Y.

On Answering Questions is an excellent article by merlyn, where he quotes this message he posted on the unix-porting mailing list.

StackExchange has a page with a rather exhaustive treatment of the topic.

You know that strategy classes are easy to make and use. For example, you want to encapsulate your output formats in such a way that you can select the appropriate wrapper without affecting client code.

package Output_Strategy::HTML;
package Output_Strategy::CSV;

. . .

my $output_strategy = $opt{'html'}
  ? 'Output_Strategy::HTML'
  : 'Output_Strategy::CSV';

$output_strategy->preamble;
$output_strategy->render(@data);
$output_strategy->postamble;
# whatever
[download]

Now, this technique makes the following assumption (or, more accurately, imposes the following constraint): the entity to be strategized (output format, in the example above) is a stand-alone class or object. It could even be a delegate within another object.

But, suppose you are extending the capabilities of a class via inheritance rather than delegation/composition. How can you apply a strategy pattern in the inheritance?

My answer is quite simple, and, again, it exploits Perl's highly dynamic nature. It involves modifying the inheritance tree at run time. And to make it more flexible, I insert a level of indirection in the inheritance chain, so that the "end user" classes don't need to be affected.

Suppose we have a set of classes (e.g. Foo) that want to "mix in" the methods of our output interface. Let Foo and Bar inherit from Output_Strategy; and let Output_Strategy inherit — based on a run-time setting — from one of the actual strategy classes.

package Foo;
use base 'Output_Strategy'; # this is a 'strategy handle class'

. . .

# set the inheritance path at run time:
@Output_Strategy::ISA = ( $opt{'html'}
  ? 'Output_Strategy::HTML'
  : 'Output_Strategy::CSV' );
[download]

Note: I'm not saying this is better than delegation. I just think it's a potentially interesting alternative technique.

Glossary:

• Handle (sense 3): an indirect, or two-level, reference
• Strategy pattern
• Composition
• Delegation
• Facade pattern aka Wrapper
• Mix-ins

Update: I have referred to this "double-indirection" of classes as "handles" because the technique reminded me of the double-indirection of memory management, used in some operating systems. In Windows, these are called handles, and it makes sense; it's the same idea as file handles, and in fact (IIUC), Windows handles are an abstraction over all of the system resources a process can access. Wikipedia has an article on Handles, and it says a handle is "an abstract reference to a resource". But that doesn't really describe what I'm doing here, which is more accurately called a bridge. Wikipedia's article on Opaque pointers helpfully/confusingly refers to both handles and the Bridge pattern. :-)

I was pondering the question "Why do some people think they enjoy programming in Java?" Software engineers who use Java will tell you that they revel in the expressive power of that language, which enables their craft and creativity to flourish.

But wait! Java isn't like that, because Perl is like that... and they can't both be. Right? I think they can, because it happens at a different level.

In Perl, we feel liberated by the fact that (for example) Perl already has an auto-sizing array type built in; we don't have to invent that wheel yet again. Perl has approximately 3.2 jillion distinct features built in. Perl programmers can "focus on the application itself", on its high-level structures and algorithms, and not worry about, for example, how to iterate over a list of heterogeneous objects.

But in Java (and most other languages) the programmer needs to think not only about those higher-level issues, but also about the lower-level structures and algorithms, and to implement them — or at least to choose the desired ones from libraries of such things. This is why it takes 5 days and 1000 lines of code to write a "hello, world" CGI in Java. Or whatever.

So, in many critical respects, Perl is the language of Only One Way. There is only one way to implement a sequence: an array. There is only one way to implement an associative array: a hash. There is only one way to search for patterns in a string (setting aside the trivial index function). And so on. Of course, if you really wanted to, you could do any of these things another way. You could choose to ignore the power of the constructs perl gives you for free. You may decide that a singly-linked list is appropriate for your application, or maybe a b-tree. People do this with some regularity.

For example, there is only one way to do classes in Perl. That is, there is one intrinsic way, which uses namespaces, @ISA, the special semantics of the -> operator, and so on. But some folks have felt this style too limiting, or not limiting enough, or too arcane, or just simply not OO enough. Thus we now have Moose, and the plethora of modules in the Class:: namespace, as well as basic techniques such as "inside-out objects", message-based object protocols, etc. etc. Java, of course, gives you no choice at all about how to do OO.

So, while Perl goes to great lengths to permit more than one approach to any problem, there are certain questions for which Perl hands you a "no-brainer" answer on a silver platter. In these cases, we're pretty close to Only One Way.

Previous node on similar topic: TOOWTDI (There's Only One Way To Do It)