Python Vs Perl
Python Vs PerlComparison 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.).
--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.
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:
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) -> 3Ignoring 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
EditText of this page
(last edited June 13, 2013)
or FindPage with title or text search