4 ms·

"Perl has always considered itself primarily a programmer-centric language, while Python has always considered itself to be more institution-centric. So in a se

by chubot 10y ago

"Perl has always considered itself primarily a programmer-centric language, while Python has always considered itself to be more institution-centric. So in a sense it's a bit dumbed down, much like Java. You'll note both of those languages make their greatest appeal to managers. :-) " Huh? I was using Python when Perl was more popular, and this seems completely fabricated. He's trying to lump Python in with Java, which is bizarre because those 2 camps have pretty big philosophical differences. I think that the main reason that Python became more popular because it has both clearer syntax and clearer semantics than Perl. It is compact AND readable -- not just compact. The data structures in Python also behave more like those you would see in a CS textbook. I'm working on my own language, and I just read over the Camel Book ("Learning Perl"). Honestly I don't see much in there that I want to borrow, except maybe for ~= automatically introducing variables. What else is good about Perl, which is 1) not in Python/Ruby/JavaScript (like hash tables) 2) overly terse/clever? (Honest question) Perl's regex syntax seems to be it's biggest influence and legacy, with Python/Ruby/Java/PCRE all adopting its syntax. And -e in Perl is also useful -- Python/Ruby/etc. aren't really good for one liners like Perl. This provides a nice gateway into the language. But a lot of other features were rightly ignored by other languages IMO. Also, with regard to the previous sentence, I actually consider Python OO kind of weak, but it's definitely better than Perl's AFAICT.

PeCaN 10y ago
> What else is good about Perl, which is 1) not in Python/Ruby/JavaScript or 2) overly terse/clever? (Honest question) Scalar/list/hash context. It makes zero sense and the syntax seems to change randomly… until you understand it. Then contexts make a great deal of sense. Also, having dealt with a good deal of Python, I'm inclined to lump it in with Java too—less verbose and dynamically typed, but still focused on code that's superficially easy to read or understand. There's a big difference between being able to read a function or class definition (whatever the hell it means to ‘read’ code; I don't even know anymore) and understand where that falls in the big scheme of things. Python and Java read from the bottom-up; individual methods make sense but then you have to piece everything together. Perl, APL, and Lisp-family read from the top-down. You start with some abstractions and idioms and work your way down to individual functions, which may be hard to grok but what matters is what they do, not how. Perl makes writing those really, really fast, and allows building abstractions easily.
- xapata 10y ago
  > Python ... read[s] from the bottom up Depends on who is writing, of course.
- chubot 10y ago
  OK thanks for the answer. I agree that this context sensitivity is probably the most Perl-ish part of Perl. I just read over the Camel book section on this, and it says: "This is the most important section in this chapter. In fact it's the most important section in the entire book." "Not only that, but you can't make any general rules to apply what you know about some expressions to others. Each expression can make up its own rules. ... Perl is very much a language that tries to do the most common, mostly right thing for you." "In fact, a big part of learning Perl is actually learning how Larry thinks. Therefore, once you can think like Larry does, you know what Perl should do". Those quotes don't inspire confidence in me -- it sounds like a battalion of mostly correct special cases... mostly correct meaning "sometimes wrong". However, I do appreciate that the linguistic part of your brain is very large and powerful, and once you internalize all these rules they can lead to a beautiful expressivity. Larry is making use of a different part of your brain than other languages do. But I have to work with 5 languages regularly, and I see this polyglot trend only increasing in the future. So I appreciate when languages are a little more predictable, and a few months away from them won't diminish my fluency.
  - ab5tract 10y ago
    FWIW, I've found that this quote: "Not only that, but you can't make any general rules to apply what you know about some expressions to others." has been greatly improved in Perl 6 over Perl 5. That is, the very rules of the parser feel more concrete and the degree of composability between interlocking syntactical constructs has far fewer rough edges. The explanations for the edge cases, when you do come across them, tend to feel more "justifiable" to me as well, in the sense that Perl 5 justifications can and will often be implementation oriented where Perl 6 justifications will tend to come from the language design itself. (Where implementation demands in excuse in Perl 6, it tends to be of the NYI variety). So the fear of 'mostly correct' is not an issue in Perl 6, in my experience. FWIW, I've also written a lot of Perl 5 code at this point and I've found 'mostly correct' to be absolutely fine in practice, if a bit of a WTF in a few cases going on (edit: going in). "Each expression can make up its own rules." While at the same time as becoming more predictable in the manner I describe above, Perl 6 also pushes this to the absolute limit by making it LITERALLY true. For Perl 5, this sentence is pretty true in spirit, if a little bit of a fib practically. The language just didn't have the design that would allow it to, say, produce a real AST. Things like source filters were attempted early on in the language cycle and were already considered harmful by the time I started Perl in 1998. In Perl 6, every expression can easily make up its own rules, but you don't do it in some oddball one-liner. Instead you have an operator (that is, "a subroutine with a funny name") defined somewhere in scope using the same definition mechanism as every native operator in the language. You get absolute guarantees for behavior on your own operators -- anything core can do, you can do. And it's (edit: core is) always there as a reference to guide you while writing your own operators. But then again, maybe you actually just don't define that many custom operators. The syntax is terse and expressive enough that I don't find myself doing it very often. I think in the long run, Perl 6 has everything you need -- and if you don't like the way it looks, it has everything you need to change that, too. And your code wouldn't be transpiled as we do in JavaScript today. It would instead be parsed by the same grammar engine that parses Perl 6 itself.
