6 ms·

> In contrast, Python encourages the creation of monoliths of the type McIlroy criticized. unfair and gratuitous criticism of python... i have seen and written

> In contrast, Python encourages the creation of monoliths of the type McIlroy criticized. unfair and gratuitous criticism of python... i have seen and written many small tools you can run using "python -m".

btilly 7y ago
As someone who uses both languages extensively, I disagree. You are right that Python is great for writing small tools that you can run, just like Perl. But Python does not lend itself to writing them inline in a command line like was done here. Perl not only does, but has a number of useful features specifically added to fit this common use case. 3 of which were used in this example. (-a for autosplit, -M to load a module, and -e to have the code passed as an argument on the command line rather than having to have it saved to a file.) Secondly, Perl lends itself to being used as a "better shell" while Python does not. What I mean is that anything that can be written in bash can be trivially rewritten in Perl, and the program that you get tends to be substantially more maintainable if the bash script is at all complex. In such a rewrite there usually isn't a good reason to change the structure of the program and make it into a single Perl program. By contrast Python has focused on the "One True Way" to do things, and the plumbing work for calling external commands is just verbose enough that a Python rewrite of a bash script is not necessarily better than the bash script. And furthermore it is much more likely that the Python rewrite of the bash script is much better rewritten as a Python script. The result is that for someone who lives on the Unix command line, Perl integrates into their world better than Python does. If you have never lived on the Unix command line, the objections may sound silly. But spend months typing commands and doing the extra steps that Python requires Every Single Time will get old. (This is historically not surprising. Perl 1 was focused on generating text reports. Perl 2 moved into being a sysadmin tool. Perl wound up as a web language because it is what all of the sysadmins recommended for text manipulation to people writing early CGI scripts.)
- codetrotter 7y ago
  I use a few different languages, one of which is Python, and I use the command line a lot, and I agree that Python is too verbose for a lot of the things that I do on the command line. Therefore, Python is not something that I reach for when doing simple tasks involving pipelines and/or file operations. I have not yet put time into learning Perl. In no small part because I was intimidated by the weirdness of some of the Perl code that I've seen. The terseness that Perl allows, and which I desire, is at once compelling and scary at the same time. For this Perl also has earned the reputation that it "Write Once, Read Never". But let's assume that I overcome my fear of Perl. Which version of Perl would you recommend that I learn? Perl 5 or the language formerly known as Perl 6?
  - setpatchaddress 7y ago
    Ruby is the best version of Perl. You can do command line one-liners and full-on object-oriented (SmallTalk object model) readable, maintainable programs.
    - btilly 7y ago
      My impression 20 years ago was that Ruby is an interesting mix between Perl and Python. In principle there is little that differentiates Perl and Ruby in terms of how maintainable or not their code can be. However the Ruby ecosystem wound up with a lot of modules contributed by people who had just moved to it from languages like Java. They overreacted to their new found freedom. The result is that between a poor testing story and questionable practices like "monkeypatching" (literally modules overwriting random methods in other modules) the Ruby ecosystem wound up with a lot of nasty gotchas. (There is a lot of, "f you load module A then B, it works, but module B then A and it doesn't.") Yes, Ruby programmers get up in arms when you say that they have a poor testing story. But ask them whether by default they have actually run unit tests for everything installed on their system, and they have not. Ask them if they could run unit tests and they think they can. But those who I have watched try have found out the hard way how many unit tests were only written for the original author to run in the original environment, and can't easily be run in an automated way. By contrast the default for CPAN is that every module has had its unit tests run on every system it is installed in, and automated smoke tests ensure that modules have had their tests run on a wide variety of operating systems and versions of Perl. The result is that random Ruby module X is generally less likely to be dependable than random Perl module Y. Which in turn means that in my experience significant Ruby code bases written by competent programmers top out at smaller than Perl, with worse maintenance stories. That doesn't discount the fact that there has been a tremendous amount of unmaintainable Perl written by incompetent programmers. (Particularly during the wild dot com days.) But "maintainable" is NOT something that Ruby has a good story to tell about.
  - btilly 7y ago
    Learn Perl 5. Perl 6 is an interesting research project for future directions that it doesn't look like the programming world will go. Most of the weirdness of Perl goes away when you read $ as "the", @ as "these" and a hash lookup as "of".
