Python is better than Perl6

> Perl5 was great. There were 3 things I wanted in Perl6: Cleaner OO support, cleaner grammar, and the third thing? Well, I wanted it to ship.

Don't miss Modern Perl http://www.onyxneon.com/books/modern_perl/

My $0.02 about perl batteries. There are sereral small and pretty frameworks. I myself like Dancer.

Presentation "Perl Dancer for Python programmers":
http://www.slideshare.net/xSawyer/perl-dancer-for-python-programmers

1. There's one way to do things.

I don't like the idea of being limited to a single way of doing something. I prefer the flexibility of choice, so I can tailor the code depending on the situation.

2. [Python] is readable.

The implication is that Perl isn't? I use perltidy on my code -- cleans the code up beautifully.

4. Perl has 'undef' but it isn't used much.

Really? I find undef quite useful, and use it often.

5. CPAN is nice but it is stifling to have to decide between 3 different modules that do the same thing.

So choice is bad?

7. No interpolation of strings

Really? That's a python *feature*? I quite like string interpolation myself.

10. Immutable data types

Perl has the Readonly module which lets you create variables that can only be initialized.

There are several Perl6 features that are available right now in Perl. But if Python's working for you, good luck with that.

My favorite Perl vs. Python quote:

"Python is basically executable pseudocode, and if that's the case, then Perl is executable line noise."

- Randall Munroe

1. "Code becomes a lot cleaner when there is one obvious way to do things."

   Perhaps. Sometimes it just becomes routinely frustrating. Its quite easy to have "one obvious way to do it" and "very dirty code", I see it all the time in PHP.

   Boilerplate code sucks.

   Also, analogies are like a box of chocolates. I could just as well say "This world would be a much better place if everyone could be forced to share the same sexual orientation".

   And what about people who are gluten intolerant?

   I do think Perl community needs a system of sorts to draw more focus to the obvious and recommended ways to do things, its a void that can be filled. Its not the abundance of choices that are the problem, its being unable to find the right choice for you.
   

2. Code readability I am convinced is perceptual. Two people will often disagree with how readable a given piece of code is. What your background is can also play big in this.

   Reading somebody else's code will always be some type of hell, and I've found things not even programming related that I've written and come back to 6 months later and wondered what the hell I was smoking.
   

4. I'd argue 'undef' is used far too much.

   It may not have been useful in your 5-line scripts or your one-liners, but it really is everywhere.

   Its actually a somewhat nasty convention of sorts for functions to return undef on failure, instead of something sensible ( such as Exceptions, but exceptions are a wart that are just starting to get attention in Perl now. )
   

6. The object model in Perl shouldn't be at all hard to use, it has in the past been a little weird in places to create things with it, but asides from that its very much like any other object model. And then we have Moose which is just plain sexy.

   package Person;
   
   use Moose;
   use MooseX::Types::Moose qw( :all );
   
   has 'name' => ( isa => Str, is => 'rw', required => 1 ); 
   has 'age'  => ( isa => Int, is => 'rw', required => 1 );
   sub stringify { 
      my $self = shift; 
      return sprintf "%s - %s", $self->name, $self->age;
   }
   
   1;
   
   package main; 
   
   use Person;
   
   my $person = Person->new( name => 'Kent' , age => 'old' ) ; # error, old is not an Int
   my $person = Person->new( name => 'Kent' , age => 25 ) ;
   
   print $person->stringify ; #  Kent - 25
   

• It went down while I forming this commoent
• Its horribly painful trying to get a code sample into a comment, a combination of being "too smart" and really "not smart enough".
• That bloody OpenID login thing keeps failing and telling me "invalid response", but after you poke it a few times you manage to log in -_-

Perl devs are not waiting on Perl 6. Some of the coolest innovations in Perl 6 have been ported to Perl 5.

2. It is readable...
Does an element exist in a hash (Python calls them 'dicts'): myelement in myhash

Perl has exists, which I would say is readable:

    exists $myhash{foo}

Perl regexes kick ass:

    /substring/

This is silly. This reminds me that in Python you can do False = 7; try it. Now all your code is broken :)

3. Parameter passing is awesome.

In Perl, you can have (via Moose and friends):

    method foo(Str $a, Int $b, Foo|Bar $c, $d)

5. "Batteries included".

I agree with you on this point. It is very convenient how python provides so many useful modules built in, like a http server and sqlite etc. Perl has a "light core" philosophy where they try to keep the core as light as possible and you have to grab what you need from CPAN.

