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.
Weak article. I was hoping for some actual content to describe the best way to actually do the port.
Instead there are just two recommendations:
Yes, port the old code to new code.
Yes, test the new code.
Uhm… Ok. Those are two things you really do want to do when porting old code to new code. Nothing really specific to Perl or python. Nothing very insightful.
Feel free to chime in where he left off.
I, for one, was thinking of the possibilities that Parrot the runtime that will power Perl 6 could offer. There was an effort at one time to also make Python run on parrot, but I think that effort has been stalled to focus on completing perl 6.
With a common jvm, you could potentially call perl from python: allowing you to gradually replace the perl.
Generally I like the IBM articles. This one is a little lacking in meat.
I don’t get it. Why would I want to do this?
Perl meanwhile became pretty nice again with all these Modern Perl stuff. I dropped Python and Ruby again.
I can see only two language that could compete with it in future. Falcon and Perl 6.
However, bot of them and especially the later one are still to knew.
Perl isn’t perfect, but they had plenty of time to fix everything and when it comes to maturity the other simply can’t compete. Yeah, OO has been a big problem, but Moose has been there for a while now, if you don’t like the old way.
I just can’t see an area where for example Python would be better. I mean I’ve tried it and the only things I can see is that it uses indention and giving me a smaller number of “ways to do it”. If I wanted to do it in that way I would simply do it that way. Readability? It’s not different from any other programming language. Either you write easy to understand, readable code or hard to understand non-readable code. Everyone of us has seen good and bad Python code I guess.
Yeah, it may be off topic, but I always wondered about that. I mean there have already been new programming languages and it is good to know more than one, but why would I do that switch?
Does Perl simply have an image problem or do I miss something?
Yeah, readability might be worth it, IMHO.
You can write elegant, easy to read code in perl, though that is the exception more than the rule. With Python readable code is re rule, rather than the exception.
Perl’s big, huge advantage, is that its installed on just about every *nix server.
We managed to compile Python 2.6 on an AIX 5.2 server without incident. Perl does have an advantage here, but it’s only really an advantage when you are distributing scripts to customers that have no interest in installing Python on their servers, and I believe this case is very rare.
Well, I occasionally help out friends maintain their websites. Which means I log into random shared hosting boxes, whos OS and software installed I can’t control. Often times, there are batch operations that I could fix easily with a script. I can’t count on python always being there, but perl is always there.
I know that everything is about tastes and likes, but I never did find Python code readable (Perl neither). I actually find C++/Java/C# and that family far more readable.
I can read both just fine, so I’m not sure I could call one more readable than another.
Its like asking me which word is easier to read “this” or “that”. One one hand “this” has more unique letters than “that”, but the letter ‘i’ is a simpler shape and less varied in representation than ‘a’ that you’ll find in “that”. On the other hand “i” can be confused with a lower case “l” as well as the number “1” in many cases.
its funny, longCamelCasedFunctionNamesMakeMyEyesBleed while wide_casing_almost_seems_like_english.
actually my first concern is the indentation as part of the language semantics. I was used to do something like that when I was programming some small things in Fortran (no, I am not as old as it seems, but my Numerical Analysis teacher wanted us to learn it) and nop, I prefer some more liberal syntax.
Actually, I agree with the significant whitespace thing. Part of it I like to stick to 2 space indenting, which is nowhere near enough for a whitepace language. The other thing is the class of bugs that bad indentation brings is just horrible to debug.
For me it’s the opposite, I prefer camelCase over wide_case, but I find the Lisp dashed-case convention the best of all. Too bad no non-Lisp language (that I know of) allows the dash in identifiers (for good reason, it would lead to loads of ambiguity in languages with actual syntax).
Totally agreed on the dashes. Other then lisp, (and file names) the only place I ever get a chance to use it html and xml.
Problem is, a language that allows “-” in variable naming can’t do the most basic mathematics who need this minus sign, except by bringing a very exotic syntax like Lisp’s
Myself, I think that the camel case vs underscore argument is highly a matter of taste. In my code, type names use camel case and variable names use underscores, because I like to differentiate those at first sight (especially when I dive in some code left alone for some months) and a starting capital is not enough for me
.
You can support a-long-variable-name easily if you require spaces around the subtraction operator (which many people put there anyway, for readability reasons). Dylan did this, and I think perl six is doing something like this, too.
Right. I personally think this gets a bit too intrusive in the coding style area, but there is room for everyone’s taste in the programming language world, and anyway you indeed proved that this is doable
Edited 2010-09-11 17:09 UTC
that is why postfix evaluation rocks!
Well, I’ve seen a language entirely based on postfix notation : SysRPL, used to code fast applications on HP calculators.
My experience was that it was horrible, after years of Pascal, Python, and C(++), to even try to understand it. One seem to be able to get comfortable with it in the long run, but I couldn’t get that far. It just looked too much like a glorified rebranding of Assembly with its stack-based way of thinking…
Edited 2010-09-12 14:10 UTC
I think most newer languages do it that way, and I agree, thats how I roll too
wrt it being a matter of taste, I slightly disagree. Camel case doesn’t scale up as well, passed about three words it gets very hard to read. Wide casing doesn’t have that problem, but it means additional characters. You could say that you shouldn’t really be going passed 3 words anyways in variable or function names, but I find there are times when inspiration totally fails me, and I end up writing a five word function because I can’t think of a more succinct way to write it.
In a world where everything could be expressed clearly in two words or less, I think camel case would make more sense. But especially when you take into account that its main bastion of use is in java, the land of enterprisey code like AbstractFoobarFactoryAdapters, I have learned to really downright hate it.
give me underscores any day of the week.
I have no problem reading any code put in front of me (well… getting out into Functional land can get a little crazy). The largest impediment to understanding what code is doing is how the developer writes it.
If you like to be super concise and you want every line to be as dense as possible, then you code is going to suck to read. If you like to spin off objects for every little operation in your code then your code is going to be hard to read. If you like to keep your variable names to 5 characters or less, then your code is going to be hard o read.
Edited 2010-09-12 13:13 UTC
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
You are really trying to say that Pythons package/module system excels over Perl? Really?
Most of those are pure FUD.
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
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
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.
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.
Python, small ? I can’t agree with this.
C, Pascal, and their object-oriented derivatives, are what I call small languages. They have a feature list close to the bare minimum, except for some things like bitfields and enums in C. Python, on the other hand, with its inclusion and high-level manipulation of lists, strings, tuples, and dictionaries, is not exactly what I would call a small language…
Edited 2010-09-12 14:15 UTC
I was talking about the benefits of a self modifying language, and was mostly thinking about lisp as I wrote that particular sentence
Don’t be so harsh on ruby! In ruby, the perl-like regular expression syntax is just syntactic sugar for using the Regexp class, which looks and feels like any other class in the language. In fact, if you wanted to, you could instantiate and use regular expression objects in ruby just like you would in python. No one usually does this, though, because the sed/awk/perl-like syntax for regular expressions is actually very convenient and helpful. I think this actually gives us the best of both worlds, because the language is still clean and consistent.
This stands in contrast to perl in many ways. For instance, in perl, if you want to assign a regexp to a variable you have to use the qr() syntax, which actually is much less convienent than the normal syntax for creating a regular expression. In ruby, you can just write something like:
re = /my_regular_expression/
which is just syntactic sugar for a properly string-escaped version of:
re = Regexp.new(“my_regular_expression”)
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++!
The more powerful something is, the bigger the hole you can dig yourself. When these things are done in the right way at the right times, they are invaluable. It takes skill, experience, and judgement.
I would agree with you if you are talking about crappy developers. Crappy developers can do much worse things when you have the ability to add or redefine language features.
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!
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.
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.
Yeah, I’ve had to rewrite a few scripts to compensate for missing cpan modules.
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?
you forgot “trim” functions
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
Funny that, cuz I can’t see any areas where Perl would be better.
Perl tends to encourage unreadable code, what with all the regex going on.
But hey, if you liker Perl go ahead and use it.
uhh… regex encourages poor readability? What planet are you from? Apparently one that does not see the use of a regular expression.
As it has been said before, it’s matter of taste, but do you really think that a long multiline if-then-elseif-elseif-godknowswhat-else block is more readable than a compact regex?
If nothing else, with the regexes you can use all those saved lines for a comment in plain English (or whatever if your native human language)
Perl isn’t for everyone. Some people never feel comfortable with Perl. It is quite different from other languages. I am one of those people. Couple of years ago I’ve replaced parts of old Majordomo 1.9x MLM with my own Perl code, and it worked, but I don’t think I’ve really learned the language….
In fact, I think that people should not try to use Perl code if they are not confident in their Perl skills. It is better for them to write their own modules from scratch and stay away from Perl completely.
Python is much more, well, mainstream, easier to learn, and, majority of people would say that the code is easier to maintain.
how is python more mainstream than perl?
I’ve used the phrase “well, mainstream”, so you don’t have to understand it literally. What I meant is that syntax looks more like some other popular languages, like Java, JavaScript or C#.
I am aware that there is, probably, more Perl code than Python code out there.
That’s a funny thing to say, given that Perl has a loosely C-style syntax like Java, Javascript, and C# – it uses braces, and semicolons, favours symbols over keywords, etc.
Whereas Python has a completely different syntax – indenting rather than braces, keywords rather than symbols, etc. I love Python, but I’d certainly never say it’s syntax looks like any of the languages you describe…
Ok, maybe not syntax, but approach, logic. Java, Javascript or C# person will learn Python much faster than Perl.
Python syntax for objects and classes is more common with Java and C# or even PHP. Perl looks strange to Java and C# crowd. Python not so much, after you get used to mandatory indentation.
So in the end your argument comes down to “Perl OO is weird and different” — well no kidding, every Perl programmer in the world has concluded that. It’s why we have Moose and why that was one of the first things to be fixed in Perl 6. Perl OO sucks! Is there anything *else* that’s fundamentally wrong with Perl?
Before you say “Readability” I will say “It’s true,” but only to a point. Perl is much more permissive and lets you get yourself in to readability trouble more easily than many other languages, but with a little discipline readable code is not hard to write. Any decent perl monger will do it as a matter of course.
Now *Python*, there’s a readability nightmare! I’ve been programming for a decade and tried to muddle my way through a moderately complex Python program the other week to make one, small change (add an additional menu option which calls existing code, just for faster access). It took me four *hours* to get it working! For a one line change. And I *still* don’t understand what all of the magic going on was.
You *can* write readable python code, but I’ve seen more than a few programs that are terse and mystifying, relying on implicit behavior, and so on. Weird syntax doesn’t help, either.
For the record I know many languages from many families, just not Python.
I never really got the readability thing. I mean nobody says C is crap, because it isn’t readable. It is damn hard to read and I am not only speaking about obfuscated code like this:
https://secure.wikimedia.org/wikipedia/en/wiki/The_International_Obf…
I always had liked Perls approach to make the programming language more like a natural language.
Also compared to similar languages other than Python I never got that argument. Ruby for example never suffered from the hard to read argument.
Of course there is some yucky Perl code, but to me it looks like this has more to do with it’s age. Older code is harder to understand in most cases. The reason seems to be that the way people think about stuff changes over time. Today OO is overly hyped. Don’t get me wrong, I like OO. In fact I am very picky about what OO really should look like. For example I don’t really like the C++ style, but prefer Smalltalk, Objective-C and Ruby.
But be serious. OO is just one of many paradigms and there are always new approaches. So it is better to use external extensions like Moose to keep up with newer ways. Functional programming is an other big thing, but there isn’t really one right way. Perl is pretty good when it comes to adopt new things. Every time the Python, Ruby, Whatever guys come up with something new I can be sure I will soon be able to use this in Perl.
I really like Ruby and Python, but every time I work on a project I get frustrated, because they show me their borders. The fact that neither of them have as many modules as Perl is also very frustrating. OO is all about code reuse, but it sucks when I always have to reinvent everything.
Maybe a project like Parrot could change this. They also have pretty nice support for a bunch of languages and got pretty far. They’d just need some publicity. It would be really nice if all the programming language projects would work together instead of having to reimplement the same stuff all on their own. Especially stuff like porting the platform somewhere else. That lack of support for a platform really sucks. It’s also one of Perl strengths. It runs virtually everywhere. Again some advertisement, because I think this project is way too unknown.
http://parrot.org/
I guess I like the wrong stuff. Perl, Tcl, Smalltalk. All declared dead
Parrot will become increasingly known as perl6 becomes more complete. One way or another perl6 will be running on parrot and even though perl5 won’t stop there are just so many advantages to perl6 that once I can get anywhere like enough performance out of it I don’t see myself going back.
Parrot is like the open source answer to the CLR, though not advertised as such. It could be massively useful if its potential is reached.
What is wrong with you ? I’ve said that people accustomed to Java and C#, which are popular languages, feel more at home with Python. I have never thought that there is something wrong with Perl.
I’ve also said that people who are not familiar with Perl should rewrite Perl programs, instead of trying to incorporate them in their own projects. I’d say that it is quite sensible advice.
I thought this would be about writing a Perl interpreter in Python. Just for the sake of good, old-fashioned perversion.
Yeah, I thought that too. Though it’s nice (and amusing) to learn that it’s possible to instantiate a Perl interpreter within Python, I’ll remember that one…
It ought, by rights, to be possible to implement Perl using PyPy’s JIT generator – that would be a potentially valid reason for writing a Perl implementation in (R)Python…
http://codespeak.net/pypy/dist/pypy/doc/
Python > Perl. Though Perl 6 is a bit of a curiosity for me, i switched from Perl to python a long time ago and never looked back.
and of course, no python article would be complete without: http://xkcd.com/353/
Ok, here you go Perl: http://xkcd.com/208/
It’s funny, I hated perl till I learned LISP, which fundamentally changed the way I write code, and look at languages. After LISP, I had the chance to talk with an oldschool perl hacker, and found we were totally talking the same language.
Nowadays, I work with ruby (which is basically what you would get if LISP and perl had a lovechild), and it totally feels like coming home.
To each his own I guess
I know what ya mean, i really like LISP too.
so that being said, here’s the obligatory xkcd refferences.
http://xkcd.com/224/
http://xkcd.com/297/
I love the Python irony, too. print “Hello, world!” doesn’t work in the newer releases of Python…
how is that ironic?
Well, you see, irony is the opposite of the literal meaning.
The comic says, “Everything is so simple! Hello world is just ‘print “Hello, world!”‘
But Hello world in Python 3 is NOT just ‘print “Hello, world!”‘. Now it’s ‘print(“Hello, world!”)’, which is somewhat more like other more punctuation-centric programming languages.
Hence, irony.
Of course, like most humorous references, it loses something when you have to explain it in detail. ;-D
I know the meaning of irony. I favor dramatic irony over the definition you put forth which I align more with sarcastic or facetious language.
In the case above, I find it still a little weakly linked to your meaning, but perhaps it is because I am not familiar with the comic you are using as a reference for your Irony.
I barely understand complex C code yet this never stopped me from using programs written in C.
Just run well tested Perl code from your other-language scripts…
PS. Yeah, I respect Lisp and love Ruby, but when I’m trying to open a bottle, anything, even a hammer will do.
Edited 2010-09-12 12:48 UTC