niftich 10y ago
Python being intuition-centric is true in the sense that there are a limited number of orthodox, pythonic ways of accomplishing something, so if you're invested in the Python philosophy, those solutions will come to you. The comparison to Java, albeit a bit surprising, comes from the notion that both of them ship with intentionally simple building blocks, which you can chain together in a limited, constrained set of ways. This kind of programming leads to Java's verbosity, where to read a file, you have to obtain an InputStream, so you use a FileReader, but you probably want to wrap in inside of a BufferedInputStream to get buffering, which you probably want to surround in a try-catch-finally to clean up exceptional states, which you're going to want to call readLines on until you run out of lines, which you want to put into a data structure that implements the interface List<>. None of these building-blocks are complex on their own. Furthermore, Java is about enforcing language restrictions from the programmer -- you must deal with checked exceptions before you can proceed, you must not clash types, you must provide an implementation of this abstract method, you must not access this private variable. Meanwhile Python encourages 'pythonic' constructs, which are idiomatic ways of accomplishing a certain task; these are not unlike what Java programmers would call 'design patterns'. But Python is more lax than Java, and has a notion of 'we're all adults here' [1] towards OO. Perl takes 'we're all adults' to a new level, providing a LOT of specialized syntax and sophisticated heuristics to squeeze more expressive power from expressions. [1] http://stackoverflow.com/questions/70528/why-are-pythons-private-methods-not-actually-private http://stackoverflow.com/questions/70528/why-are-pythons-pri...
berntb 10y ago
Uh, it seems you never heard of Moose if you think Perl's OO is weak? Why do you bother having opinions on subjects which you haven't followed for six++ years..? (Alternatively, a good criticism of Moose/CLOS?)
cicero 10y ago
Although I don't think of Python and Java as that similar, I do see what Larry is getting at. Python encourages "There should be one-- and preferably only one --obvious way to do it", which is very nice for institutions where multiple programmers have to work with the same code. The power that comes from "more than one way to do it" in Perl is great for an individual programmer that wants to create his own custom tool box, but it can cause difficulties in an organization with people at different skill levels all working on the same code base. By the way, you see similar issues with Common Lisp. It is great for individual power programmers, but it seldom catches on for something that has to scale way beyond one programmer. As a contrast, look at Go, which was, as Larry Wall would say, "dumbed down" to meet the institutional needs of Google. I know a lot of Hacker News types would rather think of themselves as power programmers rather than institutional types, but we shouldn't overly disparage the power of institutions to scale way beyond what a single individual can do, even though there can eventually be problems with bloat and mediocrity. All this is to say that there is need and room in the world for programmer-centric and institution-centric tools. Larry has been helpful to point out the difference, and so people should think about these things when choosing between Python and Perl, for example. I work at a small school, and although I am a one-man programming shop, I do everything in Python in the hopes that if something happens to me, my successor will have an easier time understanding my code. I had done some work in Racket, Clojure, and Haskell, but then I thought about the future and converted everything to Python.
- chubot 10y ago
  Yeah I see what he's getting at in the sense that Python is more regular and compositional, while Perl is more personal and "poetic" (if I'm to be charitable, I don't really like that quality in my code). But "Python has always considered itself institution-centric" is patently FALSE... as I said, if you were using Python 10+ years ago, when Perl was more popular, you would find that statement very surprising. Paul Graham even wrote about this: http://paulgraham.com/pypar.html http://paulgraham.com/pypar.html
  - cicero 10y ago
    I will agree with you that Python didn't consciously consider itself institution-centric, but it has valued institution-friendly goals such as readability and maintainability.