7. No interpolation of strings. If you want to format something, there is a great formatting system which is highly optimized.

Python:

    print "Name: {0} {1}, Age: {2}".format(first_name, last_name, age)

    say "Name: $first_name $last_name, Age: $age"

My biggest gripe about python is it's lack of support for the functional programming paradigm. Python has broken or no support for anonymous functions (python lambdas really suck, and can only contain one statement), lexical scoping (only 2 var scopes in python that I know of, global and function), closures (can only close over objects, and with lack of support for variable scoping, who would want to use it).

P.S. Sorry for all the extra white space in the code examples. I used pre tags and they seem to add extra white space.

@Everyone: seems there is some weird HTML going on, if you want a code sample, you need to use <pre></pre>, except, you can't have any new lines in your <pre>, and you have to do them all by placing a <br> instead. ( no, not <br/>, that doesn't work ).

Also, your <pre> will probably get given its own paragraph automatically no matter what you do, with copious amounts of padding on top and bottom. Isn't the web great!?

Also, good luck getting 'inline' code to work.

The bulk of this post is an ennumeration of 10 features that you like about Python. Coupled with the fact that this post is titled "Python is better than Perl6", one might assume that the ten features you list are things that Python has and Perl6 doesn't have. But, in fact, Perl6 has eight of them, in spades. The exceptions are #1 and #7, "only one way" and "no interpolation of strings", respectively. (One could argue that these are the same "feature"). I think this philosophical difference is the only legitimate bone of contention in your post. It might've been a more instructive post had you developed it further.

(Mind you, I'm not only talking about the Perl6 spec. Rakudo, a Perl6 implementation that has been shipping "early adopter" releases for months, has 2-5, 8-10 right now.)

What I hear you saying is that a better title would be "I now like Python better than Perl6". I agree, on the other hand I feel like every post I make could be suffixed with "in my opinion" or "for my situation".

I'm not sure if you're addressing me, Tom, but if you are, you might want to read my post again. I haven't taken the "in your opinion, nyah nyah nyah" critique at all.

Until Perl does something about it's ugly dereferencing (mostly unaddressed in Perl6, AFAIK) it will always suffer in any comparison on the basis of legibility.

But with that said, a programming language that uses white space as a significant character is hardly the one to take up such comparisons against.

Further, there is, IMHO, a mistaken belief (inherited from COBOL?) that dropping symbolic notation and increasing verbosity (such as in your example of regular expressions) enhances readability. To the contrary, consider a paragraph in English written without punctuation, capitalisation, and such. Python code is a stream of alphabets (and a few symbols) which relies tremendously on indentation for human consumption. Languages with clear block demarcation (e.g: {}) OTOH are arguably not less, but more readable, because of the way the human eye scans text (code). (note: I am not in any sense an expert on human cognition!)

Whether choice/diversity is a good thing or not is to a large extent a matter of opinion and I am happy to let disagreements stand on that.

Begin idle and wild speculation:

I suspect however there is something deeper (than technical considerations) going on in the Perl/Python wars, and I think it has something to do with class and turf. Perl was (and is) the language of artisans, craftsmen, hackers: the type of person who is the first to explore a technology and enjoy getting his hands dirty in the process of creation. The experts -- credentialed programmers in our case -- step in later and formalise this world for expert consumption and use: no ugly backticks and pipe symbols that betray what's going on under the hood. No markers that immediately provide visual clues on the nature of an entity in its usage. So on. These abstractions are considered (and sold as) both a matter of professional necessity ("scalability", "extensibility", etc) and aesthetics. And the armies differentiate and face off on these lines (and a sort of war it is, or else we would all be writing code in PHP :-)).

With the exception perhaps of someone like you :-), with a hacker's heart and a programmer's aesthetic (or at least environment).

End idle and wild speculation.

BTW, as you most likely know, you can 'use constant TRUE ...;' etc.

There's one way to do things ??
Do not lie like a hypocrite

You can get values of dictionary in python.

a.get('key')
a['key']

convert a numeric value in list to string.

`a[1]`+'string'
str(a[1])+'string'

defining fucntion

def foo(): print("foo()")
def foo()
print("Foo")

etc...

There are already various ways to do even basic function.

See also: http://kfsone.wordpress.com/2010/11/30/take-that-python/

