Can Perl Be Smalltalk

I've been writing Perl for about seven years now, and I've come to know it very well, and love it very deeply. My question is, are there any programmers out there who have done Lisp and Perl or Smalltalk and Perl both, deeply enough to understand both.

Particularly, I'm curious how people would compare Perl and Smalltalk. From what I've gleaned from discussions here about Smalltalk, this is my best stab at a comparison of the two languages.

Similar features:

dynamic code generation is easy
Easy things are easy, hard things are possible. Smalltalk does this with a small language and a huge library. Perl does this with a huge language and a reasonably big library, especially if you count CPAN.
AUTOLOAD/#doesNotUnderstand: (see down below)

Bad things about Perl:

language is much wider than necessary to do smalltalk style oo development. You must consciously select a SaneSubset of Perl in order to make the code clean. Picking the SaneSubset of Perl is difficult without lots of experience.
- I don't think this is a winning statement to make. The Perl philosophy is ThereIsMoreThanOneWayToDoIt. That naturally means it's more powerful than Smalltalk. If you want to purposely restrict your options, use another language like Python or Java. -- SunirShah
- Just because ThereIsMoreThanOneWayToDoIt doesn't mean that YouShouldDoItEveryWhichWay. -- JeffBay

Bad things about Smalltalk:

See: IfSmalltalkIsSoGoodWhyDoesNobodyUseIt

Things that were up top:

Can't parse it with a program, makes it difficult to create a refactoring source browser.

Actually, you don't need to write your own programs to parse it, because of the B:: modules that let you have access to the opcorn the parser made. Yes, though, a refactoring browser for Perl is tricky. At least one is in the works, headed by Michael Schwern.

In Perl, classes are so dynamically loaded that you can't tell statically or by testing if you have the dependencies for a class correctly specified.

In the normal case, you pull in dependencies via "use" at compile-time. Under what circumstances have Perl dependencies been troublesome?

The problem arises when you are writing tests. The test class frequently needs methods from the class-under-test's "used" classes. Thus the test class has to use those classes. Once the test class "uses" the relied upon class, there is no way within the test program to test that the class-under-test has correctly "used" that relied upon class. -- JeffBay

Perl allows you to intercept "use" calls, and it's trivial to test them safely that way. See PerlTestingADevelopersNotebook.

With the proper SaneSubset of Perl, it seemed like we were building code that had the least duplication in it I had ever seen in a system before. In particular, AUTOLOAD in a few judicious places helped significantly reduce the code size because instead of something like this:

$foosblah = $foo->get('blah');
$foosblat = $foo->get('blat');

We could just say something like:

$foosblah = $foo->blah;
$foosblat = $foo->blat;

AUTOLOAD is a method that every class can respond to. Anytime a method is called that the class doesn't have a method for, AUTOLOAD is called with a special variable set to the name of the method. (For you Smalltalkers, AUTOLOAD is almost identical in behavior to #doesNotUnderstand:.)

As a prime example, we had a class called "TableRow?" which was an abstract base class that implemented an object backed by a single row of a table. We had a method for getting and setting the values of a particular column, like this:

  sub get($column_name)

and

  sub set($column_name, $new_value)

We added an AUTOLOAD routine to the base class such that if the class didn't have a method by a given name, it would next check to see if there was a column by the same name, and stand in for the subroutine. In addition, any method that started with "set_" would act as a set for the given column. Like so:

  if ($user->created_on > $one_month_ago) { $user->set_activated(1); }

In the normal style, this would be:

  if ($user->get('created_on') > $one_month_ago) { $user->set('activated', 1); }

It isn't a huge difference for a single line, but it adds up when you have thousands of lines of code that deal with gets and sets on database rows.

There are also tricks you can use for installing a real subroutine into the classes method lookup table such that subsequent calls to that subroutine will skip the AUTOLOAD. Allows for mondo dynamic code generation, but as with all things, especially Perlish, use it only for good.

If you are Perl person interested in Smalltalk, or you're a Smalltalk person interested in Perl, then I would consider looking at PythonLanguage too. Python is influenced by both of these languages. Python also has mechanisms for dynamically creating methods and attributes. -- SteveHowell

Also: RubyLanguage, which seems to be 50% Perl, 50% Smalltalk.

If the question is just, "Can Perl be Smalltalk?" the answer is probably no. Smalltalkers tend to take pride in the simplicity and orthogonality of their language; Perl's TIMTOWTDI philosophy is pretty much the exact opposite of that. Also, there's more to Smalltalk than just the language - the environment is an integral part of it, which is very different from Perl's (and most other languages') use of plain text files. There are advantages and disadvantages to each approach, but you're not going to get Smalltalk's particular set of advantages in Perl. (You can't add anything to Perl to make it simple and orthogonal. ;) -- AdamSpitz

According to extremo Ron Jeffries, the other extremos are using Ruby over Perl/Python/etc... http://www.xprogramming.com/ then click on the Book Reviews IV link. -- DougPhilips

CategoryPerl