ceronman 10y ago
I have been using Perl for the last 3.5 years (for work). Before that I used Python for 8 years. For the vast majority of things Python is better. Perl programmers tend to say that the language is more powerful and allow for shorter programs, but in my experience, when writing the same program in Perl and Python, the later is more concise. There are some Perl features that save you keystrokes, for example, autovivification, but in the long run those are a lot of trouble. Also, it's really hard to learn to use Perl properly, it's full of inconsistencies and antipatterns, it's so easy to write bad code with it. Python is much simpler, consistent and with less corner cases. Python features (e.g. iteration protocol) seem more elegant to me. Perl features feel really hacky, they work, but they're rarely orthogonal and usually have surprising side effects. One aspect where Perl still kickass is for writing shell scripts. Running commands, interacting with the filesystem and other tools is so easy. Once you know Perl, you rarely use bash, sed, grep or awk.
- devdas 10y ago
  Are you trying to write Pythonic Perl?
  - ceronman 10y ago
    Of course not. Many Pythonic idioms don't really work well in Perl. I have tried to write perlish code.
jlarocco 10y ago
That whole section talking about Python seems like sour grapes, or making up excuses why Perl gave up so much mindshare to everything else. Python and Ruby beat out Perl because they released new versions and responded to and kept up with changes in the software industry, while Perl stagnated for 15 years, making incremental point releases to Perl 5 while struggling with the boondoggle that is Perl 6.
Mithaldu 10y ago
> I actually consider Python OO kind of weak, but it's definitely better than Perl's AFAICT. Another comment on this was downvoted, because it was unkind, but the point it made is correct: That statement of yours there is entirely wrong. Python's OO is what it is and it's largely static. Perl's OO however consists, at the language level, of building blocks that are very low level. That does not mean Perl's OO is bad however, since in the year 2016, you rarely operate at that level. Instead you use Moo or Moose, which take these building blocks and provide an OO API that is better than most competitors' OO APIs. Have a read through this, and try and see how much code you'd need to write in other languages to duplicate the entire range of features you see in the code samples: https://metacpan.org/pod/distribution/Moose/lib/Moose/Manual.pod https://metacpan.org/pod/distribution/Moose/lib/Moose/Manual...
kod 10y ago
> What else is good about Perl He answers that question in the interview, 'What do you think about Python'. Short summary: closures (no, python lambdas are not the same), the kind of FP that having real closures allows, a real meta-object model, concurrency without a GIL

by chubot 10y ago

PeCaN 10y ago

> What else is good about Perl, which is 1) not in Python/Ruby/JavaScript or 2) overly terse/clever? (Honest question) Scalar/list/hash context. It makes zero sense and the syntax seems to change randomly… until you understand it. Then contexts make a great deal of sense. Also, having dealt with a good deal of Python, I'm inclined to lump it in with Java too—less verbose and dynamically typed, but still focused on code that's superficially easy to read or understand. There's a big difference between being able to read a function or class definition (whatever the hell it means to ‘read’ code; I don't even know anymore) and understand where that falls in the big scheme of things. Python and Java read from the bottom-up; individual methods make sense but then you have to piece everything together. Perl, APL, and Lisp-family read from the top-down. You start with some abstractions and idioms and work your way down to individual functions, which may be hard to grok but what matters is what they do, not how. Perl makes writing those really, really fast, and allows building abstractions easily.

