Eugene's statement was that Forth and Scheme both "[let] you define
application languages". Perl does as well, IMHO; for instance, the
standard Mailtools package provides, in effect, an embedded little
language for manipulating email messages (reading them in, tweaking
headers, sending them off), which allows you to write, say, a
rough-and-ready autoresponder script in about a dozen lines of code:
#! /usr/bin/perl -w
use Mail::Internet;
$mail = Mail::Internet->new([<>]); # Read message off stdin
$reply = $mail->reply(); # Construct reply
$sender = 'autoresponder@foo.org'; # Set 'From' and 'Sender' to alias,
$reply->replace (From => $sender, Sender => $sender); # not "nobody"
# Prepend canned response to body
unshift @{$reply->body}, map { "$_\n"} (split /\n/m, <<End_of_msg);
Thanks for sending the comments below; we'll look into it.
End_of_msg
$reply->smtpsend(); # Send it off.
Similar toolkits are available at CPAN (the Comprehensive Perl Archive
Network, for those who haven't heard of it) for everything from
opening and manipulating POP connections to drawing charts into GIFs.
I'm not sure I see how Scheme and Forth *require* you to build
toolkits like this; it's more common, but I suspect that's more a
matter of shared community aesthetics than anything else. You can
write bad code in any language, and there's a lot of bad code out
there, particularly since it was a hell of a lot harder to write good
code in Perl4. (The language features used to create the message
objects used by the code above were simply unavailable).
> I think Scheme and Forth are actually better than Perl at the
> application-language-defining thing; Jeff Bone's list of things you can
> do in a page or two of Scheme (some of which are things you can do in
> twenty lines or less of Forth, and some of which aren't) is one
> example. Writing the applicative-order Y-combinator in terms of
> anonymous Perl subs is what opened my eyes.
>
> It's mostly a matter of syntax, though; most of the nice stuff in
> Scheme (lexical scoping, closures, dynamically generated anonymous
> subs, gc, higher-order functions -- although no call/cc) is in Perl,
> it's just clumsier to use and/or more poorly implemented. The
> difference between Perl and Scheme is far smaller than the difference
> between C and Scheme or between C and Perl.
IIRC, a lot of otherwise complete Scheme implementations don't support
full-strength call/cc either. Also, Perl's text-manipulation features
are a godsend if you're doing anything that involves manipulating
text, and 'pack' and 'unpack' make it surprisingly tolerable to deal
with even binary data. If you're in those application domains, these
make up for a lot of Perl's quirks.
(And Python has quirks as well; although Python syntax is cleaner, it
still did not have real lexical variables last I looked...).
rst