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.
> 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.
> 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.