Comparison of PythonLanguage and PerlLanguage; a RightBrain view is in PythonAndPerl. (Contrast: PerlVsPython...) ---- The downside of Perl I'd say is the poor readability. The design of Perl seems to encourage cryptic code in the name of efficiency - a serious disadvantage as far as modelling is concerned. (For example, I find myself trying to "reverse engineer" an interface-based architecture out of the code mess.). * ''I agree, and you know what, that "Greek" Language is totally unreadable too, they use all these funny symbols...what? you mean I have to "learn" the language first? Inconceivable!'' A familiar account of Perl's shortcomings, unfortunately written by someone who doesn't understand basic Perl features like references and who apparently thinks the term "subroutine" is a Perl neologism, can be found at: http://www.garshol.priv.no/download/text/perl.html (please excuse the Python sales pitch towards the end of the article...) --some guy (edited by KragenSitaker) [ ''CeeLanguage/CeePlusPlus, JavaLanguage, VisualBasic or anything else, for that matter can be used to write ugly code. I think it's a matter of disciplining your programmers. Try looking at CultOfPersonality ;) -- IvanStojic '' ] I can appreciate the quoted shortcomings. But I didn't see a one that hasn't been well addressed in modern perl. Bad documentation remedy: buy the resource kit. Multithreading: perl has excellent multithread support now. Arcane builtin syntax: use the english module. Full-fledged Net/DB libraries: nowadays Perl has these things coming out the wazoo. Object orientation: as of Perl5, perl supports all the OO devices you can name. Regexes and Formats as compiled objects: put them inside closures. Composite data structures: the syntax is consistent and concise, it just looks weird to folk used to lisp/prology sorts of languages. You get used to it. --PeterMerel How is ''use the english module.'' a solution for my having to deal with other people's ''Arcane builtin syntax''? My main problem with Perl is that I've had to read other people's Perl. It was never easy, even though I knew enough about the language to write non-trivial programs. -- The advantage of a small language is that it's easy to teach and understand. In a previous job, one of our colleagues, who is not stupid, was having a terrible time getting from C to C++. We moved him to Python and he turned productive in days. What's especially nice about Python is that it's tremendously scaleable for such a small language -- it works smoothly all the way up from command line scripts to large systems. I miss it deeply... [In response to a description of the PerlCOM/PerlCtrl modules] There is a Win-Python version that does ActiveX in some way I don't know enough about. c.f. http://www.python.org'' -- SteveFreeman Found it okay - and I think if anything it's more flexible than the perl one because it lets you write standalone controls and static binding (IUnknown rather than IDispatch) clients. Looking at the syntax it'd clearly be easier for a poor lost VB lamb to use. No "" at the end of lines for a start. Python works for active scripting just fine too. But wait a moment - you can actually generate java bytecode with python (see JavaPython)? Wow, perl lets you embed but it doesn't actually make freestanding bytecodes. And you can run python, complete with interactive interpreter, on a CE device? I think that'd be really sweet on a Clio ( http://www.vadem.com ) Hmm, there's something perl and java can't touch yet. Python is sure a hell of a lot easier to learn and maintain too. But the game's not over yet. There are two major factors counting against python for large-scale work: * The Python DB layer is in a state of higgledy-piggledy. There are multiple interfaces to ODBC with varying capabilities, some commercial, some not. Likewise with the direct Oracle interfaces. And the COM interface has a couple of bugs that presently hinder ADODB work. No obvious leadership is apparent in the Python DB SIG, which focuses much of its efforts on lesser databases like Informix and Sybase. This is very different to the technically excellent, well funded and well organized Perl DBI/DBD effort. ''No longer true with the DB-API 2.0 (http://www.python.org/dev/peps/pep-0249/)'' * Microsoft hasn't bought into Python. What's more it looks very unlikely that they ever will buy into Python. They have bought into Perl - they funded the win32 port. Means nothing technically, but a lot to the suits. Just proposing a scripting language is hard enough without also trying to bust 'em out of GatesDiscipleMode. (''As of Dec 1999 there is a very good win32 library covering MFC, COM, WinCe and all the stuff we LoveToHate. I don't think it's paid for by MSFT, though.'') But on the balance I think I'm still favouring Python. --PeterMerel ''Good to see there is some justice in the world ;-)'' --SteveFreeman ''Microsoft hasn't bought into Python'' -Actually they supported an experimental port by Mark Hammond. ''python.NET'' See http://www.activestate.com/Corporate/Initiatives/NET/Python_for_.NET_whitepaper.pdf?_x=1 -- PaulTaney ''It's curious how Python people still needs to justify their election of language... I like Perl and prefer it over Python because I have been able to do stuff in Perl and have not in Python... and I need no other justification... Besides, Perl is better :-) And about the Win-interface, I mostly use UnixOs and so I am not worried about IUnknowns, etc... who needs them anyway, there's Corba out there...'' -- DavidDeLis I see an equal number of people feeling the need to justify Perl. Perl's great for some things, but I plan to do most of my prototyping in python from now on. ''Perl is more than probed, people only justify it (or at least I do) when it's unjusty spoken... Using Python is OK, it's your choice. Fortunately, we can choose... The best thing is that, with any of both languages (and others like RubyLanguage, etc...) we are free...'' ---- Regarding MS buy-in for Python, the company responsible for Perl Win32 (ActiveState) has recently announced that it will be pushing and supporting a Python Win32 release too. --StevePurcell ActivePython is available from http://www.activestate.com/Products/ActivePython/index.html - it supports Linux, Solaris, and Windows. Also, it should be mentioned that ActiveState are doing versions of Python *and* Perl for MicrosoftDotNet. --KornySietsma ---- Personally, I think Ruby (RubyLanguage) is a nice compromise between the two. It has a lot of perl style operators (shortcuts) (i.e. $!), but gives choices as well, and avoids the ugliness of python's __xxx__ methods. One of the first programs that I wrote with it, I banged out 100LOC without stopping. I'm not a tremendous programmer, so that was a great feat for me. One that I've never accomplished with perl or python. It's syntax is smooth, but of course, it's still young, about where python was a year or so ago. I'll never use perl or python again. http://www.ruby-lang.org http://www.rubygarden.org (See PythonVsRuby) ''There's nothing ugly about __this__ and it signifies "internal object".'' ---- ''Composite data structures: the syntax is consistent and concise, it just looks weird to folk used to lisp/prology sorts of languages.'' So what's \(1,2,3) ''It's a very handy feature. I use it all the time (though I use it with variables, not constants). How would you do the same thing in python?'' E.g. in fetching from databases: my $sth = $dbh->prepare("select this, that from table"); $sth->execute(); $sth->bind_columns(\my ($this, $that)); while ($sth->fetch) { # Data is fetched to variables $this and $that print "This: $this That: $that\n"; } (clue: it's ''not'' the reference to a three-item list that you were probably expecting it to be) ''Well, actually it is exactly a reference to a three-item list (update: no it's not, see below). ;-) The distinction between perl-lists and perl-arrays is a common source of confusion, though. For pythoneers: in perl a ''list'' is a free set of scalars. An ''array'' is a set of scalars bound to a variable or to an anonymous array. In scalar context (as above) an operation on a list is resolved to an operation on the last element of the list. So the expression above is the same as "\3" - a reference to a scalar of value 3. To yield a reference to an array one would write the expression above as:'' [1,2,3] ''Anyway, I'm not a good teacher so you might better refer to "man perldata".'' MartinSchwartz perl's colorful "context sensitivity" works perhaps 99% of the time; and that's the hacker philosophy (I want a 90% solution ''right now''.) But I'm trying to be an engineer, so I try to set perl aside for anything over 100LOC. I say ''try'' cause it is addictive. Show me perl -p -ibak -e s/foo/bar/ in Java, ''please.'' -- PaulTaney Apply the same discipine to Perl that you would to C++ or Java, and you might be surprised at how well it scales. I worked inside of a system that included an 80KLOC Perl middle tier, and it was a real pleasure, particularly when compared to the raw pain of working in a C++ system of similar size and complexity. --DaveSmith ---- ''the expression above is the same as "\3" - a reference to a scalar of value 3'' Have you ''tried'' that? DB<1> x \(1,2,3) 0 SCALAR(0x1012e9c8) -> 1 1 SCALAR(0x1012e9d4) -> 2 2 SCALAR(0x1012e9e0) -> 3 DB<2> x \3 0 SCALAR(0x1012e9bc) -> 3 Ignoring the obvious(sic) "in a scalar context" RedHerring - nothing in the original was there to force it into a scalar context - this is actually a list of three references to scalars. It's even so documented in perlref(1) ---- See WardNumberInManyProgrammingLanguages for two programs in each language that implement the same idea. So what's \(1,2,3) (clue: it's ''not'' the reference to a three-item list that you were probably expecting it to be) Of course it isn't. An anonymous list reference is created like this: \token, or [1, 2, 3]. Most of your complaints about Perl are because you're taking Perl in reference to other languages, but Perl isn't other languages, it's Perl. Because something is done differently, doesn't mean its done wrong. As for messy code, I'll take efficency over readability any day. Besides, cryptic code is nothing a few comments won't fix. ---- Forget for the moment whether you like white space or curly braces. TheCpan is the deciding factor for me. And although many Perl Programmers wouldn't mind switching to RubyLanguage, TheCpan is the one area where both Python and Ruby still have some catching up to do. ''What modules, in particular, do you feel that Python or Ruby lacks that TheCpan provides?'' Not necessarily talking about any particular modules. Ruby and Python lack TheCpan itself. A one stop shop for searching, reading docs, reading source code, downloading the library, and (new feature, still questionable) reading module reviews -- but how about 'Memoize'? :) ''Have you seen http://raa.ruby-lang.org and http://www.python.org/pypi ?'' No (not until now, anyway), but comparing those and TheCpan, I still say there's some catching up to do. It's too bad that TheFreePan never caught on (even though it, too, needs work to catch up to TheCpan). ''In my personal experience, the quality of CPAN modules is pretty low, and as a whole, they lack regularity, especially in terms of error handling. Right now, I'm working with LWP::UserAgent. Whenever it encounters an error of any kind -- such as hostname lookup failure, connection refused, etc. -- it sets the HTTP response code to 500, making it impossible to distinguish between a network error, a protocol error, or a genuine 500 error. Terrible.'' I think you can distinguish between a genuine 500 and the others by setting the 'use_eval' option in the UserAgent constructor to false, and catching exceptions yourself (not very well documented, I admit, but obvious if you look at the code--and I've never looked at it until now). I agree about inconsistent error handling though. That's what you get with TimTowTdi and a multitude of authors :) ''Thanks for the tip.'' ''I'm willing to concede that there are some gems in CPAN. Perl's DBI is fantastic, and Python's DB-API leaves a lot to be desired. On the other hand, most of the gems in CPAN are included in the standard Python distribution. Python users don't need to get Storable from CPAN, because Python ships with pickle. You don't need Digest::MD5, because Python ships with digest tools.'' Perl now (as of 5.8.0 -- update: but not after 5.8.1) ships with Storable. Its hard to decide what should be a 'core' module or not. Some people don't do database work (and don't need DBI). Some don't do web work (and don't need CGI - although it's now included also). Another complaint: on my system, I can say 'man Storable' and get the docs for Storable. I have python and ruby installed also. Can I say 'man pickle'? or 'man any-ruby-module'? ''Try "pydoc pickle". Ruby has rdoc, which isn't as far along yet.'' pydoc doesn't work. I probably need a new python... import pickle help(pickle) Works even if the module has no documentation (but of course pickle does). can also do: import pickle print pickle.__doc__ ---- You know why I like perl(doc) over pydoc? perldoc, for most modules, starts with a SYNOPSIS section, a brief rundown of all the functionality of the module, with examples you can usually cut n paste. pydoc, OTOH, usually has no examples, and you're left googling for examples of how to actually use the library. E.g., contrast "perldoc Text::CSV" vs "pydoc csv" Or "perldoc DBI" vs (another sore point, no DBI, so, e.g.) "pydoc cx_Oracle" ''or you could just skip it and google directly. perldoc is ooold'' ---- CategoryProgrammingLanguageComparisons