- ben509 7y ago
  Perl's big win for one-liners is braces syntax. Interestingly, there are already projects to add braces syntax[1]. Two of the three Perl features are also Python features, namely -m to run a module and -c to run code on the command line. Regarding Perl being a better shell, there are modules like `doit` and `invoke` that make Python far better than perl for managing jobs, precisely because they make forking off jobs super easy. But now that you mention it... I want to write a module to make python one-liners easy. [1]: https://pypi.org/project/brackets/ https://pypi.org/project/brackets/
  - gerikson 7y ago
    Can you show an example of using doit and invoke to fork off jobs in Python? I’m pretty sure Perl has had similar functionality for some time.
    - ben509 7y ago
      Yeah, perl borrows backticks from bash[3], so it's giving you syntax to do it directly, and it's long had strong support for opening a process using a very intuitive syntax. Python's subprocess module works quite well, but gets extremely verbose[4] as you try to do anything more complex than "run a command and get the output" and has some nasty gotchas[2]. I forget the invoke syntax, but doit[1] is basically a make replacement so calling the shell is pretty easy: def task_something(): return {'actions': ['ls foo/', 'rm -r foo']} And you can use outputs from one task as inputs for another, it tracks what's been done, etc. [1]: https://pydoit.org/ https://pydoit.org/ [2]: https://docs.python.org/3/library/subprocess.html#subprocess.Popen.stderr https://docs.python.org/3/library/subprocess.html#subprocess... [3]: https://perldoc.perl.org/5.30.0/perlop.html#qx%2f_STRING_%2f https://perldoc.perl.org/5.30.0/perlop.html#qx%2f_STRING_%2f [4]: https://docs.python.org/3/library/subprocess.html#popen-constructor https://docs.python.org/3/library/subprocess.html#popen-cons...
      - gerikson 7y ago
        How can one do something like fork/exec in python? That's what I was thinking of when you mentioned "forking off jobs". There are a number of different ways to launch an external process from Perl, I think this StackOverflow answer summarizes them quite well: https://stackoverflow.com/a/800105 https://stackoverflow.com/a/800105 I'm an experienced Perl user, but I'm not as familiar with Python. In addition, I'm not really using Perl for sysadmin stuff, so I tend to try to keep stuff "within" Perl. As an example, I'd rather use the File::Find module than use backticks to invoke `find`. This has really nothing to do with functionality - I'm almost always on Linux, and the syntaxes are similarly hairy - it's just that usually you get more powerful functionality using the Perl functionality. (edit rearranged paragraphs)
- jimbokun 7y ago
  How does Ruby compare to Perl and Python for these tasks?
  - btilly 7y ago
    Ruby is about equal to Perl as a language for interactive command line usage, and both are better than Python. Comparing RubyGems to CPAN, CPAN is about 2x as large, has a better infrastructure, better testing, and is generally better. Comparing CPAN to PyPI (the Python version), they are about the same size, PyPI has a worse testing story, has more up to date modules, is growing faster and seems to be of similar quality. If you want write a system that integrates with a recent standard, support from Google, or to use something like machine learning, Python is the clear winner. Adding JavaScript, I consider node.js to have the worst command line story, worst repository system, but it is extremely popular. I personally use Perl for command line stuff and Python otherwise. I use JavaScript when I have to (and sadly I have to a lot). It is rare for me to bother with Ruby. But I learned Perl first, and have written more in Perl than the others combined. Does this answer your question fully?
ptx 7y ago
Perl starts up really, really fast though, so invoking it repeatedly in a pipeline is more practical than with a Python program for that reason.

btilly 7y ago

As someone who uses both languages extensively, I disagree. You are right that Python is great for writing small tools that you can run, just like Perl. But Python does not lend itself to writing them inline in a command line like was done here. Perl not only does, but has a number of useful features specifically added to fit this common use case. 3 of which were used in this example. (-a for autosplit, -M to load a module, and -e to have the code passed as an argument on the command line rather than having to have it saved to a file.) Secondly, Perl lends itself to being used as a "better shell" while Python does not. What I mean is that anything that can be written in bash can be trivially rewritten in Perl, and the program that you get tends to be substantially more maintainable if the bash script is at all complex. In such a rewrite there usually isn't a good reason to change the structure of the program and make it into a single Perl program. By contrast Python has focused on the "One True Way" to do things, and the plumbing work for calling external commands is just verbose enough that a Python rewrite of a bash script is not necessarily better than the bash script. And furthermore it is much more likely that the Python rewrite of the bash script is much better rewritten as a Python script. The result is that for someone who lives on the Unix command line, Perl integrates into their world better than Python does. If you have never lived on the Unix command line, the objections may sound silly. But spend months typing commands and doing the extra steps that Python requires Every Single Time will get old. (This is historically not surprising. Perl 1 was focused on generating text reports. Perl 2 moved into being a sysadmin tool. Perl wound up as a web language because it is what all of the sysadmins recommended for text manipulation to people writing early CGI scripts.)