Okay, what's with all the hating in the comments (or am I misreading it)?

TMTOWTDI is one of the things I like least about Perl. Perl is comfortable in a lot of ways because it inherits a lot of stuff Unix hackers are already familiar with. But Python benefits a lot from being much newer, and having been invented after a decade or so of watching what people were doing with Perl and Java and Tcl and so on, and being able to avoid the pitfalls.

I like Python's active use of indentation as syntax because indentation is important for readability, and if it’s important then it should have to be right — it shouldn’t be possible for the indentation to lie to you. Of course, you could enforce both by requiring (say) braces and indentation, but that just makes it easier (rather than harder) to produce syntax errors.

PS — Had problems with the CAPTCHA, and the instructions you get when it matches didn’t work properly for me in Firefox 3.6.13.

Hi Tom,

I normally don't care when people move on to other languages or -is it so farfetched?- program in different languages. Depending on the task I have no problem moving between Perl en Java...

Nevertheless, I had some problems with the reasons on using Python (again, no problem with Python itself) are they are unfair to 2010's Perl.

I read this as the core of your post:
1. I want a cleaner OO.
2. A want a cleaner/consistent grammar.
(The hypothetical point 3 is more rethoric: Moderl Perl 5 is there for production.)

For point 1 we can be short: Moose ( http://search.cpan.org/dist/Moose/lib/Moose.pm ). I learnt Java because I didn't like the Python-copied Perl 5 object system (you read that right). After working with Moose, I miss it when working with Java OO.

If by "consistent" on point two you mean the importance of context in Perl, I recommend to download the freely available Moderl Perl book (http://www.onyxneon.com/books/modern_perl/index.html) and read 3 pages (page 6 on the A4 pdf, "The Perl Philosophy - Context") that explains what you need to know. Only 3 pages to clearly and verbosely explain a philosophy/feature says to me that it's not complicated at all.

Now for the "What I like about Pyhton" (and the implicit "What I don't like about Perl"):
1. You like TIMTOWTDI or you don't. However, this is very relative: there *is* more than way to do things on expressive languages, which include Python. And TIMTOWTDI doesn't mean that there is a preferred or superior way to do things (the community frowns upon bad practices). We have books that summarize the consensus: Perl Best Practices ( http://oreilly.com/catalog/9780596001735 ), the fantastic Effective Perl (2nd ed., http://www.effectiveperlprogramming.com/) from the same series that gave us the classic Effective Java and the already linked Modern Perl.
2. You want the same operator for hash key existence and substring matching in Perl? Let me introduce you to the smart match (~~) operator (http://perldoc.perl.org/perlsyn.html#Smart-matching-in-detail), that smartly matches a lot more of things than your examples.
TRUE and FALSE are a "use constant" ( http://perldoc.perl.org/constant.html ) line away.
3. See Moose above.
4. Is this Python's TIMTOWTDI?
5. You really underestimate CPAN. Choice may take some time when evaluating modules, but there is bigger chance you'll find the functionalities you need or are easily integrated. This is *certainly* not a disadvantage. Rails? Have -by example!- a look at Catalyst ( http://www.catalystframework.org/ ).
6. See Moose.
7. Why do you think string formatting is not highly optimized in Perl?
8-9. Again, the amazing Modern Perl book to the rescue (7 pages -including unicode!- starting on page 15, Values). Not so complicated at all (I find Java way more complicated on this regard). Modern Perl has good Unicode support.
10. This is also fairly trivial to enable in your code.

"In my entire career I've written more perl "quick scripts" (1 to 5 line single-purpose or single-use scripts) but I've now written more lines of "big programs" in Python than in all my Perl experience. (that's more of a comment about how few large programs I'd written in Perl, I guess :-) )."

I think that it's time to write big, OO and readable programs in Perl. You'll see that a lot of points do not apply. You may stick with Python, but you'll respect *Modern* Perl more.

Claudio

2.

use boolean;

# now you have true, and false defined.
# cpan is a wonderful thing.

Fredric -

print 'Name:', first_name, last_name + ', Age:' , age

As someone fairly familiar with both languages, I feel I have to defend Python from the Perl defenders a bit here.

I don't like the idea of being limited to a single way of doing something. I prefer the flexibility of choice, so I can tailor the code depending on the situation.
Python's "one way to do it" mantra isn't about forcing you to do anything; it's about deciding how to approach building the Python core, or suggesting how you ought to build your own APIs. There are indeed multiple ways to do pretty much anything in Python if you look hard enough, but duplicate functionality usually isn't implemented just because it can be. Even Perl usually has one best way to do it.

And this concern is really more about other people's code. Perl devs will yell at you for using a feature you'll regret, like two-arg open. Python devs will yell at you for using a feature other people will regret, like type-checking.

Perl has exists, which I would say is readable
Why is exists $foo{bar} different from $bar = $foo{bar}; exists $bar? Because that's a syntax hack to make "element of a hash" be a special thing for that lone function. Perl has a lot of these, and that's likely the source of complaints about its readability, even for well-written code.

Perl regexes kick ass
Not quite the same, since regexes have their own syntax and you may need to worry about escaping etc. The real equivalent is index $string, $substring != -1.

This is silly. This reminds me that in Python you can do False = 7; try it. Now all your code is broken :)
Sure. And in Perl you can do BEGIN { *CORE::GLOBAL::die = sub { 1 } } and have something like ON ERROR RESUME NEXT. So don't do that.

Until Perl does something about it's ugly dereferencing (mostly unaddressed in Perl6, AFAIK) it will always suffer in any comparison on the basis of legibility.
This is actually being significantly improved in Perl 5.14. You can now do push $arrayref, $new_element; same works with all the builtins on the appropriate type of reference.

Further, there is, IMHO, a mistaken belief that dropping symbolic notation and increasing verbosity enhances readability.
Dropping useless symbolic notation enhances readability, because there are fewer extraneous decorations lying around to distract you. The braces only mean anything to the parser; everyone else uses spacial cues.

In python you could never have something like this, without modifying the core language.
This is completely untrue. There are plenty of Python libraries that do clever things to the language; there are just relatively fewer because the language does enough in the first place. Traits, interfaces, multimethods, and whatever else have all been done. Usually without gratuitously modifying the language, either.

Really? I find undef quite useful, and use it often.
Do you use undef because it's genuinely useful, or because it happens to be a default in a lot of places?

Really? That's a python *feature*? I quite like string interpolation myself.
It moves string interpolation out of the syntax and into the standard library, which means it can be upgraded or replaced in the future, like happened with Python 3.

print "Name: {0} {1}, Age: {2}".format(first_name, last_name, age) / Really? You think the python way is more readable?
I imagine you'd usually do that as: "Name: {user.first_name} {user.last_name}, Age: {user.age}".format(user=user).

Or you could use the builtin string.Template class, which supports Perl-style dollar-sign interpolation.

So choice is bad?
No, but it can be overwhelming. You need to know which of thousands of modules will best "fix" Perl for you before you write a single line. strict and warnings to fix the syntax, Try::Tiny to fix exceptions, IO::Handle to fix filehandles, autodie to fix the standard library, Moose to fix OO...

Python has broken or no support for anonymous functions (python lambdas really suck, and can only contain one statement)
This is by design. Python's syntax doesn't really allow for sticking entire blocks inside an expression in any readable manner. But function definitions are locally scoped, so you can just define your function and then do whatever you want with it. Or use a decorator, which usually solves this sort of problem more readably.

lexical scoping (only 2 var scopes in python that I know of, global and function)
Yes, because variables are not declared. It's a minor gotcha but rarely a big problem.

closures (can only close over objects, and with lack of support for variable scoping, who would want to use it).
I don't understand this. Literally everything in Python is an object, so what else is there to close over? And a closure is, by definition, a function... which establishes a new scope in Python.

The experts -- credentialed programmers in our case -- step in later and formalise this world for expert consumption and use: no ugly backticks and pipe symbols that betray what's going on under the hood. No markers that immediately provide visual clues on the nature of an entity in its usage. So on.
Should I be offended by this? Python still has plenty of punctuation; just none that doesn't benefit the programmer. (Notice, for example, that Python always requires parentheses for a function/method call whereas Perl frequently does not.)

So what do we have here. Another "I wrote Perl a thousand years ago and I can't read it anymore. I wrote Python two minutes ago and still can read it. This proves: All Perl code is unreadable, all Python code is readable."

Sure, a Perl one liner like this is hardly readable:
perl -e '@_=(0110,0101|010<<0<<1<<0<<1,1<<1<<1<<0<<1<<1<<1<<0<<1|11*1<<1<<1,0110|0100>>1|1<<1<<1,111,11*010>>1,010*1<<1<<1,11*010-1,101,(0100<<1)-(010<<1|010>>1),(11>>1)+111,(1<<1<<1<<1<<1<<1)+1,010+(1<<1));printf"%c"x@_,@_'

Then again, use Python and it all becomes clear:
python -c "_1=(0110,0101|010<<0<<1<<0<<1,1<<1<<1<<0<<1<<1<<1<<0<<1|11*1<<1<<1,0110|0100>>1|1<<1<<1,111,11*010>>1,010*1<<1<<1,11*010-1,101,(0100<<1)-(010<<1|010>>1),(11>>1)+111,(1<<1<<1<<1<<1<<1)+1,010+(1<<1));print '%c'*(0011|1<<1<<1)%_1"

I'm fascinated. From the way the perl defenders have started jumping up and down, one might imagine that someone had called them all donkeyfiddlers, rather than simply stating that his own preference of scripting language had changed. What is this human need to take the different choices of others as some kind of personal slight? Isn't it good that we all like different things? And isn't it silly to think that someone who likes different stuff from you is "wrong" - especially when that someone has had longer to make up his mind about it than you've been capable of focusing your eyes?

Python has one fatal flaw: datatypes.

$ python
Python 2.6.6 (r266:84292, Sep 15 2010, 16:22:56) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 1/2
0

People do not think is terms of datatypes. Go ask anyone how to multiple a number by 10. They'll say, "Add a zero to the end." That is not arithmetic, that's string manipulation. People easily switch from one to another. Any language that does not allow this without special converting functions, is seriously flawed.

Another flaw

In Ruby
a = { 1 => 'a', '1' => 'b', 1.0 => 'c', 1.1 => 'd' }
puts a[1]
puts a['1']
puts a[1.0]
a
b
c

In Python
a = { 1 : 'a', '1' : 'b', 1.0 : 'c', 1.1 : 'd' }
print a[1]
print a['1']
print a[1.0]
c
b
c

Why python do not distinguish between key types ?

Because you should be forced to use python in your company, please do not condemn perl which you once loved to justify yourself.

Python 3.1.3 (r313:86882M, Nov 30 2010, 09:55:56)
[GCC 4.0.1 (Apple Inc. build 5494)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> False = 7
File "", line 1
SyntaxError: assignment to keyword
>>> 1/2
0.5

Take a look at http://mojolicio.us if you want to see a truly awesome Perl web framework!

So I have been a perl guy since 1996 or so, with Perl 4, and my main job involves writing lots of perl. I like perl, but recently I started my own personal project, and someone told me to look into Django, and I have been loving that.

So to use django, I had to learn python, which turned out to be really easy. Being an experienced programmer, I already had all the concepts, it was just a matter of finding the "python way" of doing it. There being one way to do most things, and all those "batteries included" certainly did help in being sure I found the right answer quickly.

I would say not having "batteries included" is probably perl's greatest weakness while also being in a way its greatest strength.

Its a weakness because you need to be kind of in the know about which CPAN package is currently considered the best to do something, and you need to gather all those up to start doing work. It would be nice if the perl standard library were bigger, and included more in the way of dealing with common internet data types, like URLs, object oriented wrappers for arrays and hashes, etc, etc. There are lots of crappy modules in CPAN sitting right next to some amazing ones, and it can he hard to tell what to use and what is a waste of time. A little editorial control to give everyone a common base to work from would go a long way towards making it easier to find answers. It also would give a common place for other modules to then build from. I find so many modules might contain some really useful internal bit which they don't expose in their API, and this just means there is duplication of effort going on. Also if you pick the wrong module, you may not realize its wrong for you until you are rather deep into your project. Not good.

Its a strength for all the reasons we go around talking about capitalism and market forces as what will save us all. These concepts are based on their being choice limited only by effort, and a low barrier to entry. Modules can compete to become the module of choice, and many modules are falling in and out of fashion over time. The language itself (the government in this analogy) tries to just provide the building blocks, and when those building blocks may be rudimentary, ugly, or incomplete, some module steps in and does the magic needed to create some useful higher level thing. Moose is probably a perfect example. It does stuff that is usually defined in the language in most other languages, but is super ugly (but flexible) to do directly in stock perl. Since its a module, you can see how it does it, and extend, patch, or even roll your own. When something like Moose does it well and most of us agree, its wonderful, but when that doesn't happen, you can feel a bit lost.

And here Python sometimes falls short. When I wanted to find how to filter an array to only have unique items but keep its order, I found a ton of different code samples, but no module I could just install and use its API without worrying about how it did things. This is kind of the converse of the "code locked up inside modules but not in the API" problem. No language can anticipate everyone's needs.

However I still think perl needs a little more "government", a bigger set of central standards defined as a standard base of official modules that work together in a consistent way. Perl 6 does seem to address this somewhat, but Perl 5 will be what we are all using for the next several years still. Perl does need to get some of its "cool" back, and learn from what is going on in python and ruby, and do it in perl 5 with an eye to 6.

Overall, I have been finding python to be a little more enjoyable because of the consistency. I find that I can write code more clearly and quickly usually. Methods are usually smaller, because I can organize functionality into discrete bits better, because the language and its apis tend to do that too, and it is inherently object oriented.

Really every language has its strengths and weaknesses, and you need to always consider the right tool for the job. Some of these comments get into really picky technical differences, and that sort of misses the point. All languages have a lot to learn from each other, and I think as a programmer, being versed in a few gives you new perspective to improve what you do and find ways to reduce effort in whatever language you are writing in at the moment. I'm not a purist. I want to learn all I can that will let me do more, better, with less effort, wherever I find it.

I began using perl around the same time as the author. Can anyone tell me why python does not have any kind of "use Strict" construct? I've never heard a convincing argument that we don't need "use Strict".

The proper way to use format:

"Name: {first_name} {last_name}, Age: {age}".format(first_name='Bob', last_name='Bobson', age=55)

You missed one big advantage in Python: error handling. All Python runtime errors are typed exception objects that can be easily managed with try/except/else/finally/raise. This feature alone has saved countless development hours and has lead to more robust, easier to debug software.

another python better than perl, please read
Python

hi,
interesting article about perl 6. I want to add a statistic about the usage of perl on web development (despite I am a perl fan!):

http://trends.builtwith.com/framework/PHP

I am confused, not to find python in the graphic below!

I don't think Python is more readable than good, clean Perl code.

Good, clean Python code looks very monotonous, regular, and because of that it makes me sleepy.

Perl code OTOH has lots of markers (i.e., "%", "$", "@" etc) that pack a lot of abstraction, syntax and semantics. It helps guiding the eye and the mind...

Honestly, how many Python programmers took the time to read Conway's object-oriented programming in Perl?

http://www.manning.com/conway/

The usual "there's ONE way to do it, and it's best to work in teams that are FORCED to write programs these way" doesn't look to me as being something thoroughly thought-out. Here's why: Perl doesn't force you to bondage & discipline (we all agree to that), like Python or Java. But maybe this perception that B&D is so vital to "coding in the large", to the point that you have to cripple a language, is a large-organization problem, where they find it's best to lay out some coercive practices (particularly for the noobs). Or maybe it's a problem with SOME large organizations that don't set out rules for coding style, etc. Python's and Java's B&D would be time-savers according to that line of thinking.

However, I don't believe any B&D argument holds any water. C programmers were forced to "best practices" by their software houses ever since C was invented. Maybe some organizations don't want to spend the time necessary to lay out those standards (hehe, NASA does...). This says much more about the organization than about the language. So any argument extolling The One Way To Do It against TIMTOWTDI is a non-sequitur ("Good code is clean code. Python has clean code. Therefore, code in Python is good.") It's astroturfing from big corporations ("EVERYBODY wants B&D". Well, not everyone enjoys the code-monkey role that sucks the creativity out of you). Besides, all languages end up requiring work-arounds, since none of them are perfect (not even Lisp, Smalltalk, or D).

Additionally, everyone says stuff like: "Lisp/Smalltalk/Perl" work only for small teams, but the fact of the matter is that TODAY, because of distributed source control (git etc.), small teams are the ONLY type of teams that MATTER, because you are supposed to stick to your own specialist turf, and because large projects are in fact a big tree made of...small teams.

Now, I will say that I do like the repl in Python, but in all honesty I think Python's "there's only one way to do it" speaks more about the limitations Guido has as a programmer (there seems to be a consensus about this) than any real valid argument...

Is Python 3 a radical departure from the Python 2, like Perl 6 is from Perl 5? Nah. What does this tell you?

>> "Name: {first_name} {last_name}, Age: {age}".format(first_name='Bob', last_name='Bobson', age=55)

I can see how "format" shows why "use strict" is impossible to implement. I cannot see how "format" diminishes the need for "use strict". It might be that "format" demonstrates an intensely unfortunate grammar in an otherwise well conceived language

Regarding: Conway's object-oriented programming in Perl

This irreplaceable book has a copyright of 2000.

Has anyone heard of Damian updating it for Perl 5.12?

namrokretep, I'd suggest that Moose has rendered at least some of Conway's book less relevant. I'd recommend the "Objects" chapter of chromatic's "Modern Perl" as perhaps the best current replacement.

I do numerical programming (read: I am not a sysadmin) and Perl+PDL is my language, with C for the heavy lifting on the rare occasion when it's necessary. I love it and I have not experienced most of the trouble you had with Perl. However, my experience learning Perl indicates a weird role reversal for Perl, and is corroborated by the comments of others here.

In a nutshell, I would say that Perl's problem is that there really is only one way to *learn* Perl, and that way is to read books. The summer I decided to learn Perl, I read the Camel Book and Perl Best Practices and I've never had trouble knowing the weird corner cases. In fact, I love those corner cases because they are useful, fun, and occasionally expressive. Isn't it ironic that if you ask perlmonks the best way to learn perl, they all respond with a list of books? Is this the one not-necessarily-obvious-to-an-outsider way to learn Perl?

And how does one learn Python? Beats me. I've never tried, but I suspect there are many good sources out there. Wouldn't it be odd if my suspicion is correct, that there is more than one (good) way to learn Python, and there is only one way to learn Perl?

I can stand how when someone finds a language they "prefer" then it must be "better". Choice is a good thing. I use Perl, not that there's anything wrong with other languages, but it's what I prefer. Just pick the language you like and STFU about it.

Gr8 article and corresponding replies !!
I like u all guys. I wud want to say this:
1) Perl is faster than python
2) Perl is uglier than python
3) Python is a crap of ideas thrown in irregular fashion. Amazing that it became the language of choice for many.
4) Ruby is the coolest one around but has no proper libraries.

What i need is a language that is clean, having lots of libraries, caters GUI, multicore processing, enterprise tier web apps, proper reflection. Perl caters all of these well but still is confusing with idiotic $,@,# etc. symbols. Since, I have no other language that does these, I am still with perl.

Cheers.

Have you considered Haskell?

name = "bill"
age = 30
print "name: %(name)s age: %(age)s " % locals()

I am also learning Python from a Perl background. Your arguments should ring true to me, but unfortunately they do not. Is "in" really that more readable than "exists"? Even if you regard it to be, surely that's subjective.

I do a lot of unicode processing and I'm happy to say that Python 3 is finally starting to catch up with Perl in that regard. It just doesn't really work yet in practice with all the third party code out there. But I really think you got the unicode argument backwards.

Objects are very simple and logical in Perl (I recommend the OO-Perl book), but way too verbose. Moose fixes most of that and brings accessors and other things that Python doesn't really match.

Here's what I like about Python (compared to Perl):

A more simple language with less corner cases. The fact that it's slightly more typed than Perl requires less magic. Datastructures becomes much nicer when you don't reference everything all the time. Integration with C becomes even easier.

Here's what I dislike:

The weird mixture of methods and functions in the standard library, that's just barking mad. Unicode, but it's getting there. I also think the indentation thing gets in the way because you need to mark empty blocks, and closures (lambda) could have been nicer.

But they fill the same niche among the modern scripting languages. And I think your comparison is misguided, especially when bringing Perl 6 to the mix. Most languages are better then Perl 6, and nobody expects it to take over from Perl 5 which will live on.

Python just makes me happier and excited about writing code again. BTW, Catalyst is a Perl framework that's quite similar to Django/Rails.

Coming from a Perl background, and programming using Python recently:

1) One way to do it has serious advantages.
If I pick up a module from pypi I can almost always use it without much effort. CPAN modules always seem to entail significant hassles digging through badly written documentation to figure out how the developer thought you ought to present your information.
Python doesn't seem to suffer from that.
The ability to run a python shell and explore objects through the dir() function is incredibly useful too and has saved me untold amount of time in development.

