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!
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.)
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.
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.
7 comments
[ 2.4 ms ] story [ 25.3 ms ] thread(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!
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.)
(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:
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:
That lambda you typed in in the python shell is gone forever, which IMHO defeats the purpose of having a REPL.Yep.
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