I'm a big fan of Perl, have done nearly all my Web programming in that language, and have attended all three annual Perl conferences. So it was a real change of pace to attend IPC8, the Eighth International Python Conference. And, I'll admit, it was daunting to be asked to give the keynote talk at the conference's very popular Zope track. (For more on the Python-based Zope web application server, see these BYTE.com articles: August 23, 1999, October 25, 1999, January 24th, 2000.) Although my experience with both Python and Zope is far more limited than my experience with Perl, I've seen enough now to draw some interesting parallels and distinctions between the two languages and their respective cultures. Here, then, are some observations about these two wildly successful open-source scripting languages.

Perl Is Bigger, But Python Is Growing Faster. The first Perl conference in 1997 drew about 1000 attendees; it's grown modestly since then. By contrast the Python conference -- though it drew only about 250 this year -- nearly doubled last year's attendance. If the two languages were politicians, Perl would be the well-known incumbent, and Python the challenger with momentum. Among the signs of Python's growing strength was the announcement, at IPC8, that ActiveState -- the company that's made its name supporting Win32 Perl and selling commercial tools based on it -- is moving into the Python space as well.

The Two Languages Are Isomorphic In Most Respects. From 50,000 feet, Perl and Python are strikingly similar. Both are open-source products that can be built on Win32 and a wide variety of UNIX platforms. Both can be used in a purely procedural manner, or in an object-oriented way. Both manage memory automatically. Both support rich, dynamic data structures such as lists and associative arrays. Both come with extensive libraries of scripted and compiled extension modules that work with databases, graphics, networking, directory services, XML, and much more. Both are rooted in strong communities.

Although Both Scripting Languages Can Be Used In Object-Oriented Ways, Python Is More Deeply Object-Oriented. For Perl, OOP was a bolt-on, not a built-in. Objects didn't arrive until the fifth incarnation of Perl. By contrast, OOP was built in to Python, not bolted on. That said, I'm not inclined to make as much of this point as some people do. Perl's object-orientation, though it has more of a blue-collar feel to it than Python's, can certainly get the job done. What may matter more is what's under the hood. Although to the scripter both Perl and Python can seem object-oriented, Perl in the guts of its interpreter is not object-oriented whereas Python is. Why does this matter? I can't speak from experience, because I've only written trivial Perl extension modules and never written one for Python, but those in the know tell me that Python's internal object-orientation vastly simplifies the chore of mating Python to other components which are, themselves, built with object-oriented technology. This may be one reason why, although there are more extension modules for Perl, a number of the newest or most interesting modules (e.g. those supporting WebDAV or wxWindows) are supported first, or best, on Python. Perl Celebrates The Notion That "There's More Than One Way To Do It" Whereas Python Celebrates Consistency And Uniformity. The single most surprising aspect of Python, from the perspective of C or Java or Perl or almost any other language, is that whitespace counts. Too many or too few tabs or spaces isn't just a formatting glitch that makes your script look less attractive on the page. Rather, inconsistent indentation is a syntax error that stops your script dead in its tracks. If Python's your first language, this may make perfect sense. If you come from C or Java or Perl it will seem very weird at first. I'm told most people adjust easily and quickly, and that's been true for me, probably because I've always been scrupulous about indentation anyway. Just because Perl's bytecode compiler doesn't care how statements line up doesn't mean that I don't. I rely on indentation to discern block structure. The Python way, I now realize, eliminates a whole class of errors that arise when a mis-indented program makes you mis-perceive its true block structure. In Python, what you see is what you get, and there are almost no choices about how you format your code. Python's inventor, Guido van Rossum, did not capriciously deny Python programmers the freedom to format code in different ways. He chose to do so because he believes it helps programmers read and understand not only their own code, but also -- and crucially -- code written by other programmers. And indeed, the Python hackers to whom I spoke at the conference all agreed strongly with this view. They cherish Python's regular, uncluttered, and highly readable appearance. "Life's better without braces," was the motto at this year's conference.

Perl has a rather different motto: "There's More Than One Way To Do It" (TIMTOWTDI, pronounced "TimToady"). Perl can be written lots of different ways. You can choose to observe rules like those Python enforces, but you don't have to. And this freedom extends beyond just formatting. In Perl there are, for example, several ways to reference an element of a list, or write the set of key/value pairs that define a hashtable.

It's important to understand that Larry Wall is no more capricious in his desire to encourage this freedom than is Guido van Rossum in his desire to regulate it. Trained as a linguist, Larry Wall built Perl on the model of English. "Perl is a mess," he says, "and that's good because the problem space is also a mess." Wall believes that people think about things in different ways, that natural languages accommodate many mindsets, and that programming languages should too.

