On Dec 18, 2011 3:34 PM, "Yossi Itzkovich" <[email protected]> wrote:
> As a Perl fan I was asked to give an answer to the question "Why Perl and not > Python". I know there is no easy answer, and it also depends who I am asking… > > I don't want to start an emotional thread here, I am just looking for links > of comparisons, pros and cons for each language, etc. I think any answer would boil down to these factors: 1. What already exists in your code base, and what do the programmers at the company already know and are comfortable with. 2. If there's no strong bias either way, then there's the criteria of available framework/modules. Module-wise, Perl has the CPAN, of course, and Python is severely lagging behind (AFAICT) in that area. CPAN modules also come with (fair to excellent) documentation, and usually a good test-suite. Python has, reportedly quite a large standard library, which helps reduce this gap, but using the CPAN you can pick and choose from several solutions and implementations. Frameworks are up to a specific problem-space and required solutions. 3. If this isn't an issue, we get to some language features, Python's object-model is usually considered better than Perl's, definitely more integrated within the language. (Perl's Moose is way ahead of most other languages, only it's an external module coupled with a huge performance overhead). Perl's regex syntax, OTOH, is integrated with the language, unlike Python's. Python have several implementation, the main one, aka CPython, and also PyPy, JPython, et. al. Perl has perl. There are benefits and hindrances to either approach. Perl is also very ubiquitous in the *nix world and comes with probably every OS distro but Windows, Python less so. 4. Finally, if you managed to bypass all these and still haven't reach a decision, your requirements are probably more theoretic/philosophic than practical, which means the differentiation should be on those, more academic, merits of the original design choices. Perl is very different beast than most languages, as it was designed using guidelines lifted from natural languages (http://wall.org/~larry/natural.html), not to be confused with "English-like" languages like COBOL and its ilk. It is, therefore, very simple to express whatever idea you want in Perl, but it also mean you need to learn and practice a lot before you reach this level of expression (although it's very easy to write simple/simplistic Perl to do something quick and dirty, although Perl does subscribe to the Principle of Least Surprise). Perl is, according to its designer the "the first postmodern computer language" and behaves as such. Most languages aim for the "minimal kernel" + standard libraries model, while Perl piles all that stuff inside the language. This is usually where TIMTOWDI and DWIM gets thrown in the mix. Python, in a nutshell, is the extreme opposite of Perl. If Perl is like a tool-to-write-tools (quote Rob Pike "The days of 'one tool doing one job well' are dead and gone and the eulogy was delivered by Perl"), then Python is much closer to this way of thinking. For this, Python's syntax is much more strict, small, "elegant" and its design demands you to say exactly what you want, and it won't "Do What You Mean" unless you tell it to. This allows it to eschew a lot of pronunciation (e.g. braces, parenthesis, sigils) away from the syntax, and it's strictly explicit nature forces a similar style across different code-bases. (more on the matter: http://python-history.blogspot.com/2009/01/pythons-design-philosophy.html). If Perl programs are written in prose, Python programs are written technical manual style. Interestingly, the 4th group of criteria is usually what most people mean by "why X and not Y", but, as I mentioned, are the less important in the chain of decisions. Erez Observations, not opinions _______________________________________________ Perl mailing list [email protected] http://mail.perl.org.il/mailman/listinfo/perl