It's not saying there is only one way to achieve the ultimate goal, just that there is one way to use an object, etc. and that leads to much cleaner and more legible code later on down the line. Being a sysadmin I'm routinely coming across scripts written by predecessors (and even my own old scripts). It's remarkable the difference in effort required to read one of those perl scripts compared to reading an old Python, even though I'm reasonably capable of parsing regex.

2) XML API work is a lot less painful. I've written numerous scripts in perl that operate with APIs and I've hated almost every minute of it.
Python on the other hand has proven to be a real dream, it's the first time I've had XML API code 'just work' on first attempt and only flaws in my process to iron out.

3) It's the first language I've actually enjoyed programming in. With Perl, PHP etc. it has always felt like I was wrestling with a tiger, eventually getting it to do exactly what I want, be it language quirks, library quirks or whatever.
Python hasn't been like that at any stage of the process, and it's to the point where I'm actually spending good chunks of my free time just working on random little projects which is something I've never really done.

All that said, perl has been my primary scripting/sysadmin language for a number of years now and it's still what I'll first dip to for quicky scripts!

Well I say try writing proper programs in Perl and then you would learn that Perl is far more capable than Python. I recently had to use Python for a project and there were a lot of things I liked, but time and time again I found myself saying if only they had thought this through. Python is a nice idea, badly spec'ed and not brilliantly executed. Some points include:

- Syntactic white space, {} make for more readable code. That is just a fact for maintainers - also good indentation.
- Limited variable scoping, local variables exist until you exit the function and not the containing block!
- Don't declare them up front, leads to ambiguity and errors that are only detected at run time rather than compile time, makes testing for correctness harder.
- Unreliable destructors. CPython they work as expected, they are called as soon as the object goes out of scope. Jython they are not. Reliable destructors are a really useful feature in an OO language, that is why Python and Java OO suck. If you think otherwise you, I am afraid, are just plain wrong. Look at what you can do in C++ by using reliable destructors and enforcing contracts (like mutex scope based locking).
- No data privacy!
- Closures over variables not working as expected (need object/container).
- No proper anonymous functions.
- Non-standard print formatting. Printf() style stuff is normally good enough, if not then extend it rather than completely start afresh - so tiresome otherwise.
- I like having different ways of doing things. Different horses for different courses. Doesn't mean as a developer you have to use all of them.

There are plenty of really good things about Python but the above are killer points that stop it from being a practical language that I would want to use. A pity as it is more readable than Perl and Perl 6 is getting worse in that respect.

If Python works for you then fine use it. Perl is also a knock out language. I have developed 20-30000 line applications in Perl and found it to be one of the most reliable, productive, forgiving and flexible programming language I have ever used. Python would be even better if they addressed most of the above points.