While I continue to think that Larry Wall is right about this, there's no simple answer here, and with only months of Python experience to stack up against my years of Perl experience, I can't really make a fair judgement. I think it's good, though, that Python challenges me to examine some of my deeply-rooted Perl assumptions. There's nothing worse than an unexamined assumption! Python Is Designed To Be A Good First Language For A Beginning Programmer, Whereas Perl Is Most Useful To Programmers Familiar With C, Sed Or Awk, And UNIX Command Idioms.At the conference, Guido van Rossum spoke about a project called Computer Programming for Everybody. He aims to craft a subset of Python, and a set of educational materials related to it, so that Python can be to the next generation of programmers what Pascal was to mine: the language that's used to teach first-time programmers. As much as I admire Perl, I would never recommend it to a beginner. Perl should be your third or fourth language, not your first. Python, even in its current form, would be a reasonable first choice. The path from the simplest script, through structured programming, on to objects, and thence to large systems, is quite smooth.

In fairness to Perl, I was productive in the language almost immediately, and long before I mastered things like references, objects, and power tools like Perl's amazing map function, which applies a function to every element of a list. (Yes, in case you're wondering, Python has a map function too.) But then, I came to Perl after Pascal, Lisp, C, Ada, C++, and a few other languages. It's hard for me to imagine how Perl would have appeared to me as a first language, but my sense is that Python would have been an easier place to start. Certainly the Python community, as a whole, seems to take a genuine, life-cycle-oriented interest in the development of a programmer.

Perl Is more Powerful And More Mature In Some Ways. Despite Python's growing strength and popularity, Perl remains the gold standard for scripting in many respects. For regular-expression-based text-processing, I'll take Perl any day, even though Python in recent years has gotten faster at this, and has switched to a Perl-5-like regex syntax.

The Python community hasn't yet matched Perl's CPAN (Comprehensive Perl Archive Network), a masterfully organized compendium of Perl extension modules. Likewise, Python has yet to match Perl's standard methods for building modules and packaging them for distribution. A new Python initiative called Distutils is attacking this problem, and it's inspired by Perl's MakeMaker, a module that enables Perl programmers to build standard modules for distribution on CPAN.

Perl's database support is broader than Python's. Championed by Tim Bunce, Perl's DBI/DBD (database interface, database driver) mechanism has been a strong standard for years, and as a result, Perl programmers enjoy rich support for many different SQL databases. Python has a similar mechanism, but people in the Python community tell me that Python's DBI doesn't cover the wide swath that Perl's DBI does. Perl Lacks A Killer App; Zope Is Python's Killer App. Perl's been aptly called "the duct tape of the Internet" and in that sense, the Internet is Perl's killer app. Countless Web sites depend on Perl for the production of HTML, for the management of user databases, for the monitoring of mission-critical servers, and a thousand other chores. And yet...there's nothing in Perl space like Zope. By that I mean, there's no killer app that leads people to Perl in the same way that Zope leads people to Python. It's clear that Zope was one of the main reasons that this year's Python conference was twice the size of last year's. People who otherwise had no particular reason to want to learn Python (like me) found their way to the language not for its intrinsic properties, but because it's the engine of Zope.

What's magical about Zope is that it looks, to users, like a content-management system with a simple Web interface that anybody can use. A non-programmer can manage a simple website, using Zope, with little training. Thanks to Zope's powerful object-oriented framework, it's easy to build such a site in an efficient and economical way, inheriting (or, in Zope-speak, acquiring) common elements from ancestral objects. Thanks to Zope's built-in object database, it's easy to restructure the site -- for example, by cutting a subtree of objects from one location and pasting it into another.

Out of the box, in other words, Zope is a useful Web content manager for nonprogrammers. And then, when the site needs to grow more sophisticated, the afterburners kick in. There's a tag language called DTML (Document Template Markup Language) which, like Cold Fusion Markup Language or Java Server Pages or Active Server Pages, mixes HTML templates with programming instructions that can populate these templates with data drawn from SQL stores or Zope's own object database. When this mid-level programming environment runs out of gas, you can drop down to Python -- Zope's native implementation language -- to write powerful extensions that communicate intimately with Zope's internal machinery.

It's a great model. Although Python zealots tend to attribute the success of Zope to the qualities of Python, I'm not so sure about that. As I've said, Perl and Python really aren't too different from 50,000 feet. So how about it, Perl folks? Python has quite sensibly borrowed lots of great ideas from Perl. Here's a great idea that Perl ought to be borrowing from Python.

Jon Udell (http://udell.roninhouse.com/) was Byte magazine's executive editor for new media, the architect of the original www.byte.com, and author of Byte's Web Project column. He's now an independent Web/Internet consultant, and is the author of Practical Internet Groupware, from O'Reilly and Associates. His recent Byte.com columns are archived at http://www.byte.com/index/threads. Dell Computer has joined RosettaNet, an IT industry consortium, and has been elected to its Information Technology Manager Board. Executives at this Round Rock, Texas, computer maker said they expect RosettaNet standards to assist supply-chain communications within DellWare, which resells third-party products. RosettaNet is a partner-to-partner e-business initiative using XML-based interface processes.

www.cmpnet.com The Technology Network

Copyright 1998 CMP Media Inc.