codetrotter 7y ago
I use a few different languages, one of which is Python, and I use the command line a lot, and I agree that Python is too verbose for a lot of the things that I do on the command line. Therefore, Python is not something that I reach for when doing simple tasks involving pipelines and/or file operations. I have not yet put time into learning Perl. In no small part because I was intimidated by the weirdness of some of the Perl code that I've seen. The terseness that Perl allows, and which I desire, is at once compelling and scary at the same time. For this Perl also has earned the reputation that it "Write Once, Read Never". But let's assume that I overcome my fear of Perl. Which version of Perl would you recommend that I learn? Perl 5 or the language formerly known as Perl 6?
- setpatchaddress 7y ago
  Ruby is the best version of Perl. You can do command line one-liners and full-on object-oriented (SmallTalk object model) readable, maintainable programs.
  - btilly 7y ago
    My impression 20 years ago was that Ruby is an interesting mix between Perl and Python. In principle there is little that differentiates Perl and Ruby in terms of how maintainable or not their code can be. However the Ruby ecosystem wound up with a lot of modules contributed by people who had just moved to it from languages like Java. They overreacted to their new found freedom. The result is that between a poor testing story and questionable practices like "monkeypatching" (literally modules overwriting random methods in other modules) the Ruby ecosystem wound up with a lot of nasty gotchas. (There is a lot of, "f you load module A then B, it works, but module B then A and it doesn't.") Yes, Ruby programmers get up in arms when you say that they have a poor testing story. But ask them whether by default they have actually run unit tests for everything installed on their system, and they have not. Ask them if they could run unit tests and they think they can. But those who I have watched try have found out the hard way how many unit tests were only written for the original author to run in the original environment, and can't easily be run in an automated way. By contrast the default for CPAN is that every module has had its unit tests run on every system it is installed in, and automated smoke tests ensure that modules have had their tests run on a wide variety of operating systems and versions of Perl. The result is that random Ruby module X is generally less likely to be dependable than random Perl module Y. Which in turn means that in my experience significant Ruby code bases written by competent programmers top out at smaller than Perl, with worse maintenance stories. That doesn't discount the fact that there has been a tremendous amount of unmaintainable Perl written by incompetent programmers. (Particularly during the wild dot com days.) But "maintainable" is NOT something that Ruby has a good story to tell about.
- btilly 7y ago
  Learn Perl 5. Perl 6 is an interesting research project for future directions that it doesn't look like the programming world will go. Most of the weirdness of Perl goes away when you read $ as "the", @ as "these" and a hash lookup as "of".
ben509 7y ago
Perl's big win for one-liners is braces syntax. Interestingly, there are already projects to add braces syntax[1]. Two of the three Perl features are also Python features, namely -m to run a module and -c to run code on the command line. Regarding Perl being a better shell, there are modules like `doit` and `invoke` that make Python far better than perl for managing jobs, precisely because they make forking off jobs super easy. But now that you mention it... I want to write a module to make python one-liners easy. [1]: https://pypi.org/project/brackets/ https://pypi.org/project/brackets/
- gerikson 7y ago
  Can you show an example of using doit and invoke to fork off jobs in Python? I’m pretty sure Perl has had similar functionality for some time.
  - ben509 7y ago
    Yeah, perl borrows backticks from bash[3], so it's giving you syntax to do it directly, and it's long had strong support for opening a process using a very intuitive syntax. Python's subprocess module works quite well, but gets extremely verbose[4] as you try to do anything more complex than "run a command and get the output" and has some nasty gotchas[2]. I forget the invoke syntax, but doit[1] is basically a make replacement so calling the shell is pretty easy: def task_something(): return {'actions': ['ls foo/', 'rm -r foo']} And you can use outputs from one task as inputs for another, it tracks what's been done, etc. [1]: https://pydoit.org/ https://pydoit.org/ [2]: https://docs.python.org/3/library/subprocess.html#subprocess.Popen.stderr https://docs.python.org/3/library/subprocess.html#subprocess... [3]: https://perldoc.perl.org/5.30.0/perlop.html#qx%2f_STRING_%2f https://perldoc.perl.org/5.30.0/perlop.html#qx%2f_STRING_%2f [4]: https://docs.python.org/3/library/subprocess.html#popen-constructor https://docs.python.org/3/library/subprocess.html#popen-cons...
    - gerikson 7y ago
      How can one do something like fork/exec in python? That's what I was thinking of when you mentioned "forking off jobs". There are a number of different ways to launch an external process from Perl, I think this StackOverflow answer summarizes them quite well: https://stackoverflow.com/a/800105 https://stackoverflow.com/a/800105 I'm an experienced Perl user, but I'm not as familiar with Python. In addition, I'm not really using Perl for sysadmin stuff, so I tend to try to keep stuff "within" Perl. As an example, I'd rather use the File::Find module than use backticks to invoke `find`. This has really nothing to do with functionality - I'm almost always on Linux, and the syntaxes are similarly hairy - it's just that usually you get more powerful functionality using the Perl functionality. (edit rearranged paragraphs)
jimbokun 7y ago
How does Ruby compare to Perl and Python for these tasks?
- btilly 7y ago
  Ruby is about equal to Perl as a language for interactive command line usage, and both are better than Python. Comparing RubyGems to CPAN, CPAN is about 2x as large, has a better infrastructure, better testing, and is generally better. Comparing CPAN to PyPI (the Python version), they are about the same size, PyPI has a worse testing story, has more up to date modules, is growing faster and seems to be of similar quality. If you want write a system that integrates with a recent standard, support from Google, or to use something like machine learning, Python is the clear winner. Adding JavaScript, I consider node.js to have the worst command line story, worst repository system, but it is extremely popular. I personally use Perl for command line stuff and Python otherwise. I use JavaScript when I have to (and sadly I have to a lot). It is rare for me to bother with Ruby. But I learned Perl first, and have written more in Perl than the others combined. Does this answer your question fully?

ptx 7y ago

Perl starts up really, really fast though, so invoking it repeatedly in a pipeline is more practical than with a Python program for that reason.