Slashdot Mirror
Perl vs. Python: A Culture Comparison
davemabe writes "Every programmer has a favorite scripting language. Here is a well written article by Jon Udell from byte.com detailing the differences between Perl and Python, their cultures, OOP, database access, philosophies, and which one will gain the most converts in the future. Very interesting reading on an almost religious debate. "
Right, off the ropes, reversed, back elbow, elbowdrop, off the ropes with a kneedrop to the chin - 2 count. In the corner, right, right, into the opposite corner, follow lariat. Fisherman suplex coming up - 1, 2, shoulder up! That move NEVER works! Wall scoops him up for a bodyslam again - and now Wall is ready to try the Money Shot - Guido manages to bounce off the top rope, crotching Wall. REVERSE FIREMAN'S CARRY! Cover, referee "Blind" Jim Korderas in position - 1, 2, 3!!! Ladies and gentlemen, we have a NEW Champion!!!!!
Do we have a new champion in the scripting language areana? Does it matter if they're both well made products?
More race stuff in one place,
than any one place on the net.
Re: Jon Udell's: "A Perl Hacker in the Land of Python" (http://www.byte.com/feature/BYT20000201S0001)
Well, since someone else mentined it, here's a reaction I had to an
email conversation where the Udell URL was cited. Take it or leave
it... but I finally pinned down what I think is wrong with Wall's
initially rather intriguing 'philosophy':
You know in Perl the motto is "there is more than one way to do it".
Larry Wall takes this by way of a linguistics background, and wants
to make Perl resemble a natural language. In contrast--at least at a
syntactic level--Python has fairly clear rules about what something
*has* to look like, and there tends to be a high degree of
orthogonality (which Wall vehemently eschews). There were some
remarks like this in the article. (Obviously, in terms of semantics,
large-scale design, and algorithms, there are many ways to do a thing
in any language).
I think Perl succeeds in what it is trying to do. For that reason,
it really does often look like a "write-only" language. You can
easily express your own "thoughts" fluidly and naturally... the
problem is that they are then as difficult to unpack later as a poem
or a complex philosophical sentence (good uses of natural language).
The thing that Wall &gang seem to miss is the distinct registers of
natural language. The whole thing is very rich in expressivity, and
highly non-orthogonal. But that is absolutely *NOT* the case when it
comes to specialized areas of natural language where clarity and
precision are at a premium. I *WANT* air-traffic controllers to
speak in a highly structured, syntactically and lexically limited,
and stereotypical fashion! I really *DO NOT* want them to use free
verse! To a somewhat lesser extent, I also want programming specs or
technical documentation to follow a rather rigid pattern. When I
look in the help file, it makes my life a lot easier if the list of
parameters to a function are always described under the same heading,
with a consistent and fairly small subset of English words, and with
an attention to consistent whitespace, layout and special characters.
The moral is that Perl is a great language for *implementing*
haiku... but Python is rather better at implementing functional
specs.
Yours, Lulu...
Buy Text Processing in Python
Zope sounded interesting, but I'm also checking out Mason, a Perl-based system that is tied into mod_perl. mod_perl was perl's six or seventh killer application (and I mean application as in applying a tool to a job, not as in a packaged program). First came the power of Perl regex for text processing. Then CGI (remember CGI was pretty much born in Perl). Then came LWP, and a splash was heard round the world. How many robots and spiders are written in anything else?
Perl is slowing, though. There is a consolidation and honing of features that needs to take place, and perl resists that. In some ways, this makes me long for something like Python, but I've actually been thinking of writing a Perl variant that accomplishes some of the same goals, but aimed more at large-scale programming in performance-oriented environments. I see the main benefits of a new language design being:
I dunno. I'll probably spend a couple of months scoping other languages before making any real investment of time.
As for whitespace and style issues, I dislike Python's way so much that I've put off learning the language for years. It's just so... FORTRAN. Why, of all things would you, in this day and age, subject people to a DEFINITION of TABS?! Why not enforce variable-naming at the same time?
One major point the article makes is the philosophical differences between the languages. This is best illustrated by the simple "There's More Than One Way To Do It" (TIMTOWTDI) approach of PERL versus the "Keep It Simple Stupid" (KISS)design of Python. I think this is not only valid, but possibly the most fundamental difference between the languages. Outweighing even the Object Oriented aspects.
As a programmer I am very attracted to Python's clean syntax and deceptively simple low level data structures. Within this simplicity lurks some very impressive thinking about how programming languages should be used. For example Tuples are first order objects in Python! The only other languages I know of with Tuples as first order data structures are declarative languages like SQL. (Someone is sure to tell me how I am wrong in a reply...)
What this simplicity means is that I can build arbitrarily complex structures from those simple elements and the next programmer to look at my code will be able to follow my code without too much effort. Building complex structures from simple ones is the very essense of Object Oriented design, look at Smalltalk for another example of this approach -- although Python has an arguably better syntax than Smalltalk.
On the other hand, providing multiple ways to accomplish the same action means that the programmer can choose the method best suited to the current need, both in parsimonious code and optimal execution time. In this PERL is rather like C++ which often provides 15 different ways of doing the same thing, each optimized for a different purpose. The downside of this is that you need to know every one of those 15 possible ways to get the job done and understand the reasons why any one is best suited for a particular need...
My, long winded, point is this: TIMTOWTDI can potentially provide shorter programs and better execution times, but will always result in more difficult to understand code. Moreover, many programs will not be optimally coded because the programmer who writes them will only understand 10 or 11 of the 15 ways to do things, resulting in the old "When you have a hammer, everything looks like a nail." problem. However the KISS approach ends up with more total lines of code and, perhaps, slower execution times, but the code will be more accessable and (therefore) more maintainable.
And this is why I prefer Python. Processing cycles are cheap, but programmers are expensive. I am always willing to trade one for the other. If I have to choose between a language that promotes code clarity and simplifies maintenance over another that tends to shroud the algolrithms in terse bits of bizarre sytax then I will always go with the former...
Jack
- -
Are you an SF Fan? Are you a Tru-Fan?
The two monks stand side by side, facing the altar, behind which a graven image of the Great and Benevolent Tux stands with wings half spread as he contemplates the GNU/Path to True Enlightenment Through Open Source. One monk wears a single pearl upon his forehead, glimmering in the flickering light of the altar candles. The other sports a torc in the form of a serpent entwined around his upper arm. The gaze upon the image of Tux placidly, each at inner peace.
The monk with the pearl breaks the silence: "Good brother, I see your movement grow by leaps and bounds. How is this so?"
The monk with the serpent replies: "It is our more disciplined coding, brother, which more quickly leads down the One True Path of Enlightenment. Discipline of code leads to discipline of mind and body."
Pearl: "But what of tailoring the Quest to the individual? Be flexible like water, and in time, even stone will fall before it."
Serpent: "Be structured like iron, and the stone will fall faster."
Pearl: "But each mind is different, and should be allowed to find their own path."
Serpent: "There is but one Path, brother, just many ways to find it. Ours is the quickest and most sure."
The candles on the altar continue to flicker as the two monks fall into a few moments silent contemplation.
Pearl: "I am afraid I must disagree."
Serpent: "So you say, but you know the truth in your heart. Did not your order adopt the doctrine of OOP despite the conflicts with your order's earlier, strictly procedural ways?"
Pearl: "OOP is just one path of many."
Serpent: "It is the soul of the Way."
Pearl: "And so you seek to challenge the longstanding authority of the Order of the Pearl? We have existed longer, and are closer to the Truth!"
Serpent: "You wander blind in the mists, poor deluded souls, while the True Way beckons! You can yet change your $PATH."
Pearl: "You speak heresy! Leave the Holy Temple before the Great and Benevolent Tux smites you!"
Serpent: "I speak Truth, and you are but too mad to see it! I curse you and your Order! The Way of the Serpent will triumph!"
And the monk with the serpent turns and stalks out of the Temple, growling, "We will be back, and in numbers! The Temple will be ours!"
The monk with the pearl watches his counterpart leave, turning back to the altar and shaking his head. "We will be waiting, and the Great and Benevolent Tux is on our side!"
-- WhiskeyJack, on serious caffeine withdrawal.
> I think the difference between python and perl
> can simply be explained that perl is about
> getting something done, no matter about how
> messy or incorrect the method used may be,
> while python is about doing things correctly
> 1st time, for later use.
What? Because Python forces you to a strict coding style doesn't mean that your code is "correct". It's still possible to write a bad algorithm in Python, just as it is in Perl.
> Its the difference between grafting OOP into a
> text processing language or including it from
> the start.
Perhaps you should actually point out some limitations of Perl's OOP. Maybe you could also explain what this has to do with your own code quality.
> Its also got a more readable and less misused
> syntax, albeit its use of whitespace is at the
> other extreme from perl's fit it all into one
> line with no carraige returns in sight. (if its
> not like that, your likely not using perl to its
> tersest extent.)
What are you talking about? Sure it's possible to write Perl code on one line, just as in many other languages. Unless you're an idiot, or purposefully writing obfuscated code, it's generally not done.
I'm sick of all these comments complaining about how hard Perl code is to read.
Providing that:
a) you actually know the language, and
b) the code was written by someone who actually knows the language
You should have zero problems with readability. Remarkably enough, the above applies for nearly every other programming language.
> From someone who has dabbled in both and used
> neither significantly.
Like so many others in this discussion, I doubt that you're qualified to make such broad assumptions about either language.
I use Perl a lot; while I've read the book Learning Python, I haven't really used the language, so please correct me if I'm wrong:
It seems that the essential structure of Perl and Python is pretty similar most of the time. Okay, Python doesn't have function closures and other funky features, but most programs and libraries don't use them. Similarly, the two OO paradigms are a little different, but the basics - creating an object, simple inheritance - are the same, and this is often all you use anyway. Applying the 80/20 rule, you could say that they are pretty similar.
What would be cool is a way to call Perl libraries from Python, and vice versa. For example, Perl's DBI is said to be better than Python's database drivers (which tend to be specific to a particular DBMS). Since most DBI methods are just creating an object, performing an action, or returning a list as a result, it would be easy to write Python wrappers for them. Similarly, some cool things like wxWindows have Python bindings and no Perl bindings, but the features they use aren't particularly Python-specific. (wxWindows is written in C++.)
So how about a general interface for Python that wraps any Perl module? Then Python programmers could take advantage of the world's largest archive of reusable software, CPAN. It would be a fairly simple matter (I suppose) to load in libperl.so, tell it to load the Perl module, and then whenever a call is made to the module, marshal the arguments from Python dictionaries to Perl hashes, Python strings to Perl strings and so on. Of course many modules which depend on Perl intricacies wouldn't work here, but most modules would.
The opposite interface would be fairly similar. Since Perl's lists and hashes do not nest, you'd need to convert a Python function or method returning a list to a Perl one returning a list reference. But apart from that things should be just the same.
I'm a keen Perl programmer, and the one thing that's stopping me from trying Python out for real work is that I'd have to wave goodbye to all those lovely CPAN libraries. So could someone with more knowledge say whether a scheme like the above is possible?
-- Ed Avis ed@membled.com
Sorry, but this is bullshit. JPython is written in Java and runs the same speed (and on some benchmarks faster) than CPython. How can JPython run Python as fast as CPython, yet Java be *slower* than Python? I don't think so.
Perl's PP-bytecode execution speed is about 100 times slower than a JIT'ed Java App, just try writing a straight numerical app like a Fast Fourier Transform, or a JPEG-decoder in *pure* perl, with no XS modules that escape to C.
If you look at caucho.com, they have proof that Java servlets are faster than mod_perl.
Perhaps you are refering to the GUI widgets being slow, but the GUI widgets are just a module, like Tk/wxWindows and are just an add-on to the VM, not part of the language. Not only that, but there are numerous third-party replacements for the standard Swing/AWT widgets that run very fast.
The fact remains that Python/Perl are interpreted, and Java, while being bytecoded, is compiled on the fly to native instructions.
There are plenty of code libraries out there that demonstrate Java's relative speed vis-a-vis other interpreted languages.
Java's JMF multimedia framework demonstrates realtime MP3 decoding, and MPEG/AVI decoding in pure Java. http://java.sun.com/products/java-media
www.jcraft.com demonstrates an *XSERVER*, yes, an X11 display server, ESound server, and true-type font server written in Java.
At www.komplex.org you can see real-time "megademos" doing 3D transformations, lighting, texture, and bump mapping. With Java2, some of these run fullscreen (640x480) at 20fps.
Java Cryptography libraries demonstrate very fast encoding performance. Try writing a Pure Perl/Python RSA/DES/RC-4 library, and an SSL stack that can perform.
Yes, we know Java isn't as fast as optimized C. But Perl/Python can't beat Java unless you write a program that is almost entirely made up of calls to Perl's native facilities (perlfunc functions, regex, and hashtables). Anything that has to process a large amount of data, *and* isn't related to parsing/manipulating text, will run slow.
If you created a native-library hashtable for java, and native library string and regex libs, Java would exceed at text processing too.
Having different editor settings is something which different authors often have, this is hardly the first instance where magic white space has caused problems, make being an obvious previous example.
I really don't know why Python programmers reject the concept of bracket characters (or words as in languages like Pascal). In my exprience, when reviewing code it's useful to know what the original author was intending to program, as well as what she actually programmed.
Having syntax markers as well as indentation provides a valuable redundant check which indicates when the thoughts are not matching the code.
If a program has
Then I know that there is something wrong with the program. I don't know if the programmer wanted the else to go with the first if or the second, but I do know that he was confused about this section of code.By removing the {}, you loose that redundant check on the code, and the poor maintence programmer has no clue that this is a suspect portion of code.
In the past I've heard the claim that you could use magic comments in python to indicate your desired indentation. Unfortunatly, almost every production program I've ever seen has had correct indentation, while I've never ever seen a python program with magic comments.
There are several different implementations of Python, but the most notable are CPython (Original Python) and JPython. JPython is an implementation of Python in 100% pure Java. Python scripts run anywhere there is a JVM (though you need the JPython jar and probably the Python class library). Furthermore you get complete access to Java from within Python. You can instantate and send messages to any Java class. You can even subclass Java classes in Python. You can use the Python interactive mode to interactively manipulate Java classes. It's way cool! In my opinion, it is the best way to deal with Java. Python becomes a higher level langauge on top of Java.
Anyone who is forced to use Java (which is becoming more and more politically correct every day) would be wise to check out JPython.
Many people complain about Python's use of relative indentation but those people typically don't use python. It really is a complete non-issue for people that use Python. Let's face it, cutting and pasting code when using an Object Oriented language is Bad Form.
Note that it is indeed possible to defeat the indentation if necessary. Check out this implementation of a CBC (Cipher Block Chaining) mode Karn cipher in Python (using MD5 for the hash function). The key and IV are crunched with MD5 before usage, so they can be of arbitrary length and density.
Usage: karn -e "key" "initialization-vector" | karn -d "key" "initialization-vector"
from md5 import *;from sys import *;from string import *;M=md5;il=ir=M(argv[3]\ ).digest();ki=M(argv[2]).digest();K,k=ki[:8],ki[8: ];p=stdin.read(32);c={'-e':'\ l=x(l,il);r=x(r,ir);R=x(M(l+K).digest(),r);L=x(M(R +k).digest(),l);il=L;ir=R','\ -d':'L=x(M(r+k).digest(),l);R=x(M(L+K).digest(),r) ;L=x(L,il);R=x(R,ir);ir=r;il\ 1 6],p[16:\ ];exec(c[argv[1]]);stdout.write(L+R);p=stdin.read( 32)";exec(main)
=l'};main="def x(a,b):return joinfields(map(lambda m,n:chr(m^n),map(lambda m:o\
rd(m),a),map(lambda m:ord(m),b)),'');\nwhile(p):p=ljust(p,32);l,r=p[:
$x->{'y'} versus x.y -- and let's not forget about x.__class__=mypackage.MyClass. Can you even do the latter in perl?
The distinction seems pretty clear to me... perl's class / package syntax is MUCH obviously cruftier. If you think that it's not ... well, then use perl for OOP. We disagree.
Have you ever tried to read befunge, or brainf***? I know these languages, and this is certainly NOT true for them. Perl also makes heavy use of punctuation marks to mean things which are not only not immediately obvious, they can be confusing. In fact, a quote from Larry Wall himself is "admittedly, readability suffers..."Perl is not as readable as python. If you don't have any trouble reading perl, that's anecdotal evidence... there is a statistically significant number of people who don't have any problems -- and in fact, enjoy -- reading python (read the python mailinglists, or c.l.python, or www.python.org, or #python on IRC... I've been to the perl equivalents, and I've never seen them advertising readability or maintainability), because it was designed to encourage that. This doesn't mean perl is worthless: it's a language feature of python to be consistent and easy to read. It is a language feature of perl to be terse and easy to write.
Finally, consider this python statement: x=['a','b',{'c':'d','e':['f','g']},['h',['i','j']] ]. I admit that perhaps I'm not the swiftest perl programmer ever, but it is certainly not that easy to make a data structure which is a list of strings, hashes of strings and lists, and lists of lists in perl. The syntax gets really hideous and doesn't mean what it looks like it should. (I can't even come up with a way to write that in perl on they short notice required for posting this comment: perhaps a better perl hacker than I can elucidate..)
Glyph Lefkowitz - Project leader, Twisted Matrix Labs
Writer, Programmer - Not a member of the TSU
You know, I've never understood why advocates of a language whose motto is, "There's more than one way to do it" take such exception to those who choose to do it in another way.
Weblogging Considered Harmful:
as long as you are consistent about the amount of whitespace in a given block, it doesn't matter if you use a tab, three spaces, or any combination. Python cares if you are consistent about it within the block. it does not have to be a tab.
for example, run "python" and type these in:
def myFunction():
print "two spaces"
def yourFunction():
print "eight spaces"
no problem. just use the same spaces in a given block.
Daniel
I didn't know Python.
At my old job, I was told to learn it because we were going to use it as our scripting language for a text animation system we were working on. At the time it wasn't a priority, and my internship ended before I got around to it.
I know Perl, and I always cringe whenever I have to code in it. It's something about all the excess punctuation that is required to do anything.. It's a hemorrhoid to read anyone else's code.. I think Perl code in itself is a good fingerprint of the psyche of the programmer. You can see little hints of anarchy/anal retentiveness in it. WTF - why can't the code be cleaner? Why can't it represent the true nature of what the programmer is trying to get across?
And then I started working for this VFX company in Austin, TX (I'm an anonymous coward, remember?) We were in desperate need of a robust distributed work queue for rendering, compositing, compiling..etc. I still had the Python books, so I decided to check it out, making this my little project that I would use Python for.
In one week I knew everything about the language there was to know. Easy - direct - clean - beautiful. By the second week I was writing C modules to interface with NT and SGI (the two architectures we use) system libraries. Serious cake.. The OOP structure of Python is very free and easy to understand and code.
...
Now that the project is done, I can't imagine using Perl, or any other language to do something like this.
Some of the joys I found while learning Python and coding this thing were (no I'm not into abusing buzzwords) ease in RPC communication and data marshalling, thread control, bidirectional pipes, code-reuse, architecture independence, exception handling, and the easy ability of going back into what I wrote and being able to read my own code - not to mention a great debugging environment.
It's sort of like a really clean C++ with the convenience of Perl.
I would HIGHLY recommend Python as being something you need to learn and start using! I mean, Perl is good for hacking stuff together because you know how to do it in Perl. Even Bash is good for that.. But Python really gives you a good feeling that you are architecting something that is made to work, made to last, and made to be maintainable. And Python is extremely good for quick Perl-ish hack jobs.
Maybe Perl (in reference to an above post) is for artists, but I think Python is for designers. Know which one you are, before you do anything else.
Sean
Having said in an earlier post that I like the article, here's two things I disagree with.
For one thing, the claim about a "Killer App" is not terribly persuasive. Perl may not be able to point to an application that is as impressive as Zope, but there is a multitude of Perl software components that have proven themselves as killers -- such as the CGI, DBI and LWP modules and Apache's mod_perl, to name just as a few. A great deal of software running on the Internet constitutes Perl's "killer".
More importantly, I don't at all believe in a distinction between Perl and Python, or for that matter any other language, concerning TMTOWTDI -- as if Python's motto is "There's only one way to do it", or TOOWTDI (pronounced "tooty").
People act as if TMTOWTDI is a special feature of Perl, but I don't buy it. TMTOWTDI is an essential truth about the way computers work, regardless of any programming language. Show me any problem, and I'll show you more than one substantially different Way To Do It, using any language.
TMTOWTDI is often misunderstood as a free-for-all, a ticket to do whatever you want. Not so. The motto should always be continued with, "... But Some Ways Are Sometimes Better Than Others". Some solutions to a problem will run very fast. Others won't run as fast, but will use less memory or I/O. Yet other Ways To Do It lend themselves to being written in more easily maintainable code. If you read the Camel and other Perl docs carefully, you'll notice that the authors are always at pains to make these differences clear.
Suppose your program needs the value of a complex function. You could compute the function on the fly, which may take some time but saves space. Or you may pre-compute it for a large number of values, which will take up a lot more space but will run much more quickly. Your choice of a solution will probably not be influenced at all by the programming language you've chosen to use, but rather by the resources you have available.
I don't know Python, but I flat-out disbelieve that it allows only one way to solve any particular problem.
Always keep a sapphire in your mind
Providing that:
a) you actually know the language, and
b) the code was written by someone who actually knows the language
You should have zero problems with readability. Remarkably enough, the above applies for nearly every other programming language.
And I'm sick of all these dismissive oversimplifications of a complex issue.
Some languages lend themselves more to readability than others.
Admittedly, readability has as much to do with the reader than it does with the writer, but there are some attributes of a programming language that make it more readable when the readers are most human programmers who might try to modify code.
For example, I can parse and completely understand the semantics of simple aritmetic more easily than I can most English prose. This is true, even though I spend probably a minumum of 1000 times more time practicing writing and reading English than I do with arithmetic. Thus, it's not a matter simply of experience with the language.
English prose is far more expressive and powerful and completely contains all the expression and power of simple arithmetic.
The TIMTOWTDI nature of Perl leads to a lot of different ways to express a program. To understand the semantics of a Perl program one might have to think in a number of different idioms. Depending on the original author, the different styles and idioms might cover a large subset of the language in a given program, and Perl is a "big" language, with lots of odd corners.
Here's an extract from a discussion I was involved in a few years back in comp.lang.perl.misc with none other than the redoubtable Randall Scwartz that I think helps illustrate the point I'm trying to make:
>>>>> "Jordan" == Jordan Henderson writes:
Jordan> For example, say I want to extract preformatted text from an HTML
Jordan> file. Note that this is not a general purpose preformatted-text-
Jordan> extractor, but it's handy for files where I can guarantee the
Jordan> format (in a case where I wrote the original HTML file with another
Jordan> program, for example):
Jordan> while () {
Jordan> last if
Jordan> }
Jordan> if (eof) die "HTML format bad, couldn't locate preformatted text.";
Jordan> while () {
Jordan> last if
Jordan> print;
Jordan> }
Jordan> if (eof)
Jordan> die "HTML format bad, couldn't locate end of preformatted text.";
Jordan> Is there a better, clearer way to do this sort of thing?
I usually write something like this:
$found = 0;
while () {
$where =
$found = 1, print if $where;
last if $where =~
}
die "we didn't find it!" unless $found;
print "Just another Perl hacker,"
--
Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying
Email: Snail: (Call)
PGP-Key: (finger merlyn@teleport.com)
Web: My Home Page!
Quote: "I'm telling you, if I could have five lines in my
Now, I was somewhat of a Perl newbie and I'm still nowhere nearly at the level of a Randall Schwartz, but I had a hard time with Randall's answer at the time. I was familiar with the .. operator, but had never used it.
I still feel that my original attempt using the eof operator was simple and very readable. I also love the elegance of Randall's solution.
See, I like Perl, I really do. It's very expressive. Randall's solution points to many other opportunities for good use of the .. operator. I don't think it's the most readable, in this case.
There's the rub. The most readable solution may not use the most expressive idioms. Readability isn't the only criteria on which to judge a work. Shakespeare is harder to read than Suess, but I don't want to be limited to a Suess-like style in my own writing
However, I'm sympathetic to the camp that seems to believe that computer languages should not have the same ambiguities and expressive power than natural languages. In some settings, it may be more productive to use languages with a more limited selection of possible idioms.
For example, I might prefer that an Air Traffic Control system be written in Ada rather than Perl. I want the maintainer of that code to be able to immediately and completely grasp the semantics of the code in front of him or her. I want the maintainer to be immediately comfortable with the style and choice of idioms.
Horses for Courses. Perl still excels in it's adaptability, it's functionality and it's expressive power. Python may excel in simplicity, it's applicability to programming language education and it's readability. I don't actually know Python so forgive me if I misrepresent it.
I'm glad I have simple arithmetic for some things. I'd hate to have to express number problems in English. I prefer "2 + 17 = 19" to "Two plus seventeen equals nineteen."
-Jordan Henderson
Yeah, use bless. But your point is well taken. Perl's OO stuff is pretty much roll-your-own, which is great except when it sucks. I love Perl, but at times it's so crufty that I immediately revert to Scheme.
Well, actually, it's pretty straightforward:
The syntax is fairly clean, I think (although it does look much nicer when properly indented and formatted), although accessing it can be uglier:
One striking thing about Perl that I haven't seen in other language communities is the ease with which experienced programmers almost unconciously create personal dialects of the language. This is great for writing code, much less great for, say, fixing it. There are so many weird tricks possible, such a rich idiom, that it's natural to recycle exceptionally clever bits, sometimes (often?) to the detriment of readibility
In any event, both languages are fun to code in, and can certainly peacefully co-exist.
Cheers,
(jfb)To spur "enterprise Linux," Big Bang, the distributed two-phase commit.