Linked by Thom Holwerda on Fri 10th Sep 2010 14:59 UTC
General Development Python programmers shouldn't get too smug. While many people agree that Python is designed in a way that makes it a highly readable language, there can still be problems with legacy, untested Python code too. Porting legacy Perl to Python can be a daunting task. In this article, learn some of the theory behind dealing with legacy code, including what not to do.
Thread beginning with comment 440347
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Why would I want to do it?
by sreque on Fri 10th Sep 2010 17:54 UTC in reply to "Why would I want to do it?"
sreque
Member since:
2010-09-10

Here's a few areas where Python excels over out-of-the-box Perl:

function calling conventions
error handling of built-in data types, functions, and language features
exceptions and stacktraces
metaprogramming
object system
variety of implementations
grammar and overall language complexity (affects tool creation)
concept of iterators and for comprehensions
complexity of references
handling of built-in versus user-created data types
threading
package/module system
overall consistency of features
execution model
file handling (Typeglobs, variable references, and OO wrappers! Oh my!)

Many of Perl's weaknesses as listed above can be fixed to at least a certain extent by downloading a bunch of CPAN modules that basically modify the language (see the perl5i CPAN module for a good example). However, why bother going through such a huge effort to fix Perl when you can just use a better designed language? Plus, you have to get your team to agree to use all of those modules, and in my experience people who use Perl are quite comfortable with the default language. With Python, everyone starts out on a much higher and more stable ground.

Edited 2010-09-10 18:01 UTC

Reply Parent Score: 3

sigzero Member since:
2006-01-03

You are really trying to say that Pythons package/module system excels over Perl? Really?

Most of those are pure FUD.

Reply Parent Score: 4

sreque Member since:
2010-09-10

Yes, because a flat namespace, an overly complex system for importing and exporting of symbols, stapled-on OO, and requiring you to put a non-zero-returning statement at the end of each file makes for an excellent package system.

It's only FUD if you're biased for Perl! For the rest of us, it's the truth.

Edited 2010-09-15 16:29 UTC

Reply Parent Score: 1

google_ninja Member since:
2006-02-05

I would _highly_ recommend learning a language before making sweeping statements like this. You really make yourself look like a moron when most of what you say is just flat out wrong. (perl actually does almost all of those things). That being said, I sort of wanted to comment on this

Many of Perl's weaknesses as listed above can be fixed to at least a certain extent by downloading a bunch of CPAN modules that basically modify the language (see the perl5i CPAN module for a good example).


A powerful language is one that can redefine itself to meet its needs. If you have that, you can just release a small core and let libraries define all the fancy language features people like. The neat thing about this is that it lets the language move way faster, since cool language features are often created by people who have a good idea, but aren't interested in hacking on c based VMs. There is a time and a place for that sort of thing, and when you are used to it, languages that don't let you redefine themselves start feeling cumbersome and irritating when that time comes, and you are forced to implement something that could have been done in a much more elegant fashion.

Now, all of that is my opinion, as someone who absolutely loves languages like perl, and ruby, and LISP. I know that not everyone thinks the same way, but a great many really smart people do. Hopefully this is a bit of a window into how the "other side of the fence" sees this sort of thing.

Reply Parent Score: 2

vivainio Member since:
2008-12-26

If you have that, you can just release a small core and let libraries define all the fancy language features people like.


I've heard many things about Perl, but never heard it referred to as "small". Every time someone had an idea, they were sure to add it to the core language.

Python is small. It doesn't even support regular expressions in the core language (which is a design flaw both perl and ruby happily make), you'll use the standard library instead.

Reply Parent Score: 2

asdf Member since:
2009-09-23

A powerful language is one that can redefine itself to meet its needs.


I just can't stand that statement. Sure, everyone redefines the language into meeting one's own silly imagined requirements. Powerful for each silly isolated programmer, massive failure as a communication tool among peer programmers. Yeah, go! perl and c++!

Reply Parent Score: 1

sreque Member since:
2010-09-10

I know more about Perl than any other developer I've met, and I can hold my own against arguments from the likes of you just fine.

Also, there is a difference between languages like Lisp that give you a small core and let you easily build your own sub-language with macros, and a language like Perl where people have hackily built modules to cover up for past design mistakes. Perl's source transformer system, for instance, is inferior to anything the Lisp world has to offer. At the same time I've also heard Perl 6 improves significantly in this regard, but I won't hold my breath until Perl 6 is out and accepted by the community. Lastly, other scripting languages like Ruby also let you access and transform the AST, but this feature is not used nearly as much in these languages because, frankly, they don't need it nearly as badly as Perl does.

Anything else you'd like to try in defense of Perl? I promise you it is much easier to attack Perl than defend it!

Reply Parent Score: 1

pshangov Member since:
2010-09-11

Many of Perl's weaknesses as listed above can be fixed to at least a certain extent by downloading a bunch of CPAN modules that basically modify the language


Modern Perl is ALL about CPAN. The core language distribution has been purposefully kept minimal and it is on CPAN where evolution takes place. In a similar vein key libraries (such as Catalyst) are purposefully kept minimal, with most goodies available as individual modules to be installed separately. A good Perl programmer is nowadays a programmer who knows her way around CPAN. This is an approach that is indeed harder at the start, but immensely more powerful in the long run.

Reply Parent Score: 2

Delgarde Member since:
2008-08-19

A good Perl programmer is nowadays a programmer who knows her way around CPAN. This is an approach that is indeed harder at the start, but immensely more powerful in the long run.


Yes and no. Having that resource is great for developers, but a *massive* pain for distribution. It's no good having a nice 100-line perl script that requires a dozen CPAN modules to be installed before you can use it.

Especially when you then try to do so on some random UNIX platform, and find the module doesn't compile on that platform because of some subtle difference between Linux and (e.g) HP-UX.

Reply Parent Score: 2

sorpigal Member since:
2005-11-02

This is the truth. Perl without CPAN is like C with just the standard library. You can rebuild everything yourself, but why would you do that when you can go grab a .so?

Reply Parent Score: 2

modmans2ndcoming Member since:
2005-11-09

you forgot "trim" functions

Reply Parent Score: 2

sorpigal Member since:
2005-11-02

All of these either exist in Perl, too, or don't aid the point: Maintainability.

Iterators and for comprehension are sweet sauce, sure, but once I have a stack of perl code that doesn't use them and works, what exactly is my motivation for porting to python?

A variety of implementations is nice, but does it *really matter* that I there's "only" one source base for perl? I mean, it's open source! It's not like there's a portability problem when the perl interpreter is concerned, it runs everywhere.

I could go on and on.

If you're *starting a new project* then some of your arguments are useful, but we're maintaining code in this article.

Although, in fact, even when starting a new project I would, personally, be prepared to defend Perl's advantages. I've seen far, far more cases, for example, where an interpreter point upgrade breaks python programs. But we

Reply Parent Score: 2