[kqr]

This is because it was invented to be possible to use as an interactive shell. When you're working with an interactive shell, you want its language to be (at least somewhat) optimised for writeability, which by necessity means a lack of optimisation for readability. (Explicitness and some level of redundancy aid readability but hurt writeability.)

[dalke]

I believe Perl was meant as a replacement for shell scripts, as well as sed and awk script. It wasn't designed as a interactive shell. For example, the original perl man page says (quoting from http://history.perl.org/PerlTimeline.html ):

        Perl is a interpreted language optimized for scanning  arbi-
     	trary  text  files,  extracting  information from those text
     	files, and printing reports based on that information.  It's
     	also  a good language for many system management tasks.  The
     	language is intended to be practical  (easy  to  use,  effi-
     	cient,  complete)  rather  than  beautiful  (tiny,  elegant,
     	minimal).  It combines (in  the  author's  opinion,  anyway)
     	some  of the best features of C, sed, awk, and sh, so people
     	familiar with those languages should have little  difficulty
     	with  it.

The closest that perl had to an interactive shell was with the "-d" debugger. See for example this synopsis from 2007 at http://archive.oreilly.com/pub/post/writing_a_modern_perl_re... :

> One area in which Perl falls behind other languages is in its lack of a usable Read-Evaluate-Print-Loop. (perl -de 0 just isn't enough for me.) I've used Ruby's irb and a handful of Python shells, and I'm starting to become a fan of ghci, but I fall back on perl -e far too often for my sanity.

An interactive shell should, in my opinion, support more than a REPL. It should also implement job control, like suspending a job or starting jobs in the background. Perl definitely was not invented for that purpose.