The simplest parser begins with the simplest language design. A language that has a one token (or even two) look-ahead will always be easier to parse than a language that requires consuming long runs of tokens before you know what the run means. For example, suppose we had a language that looked like this:

action article target "\n"
action ::= "WALK" | "FEED" | "PLAY WITH"
target ::= "DOG" | "CAT" | "CANARY" | "FISH"
article ::= "A" | "THE"
[download]

Language samples would look like this:

  WALK THE DOG
  FEED THE CANARY
  PLAY WITH A FISH
[download]

and a parser (sans error detection) could be as simple as this:

use strict;
use warnings;

while (my $sLine = <DATA>) {

  my @aFields = split(/\s+/, $sLine);

  #the general case
  my $sAction = shift @aFields;
  my $sArticle = shift @aFields;
  my $sTarget = shift @aFields;

  #special cases - PLAY WITH has two tokens
  if ($sAction eq 'PLAY') {
    $sAction .= " $sArticle";  #$sArticle is 'WITH'
    $sArticle = $sTarget;      #$sTarget is an article
    $sTarget = shift @aFields; #target never got read
  }
  doSomethingWithStatement($sAction, $sArticle, $sTarget);
}

sub doSomethingWithStatement {
  my ($sAction, $sArticle, $sTarget) = @_;
  print "action=<$sAction> article=<$sArticle> target=<$sTarget>\n";
}

__DATA__
WALK THE DOG
FEED THE FISH
PLAY WITH A CANARY
[download]

Of course, for production purposes you would probably want to do some error checking. Also you might want to make certain combinations of verbs and targets illegal. For example, it doesn't make much sense to "WALK A FISH". And if you really want to get fancy you can explore the wonderful world of lexers. But hopefully this will illustrate the basic idea.

I wanted to provide you with a link to an easy to understand non-jargon filled article on designing an easy to parse language, but I'm having little luck googling for that. Perhaps another Monk with better search term fu can help you with that.

Best, beth