xapata 10y ago
> Python ... read[s] from the bottom up Depends on who is writing, of course.
chubot 10y ago
OK thanks for the answer. I agree that this context sensitivity is probably the most Perl-ish part of Perl. I just read over the Camel book section on this, and it says: "This is the most important section in this chapter. In fact it's the most important section in the entire book." "Not only that, but you can't make any general rules to apply what you know about some expressions to others. Each expression can make up its own rules. ... Perl is very much a language that tries to do the most common, mostly right thing for you." "In fact, a big part of learning Perl is actually learning how Larry thinks. Therefore, once you can think like Larry does, you know what Perl should do". Those quotes don't inspire confidence in me -- it sounds like a battalion of mostly correct special cases... mostly correct meaning "sometimes wrong". However, I do appreciate that the linguistic part of your brain is very large and powerful, and once you internalize all these rules they can lead to a beautiful expressivity. Larry is making use of a different part of your brain than other languages do. But I have to work with 5 languages regularly, and I see this polyglot trend only increasing in the future. So I appreciate when languages are a little more predictable, and a few months away from them won't diminish my fluency.
- ab5tract 10y ago
  FWIW, I've found that this quote: "Not only that, but you can't make any general rules to apply what you know about some expressions to others." has been greatly improved in Perl 6 over Perl 5. That is, the very rules of the parser feel more concrete and the degree of composability between interlocking syntactical constructs has far fewer rough edges. The explanations for the edge cases, when you do come across them, tend to feel more "justifiable" to me as well, in the sense that Perl 5 justifications can and will often be implementation oriented where Perl 6 justifications will tend to come from the language design itself. (Where implementation demands in excuse in Perl 6, it tends to be of the NYI variety). So the fear of 'mostly correct' is not an issue in Perl 6, in my experience. FWIW, I've also written a lot of Perl 5 code at this point and I've found 'mostly correct' to be absolutely fine in practice, if a bit of a WTF in a few cases going on (edit: going in). "Each expression can make up its own rules." While at the same time as becoming more predictable in the manner I describe above, Perl 6 also pushes this to the absolute limit by making it LITERALLY true. For Perl 5, this sentence is pretty true in spirit, if a little bit of a fib practically. The language just didn't have the design that would allow it to, say, produce a real AST. Things like source filters were attempted early on in the language cycle and were already considered harmful by the time I started Perl in 1998. In Perl 6, every expression can easily make up its own rules, but you don't do it in some oddball one-liner. Instead you have an operator (that is, "a subroutine with a funny name") defined somewhere in scope using the same definition mechanism as every native operator in the language. You get absolute guarantees for behavior on your own operators -- anything core can do, you can do. And it's (edit: core is) always there as a reference to guide you while writing your own operators. But then again, maybe you actually just don't define that many custom operators. The syntax is terse and expressive enough that I don't find myself doing it very often. I think in the long run, Perl 6 has everything you need -- and if you don't like the way it looks, it has everything you need to change that, too. And your code wouldn't be transpiled as we do in JavaScript today. It would instead be parsed by the same grammar engine that parses Perl 6 itself.

niftich 10y ago

Python being intuition-centric is true in the sense that there are a limited number of orthodox, pythonic ways of accomplishing something, so if you're invested in the Python philosophy, those solutions will come to you. The comparison to Java, albeit a bit surprising, comes from the notion that both of them ship with intentionally simple building blocks, which you can chain together in a limited, constrained set of ways. This kind of programming leads to Java's verbosity, where to read a file, you have to obtain an InputStream, so you use a FileReader, but you probably want to wrap in inside of a BufferedInputStream to get buffering, which you probably want to surround in a try-catch-finally to clean up exceptional states, which you're going to want to call readLines on until you run out of lines, which you want to put into a data structure that implements the interface List<>. None of these building-blocks are complex on their own. Furthermore, Java is about enforcing language restrictions from the programmer -- you must deal with checked exceptions before you can proceed, you must not clash types, you must provide an implementation of this abstract method, you must not access this private variable. Meanwhile Python encourages 'pythonic' constructs, which are idiomatic ways of accomplishing a certain task; these are not unlike what Java programmers would call 'design patterns'. But Python is more lax than Java, and has a notion of 'we're all adults here' [1] towards OO. Perl takes 'we're all adults' to a new level, providing a LOT of specialized syntax and sophisticated heuristics to squeeze more expressive power from expressions. [1] http://stackoverflow.com/questions/70528/why-are-pythons-private-methods-not-actually-private http://stackoverflow.com/questions/70528/why-are-pythons-pri...

berntb 10y ago

Uh, it seems you never heard of Moose if you think Perl's OO is weak? Why do you bother having opinions on subjects which you haven't followed for six++ years..? (Alternatively, a good criticism of Moose/CLOS?)

