

Python vs. Perl vs. C++ - Python is Better - pankratiev
http://www.strombergers.com/python/

======
jrockway
I have one. Let's write a REPL in Python:

    
    
       result = eval string
       print result
    

Wow, so easy. Except it doesn't work when string contains "import foo". OK,
that's fine, we can "exec" instead of "eval". Oh, but then we don't get the
return value anymore.

(The Python solution to this is a flag to pass to exec to tell it to print the
result to stdout. If you want to capture the object that's the result, well,
too fucking bad. I did this in my Python REPL with an AST rewrite of the
user's input. What the fuck!?)

In Perl, you can `eval $string' and the return value is the return value of
the code you just ran. And any Perl works!

I've never written any Perl that looks like what this article uses. If I want
to slurp a file, I say "my $file = read_file('path/to/file')". read_file comes
from File::Slurp. If I want to do strict validation of the arguments to my
function, I just use Params::Validate (or MooseX::Declare if my blood sugar is
low). (Why do you care about number of arguments but not type of arguments? So
you get an obscure error when you try to use "1" as a hash?) Perl has classes,
Perl has exceptions. If you say it doesn't, like the author of this post, you
don't know anything about Perl.

So my point is, it's easy for fanbois to hand-pick examples of why a language
is bad, especially when they don't even know the language. It's all very
simple in practice: to program well in a programming language, you have to
learn the language. Try not doing that, and you will fail, even if that
language is Python!

~~~
jerf
Python has Perl beat on the REPL loop out-of-the-box:
<http://docs.python.org/library/code.html#>

    
    
      Python 2.7.1 (r271:86832, Mar 14 2011, 00:19:31) ...
      Type "help", "copyright", "credits" or "license" for more information.
      >>> import code
      >>> code.interact()
      Python 2.7.1 (r271:86832, Mar 14 2011, 00:19:31) 
      [GCC 4.4.4] on linux2
      Type "help", "copyright", "credits" or "license" for more information.
      (InteractiveConsole)
      >>> import this
      The Zen of Python, by Tim Peters
    
      Beautiful is better than ugly.
      Explicit is better than implicit.
      ...
    

And there are a variety of ways to extend it with various input and output.
Much easier and more flexible than anything Perl will offer without a CPAN
module. Which is probably out there.

That said, while I agree with this guy's conclusion his arguments are mixed in
quality, trending towards poor. I like Python better, but my professional
coding is primarily Perl and has been for nearly a decade now. Many Perl code
snippets I looked at had a fatal flaw in it that made Perl look worse than it
actually is, or the putative improvement that Python has is a judgment call
rather than a good reason. And the reasons I _actually_ like Python better are
mostly not to be seen, except for the "classes" one.

(Reasons: The "double underscore" methods may have notoriously bad names, but
they work better and more reliably over the last decade than Perl overloading
has for me, you can't do more than badly fake Python iterators in Perl 5 last
I knew, trivial and across-the-board ability to use arbitrary objects as dict
keys, more sensible Unicode handling in Python 3. __str__ and __repr__;
Dumper/say is no replacement. And for all the putative benefits of Perl's
various syntaxes and sigils and for all that I've programmed in Perl about an
order of magnitude more than I've programmed in Perl it's Python features I
miss in Perl and _never_ vice-versa. Locally everything in Perl makes sense,
yet somehow the global combination of all these locally-slightly-better things
does not produce a better language, just a larger one. But Perl's still on the
short list of languages I can stand to use.)

~~~
jrockway
If you're not willing to use CPAN, there is no point in using Perl.

(Incidentally, have you ever read code.py? Very inflexible and largely useless
except for the exact purpose it's implemented for, a terminal-based REPL with
no history or tab completion.

I needed to write something like this:

<https://github.com/jrockway/stylish-perl>

for Python, and simply couldn't do it without a clever AST rewrite, which
added the equivalent of __result__ = <whatever they typed in that can be an
rvalue>. Then it was all easy, although it still doesn't quite work right (but
I feel if I knew what I was doing and cared, it could be fixed).

As to why stylish-python is not on Github; I wrote it for "work Python"
instead of real Python. Yes, we have a fork of Python 2.6 that uses an
internally-developed Redis clone to store the source code instead of files.
This was not my idea and I did not write any of the code :) (Writing your own
database and your own IDE is a lot more fun than writing ETL code, I guess.)

Also, with respect to repr vs. Data::Dump::Streamer, I'll just paste the
following REPL sessions:

    
    
        [~] 0 (jon@snowball2)
        $ python
        Python 2.6.6 (r266:84292, Dec 26 2010, 22:31:48)
        [GCC 4.4.5] on linux2
        Type "help", "copyright", "credits" or "license" for more information.
        >>> repr(lambda (x): return x)
        '<function <lambda> at 0x7f6103dda668>'
        >>>
    
        [~] 0 (jon@snowball2)
        $ re.pl
    
        $ sub { my $x = shift; return $x }
        $CODE1 = sub {
                   package Devel::REPL::Plugin::Packages::DefaultScratchpad;
                   use warnings;
                   use strict 'refs';
                   my $x = shift @_;
                   return $x;
                 };
    

Note how DDS can represent all of Perl's data structures, not just some of
them. You now know that you have the identity function instead of a function
at memory address 0x7f6103dda668. I guess Python programmers don't care
because everything has a name.

Also, with re.pl, you can do this later on in your session:

    
    
        $ $CODE1->(42)
        42
    

That lambda you typed in in the python shell is gone forever, which IMHO
defeats the purpose of having a REPL.

------
davvid
The biggest problem with Python is performance. It doesn't do threads. The GIL
is a real bummer.

Even when you use the threading module it's very common to load up the system
monitor and see only 1 core out of 12 being used. :-/

Performance problems aside, it's a pleasant language and the stdlib is well-
designed.

This comment from earlier this week pretty much sums it up:

"Why can't you make Python faster!?" Because Python does a lot of stuff
without you asking.

<http://news.ycombinator.com/item?id=2393696>

------
tzs
I can't tell if this is meant as an April Fool's joke.