Happy coding.

Tony.

Um, at the end there, your said you cannot continue lines in Python. Well that's not true.
All you have to do is this:
print ("I'm pretty sure", end = " ")
print ("this is is a website.")

Of course, that is only Python 3...

Love

Everyone keeps saying that the Python philosophy is "there is only one way to do things". I can't believe this has never been corrected. The Zen Of Python states "There should be one, and preferably only one, OBVIOUS way to do things."

All this talk about being forced to do something are strawmen. What you have in Python is one, simple, clear, straightforward approach instantly springing to mind is almost every case. This means that Python code is more readable to others because even with different programmers they've most likely taken the same approach.

There is no denying that Python is preferred by many programmers.

It obviously has something going for it -- unfortunately, I found your reasons difficult to follow. Most of the stuff you list that Perl cant do is not true, and even some points (eg string interpolation) are insane.

So, (i) you like Python better, AND (ii) you have failed to identify why ... I am sure good reasons exist -- they are just not in your post.

If I had to guess (it is a guess) ... is that the many-different-ways principle of Perl makes it harder to set standards when building large programs. Try using Moose for these. In any case, the real beauty of Perl is that you almost always never need to write big programs ... just use CPAN or qx/native_os_exe/ ... it's a beautiful platform for glueing stuff that is already there anyway.

The best rule of thumb I've seen on this topic:

less than 10 lines - use shell code
10 - 100 lines - use perl
> 100 lines - use a real programming language

My $.02 here of course:

I agree with you completely on #2, #3, and #6.

You are a total crackhead on point #8.

The rest I don't think are a big deal, and it is was a complete waste of time to re-invent the wheel and make a whole new language. Data structures on Python are terrible -- if there is one thing to keep from perl it is the simple scalar/array/reference model.

And, of course, it is obvious now that Python jumped the shark with python3 -- completely destroying your argument #1. Every Linux distro will have to ship both python2 and python3 for the rest of eternity.