cicero 10y ago

Although I don't think of Python and Java as that similar, I do see what Larry is getting at. Python encourages "There should be one-- and preferably only one --obvious way to do it", which is very nice for institutions where multiple programmers have to work with the same code. The power that comes from "more than one way to do it" in Perl is great for an individual programmer that wants to create his own custom tool box, but it can cause difficulties in an organization with people at different skill levels all working on the same code base. By the way, you see similar issues with Common Lisp. It is great for individual power programmers, but it seldom catches on for something that has to scale way beyond one programmer. As a contrast, look at Go, which was, as Larry Wall would say, "dumbed down" to meet the institutional needs of Google. I know a lot of Hacker News types would rather think of themselves as power programmers rather than institutional types, but we shouldn't overly disparage the power of institutions to scale way beyond what a single individual can do, even though there can eventually be problems with bloat and mediocrity. All this is to say that there is need and room in the world for programmer-centric and institution-centric tools. Larry has been helpful to point out the difference, and so people should think about these things when choosing between Python and Perl, for example. I work at a small school, and although I am a one-man programming shop, I do everything in Python in the hopes that if something happens to me, my successor will have an easier time understanding my code. I had done some work in Racket, Clojure, and Haskell, but then I thought about the future and converted everything to Python.

chubot 10y ago
Yeah I see what he's getting at in the sense that Python is more regular and compositional, while Perl is more personal and "poetic" (if I'm to be charitable, I don't really like that quality in my code). But "Python has always considered itself institution-centric" is patently FALSE... as I said, if you were using Python 10+ years ago, when Perl was more popular, you would find that statement very surprising. Paul Graham even wrote about this: http://paulgraham.com/pypar.html http://paulgraham.com/pypar.html
- cicero 10y ago
  I will agree with you that Python didn't consciously consider itself institution-centric, but it has valued institution-friendly goals such as readability and maintainability.

ceronman 10y ago

I have been using Perl for the last 3.5 years (for work). Before that I used Python for 8 years. For the vast majority of things Python is better. Perl programmers tend to say that the language is more powerful and allow for shorter programs, but in my experience, when writing the same program in Perl and Python, the later is more concise. There are some Perl features that save you keystrokes, for example, autovivification, but in the long run those are a lot of trouble. Also, it's really hard to learn to use Perl properly, it's full of inconsistencies and antipatterns, it's so easy to write bad code with it. Python is much simpler, consistent and with less corner cases. Python features (e.g. iteration protocol) seem more elegant to me. Perl features feel really hacky, they work, but they're rarely orthogonal and usually have surprising side effects. One aspect where Perl still kickass is for writing shell scripts. Running commands, interacting with the filesystem and other tools is so easy. Once you know Perl, you rarely use bash, sed, grep or awk.

devdas 10y ago
Are you trying to write Pythonic Perl?
- ceronman 10y ago
  Of course not. Many Pythonic idioms don't really work well in Perl. I have tried to write perlish code.

jlarocco 10y ago

That whole section talking about Python seems like sour grapes, or making up excuses why Perl gave up so much mindshare to everything else. Python and Ruby beat out Perl because they released new versions and responded to and kept up with changes in the software industry, while Perl stagnated for 15 years, making incremental point releases to Perl 5 while struggling with the boondoggle that is Perl 6.

Mithaldu 10y ago

> I actually consider Python OO kind of weak, but it's definitely better than Perl's AFAICT. Another comment on this was downvoted, because it was unkind, but the point it made is correct: That statement of yours there is entirely wrong. Python's OO is what it is and it's largely static. Perl's OO however consists, at the language level, of building blocks that are very low level. That does not mean Perl's OO is bad however, since in the year 2016, you rarely operate at that level. Instead you use Moo or Moose, which take these building blocks and provide an OO API that is better than most competitors' OO APIs. Have a read through this, and try and see how much code you'd need to write in other languages to duplicate the entire range of features you see in the code samples: https://metacpan.org/pod/distribution/Moose/lib/Moose/Manual.pod https://metacpan.org/pod/distribution/Moose/lib/Moose/Manual...

kod 10y ago

> What else is good about Perl He answers that question in the interview, 'What do you think about Python'. Short summary: closures (no, python lambdas are not the same), the kind of FP that having real closures allows, a real meta-object model, concurrency without a GIL