4 ms·

How many of those modules only exist to compensate for weaknesses in the core language though? For example, looking at http://search.cpan.org/~pevans/Scalar-Lis

How many of those modules only exist to compensate for weaknesses in the core language though? For example, looking at http://search.cpan.org/~pevans/Scalar-List-Utils-1.30/lib/List/Util.pm http://search.cpan.org/~pevans/Scalar-List-Utils-1.30/lib/Li... just befuddles me: every function is a one-liner or built-in in Python and most reasonable modern languages. Yet Python's stdlib is much smaller than Perl's. Note that the module in question has to have a bunch more functions than necessary in order to work around more problems in the core language: you need sum0 in addition to sum because you can't just use default arguments and you need both min/max and minstr/maxstr because context dependent type interpretation confuses everything. Of course, this doesn't generalize at all to other types besides strings in contrast to python's keyargs. Frankly, the notion that I need to download an external module in order to do something as basic as finding the largest element of a list seems just bizarre. The real problem here is that instead of having a small orthogonal core that everyone can learn and use, you have an incredibly complicated core that no one really understands that devolves lots of basic functionality to a giant network of modules. I think the perl community works incredibly hard at writing lots of CPAN modules to try and correct for perl's defects. But 100,000 bandaids isn't something to be proud of.

peterwwillis 13y ago
First: you're confusing "missing feature" with "weakness". Some people actually prefer not having 100,000 built-ins. IMHO comparing how you eat an apple with how you eat an orange is stupid. It's not the same fruit, and they work a little differently, and that is okay. If you prefer eating apples because you think the way to eat oranges is stupid, that is okay too. Second: You don't have to use a module to find the largest element in a list. But you can if you want, and you may find the module does it better than you do. Also, List::Util has been shipped with core perl since 5.8.0, so you don't have to download it. Third: Perl does have a small core that everyone can learn and use. The fact that you don't understand it or what modules are for does not discredit it.
- MichaelSalib 13y ago
  Some people actually prefer not having 100,000 built-ins Have you actually ever looked at Python? The core language is pretty small; much smaller than perl certainly. My point is that if you design the core well enough with orthogonal components and capabilities, you can give people the equivalent of many thousands of purpose-built modules. I have no idea what you're trying to say with your fruit analogy. Perl does have a small core that everyone can learn and use. That hasn't been my experience; the core language seems to have a staggering number of rarely used quite odd features that accumulated early on. It seems extremely hard to write a new implementation of perl that supports all that cruft; one can't even parse perl correctly except by using the existing implementation.
  - peterwwillis 13y ago
    Let's not get too wrapped up in language design. Perl was designed to replace 16 different Unix commands, and in that respect it is successful. Python was created as a scripting language with exceptions, and in that respect it is also successful. Thus my fruit analogy: Python and Perl are different kinds of fruit. They are designed differently and you use them differently. This is not a flaw. It is a feature. Arguing about how it should have been done X way is pointless. As for parsing, it is impossible to parse Perl, as it is Turing-complete and nobody has solved the halting problem (yet).
    - MichaelSalib 13y ago
      Perl was designed to replace 16 different Unix commands, and in that respect it is successful. Python was created as a scripting language with exceptions, and in that respect it is also successful. I don't think either of these statements is true. This is not a flaw. It is a feature. Arguing about how it should have been done X way is pointless. I disagree. This is not about subjective aesthetics. There are some fruits that are poisonous and are thus objectively bad, totally apart from the question of what fruit you think tastes best. Some of perl's language design features are objectively bad. For example, the way references are implemented makes it absurdly difficult to reason about simple things like nested sequences. If that complexity was needed to get some positive benefit like outstanding performance, then maybe it would be justified. But there are no significant benefits. They are the way they are because Larry Wall didn't understand anything about programming languages when he made perl. As for parsing, it is impossible to parse Perl, as it is Turing-complete and nobody has solved the halting problem (yet). With respect, every language I'm familiar with can be easily parsed except for perl. This has nothing to do with Turing Completeness or the Halting Problem. This has to do with having a sufficiently well designed syntax that tools can easily parse files written in the language without having to implement the whole damn language. That's an important property to have every language besides perl nails it because it is easy to do, but perl doesn't because Larry Wall didn't know anything about programming language design when he started.
chromatic 13y ago
Frankly, the notion that I need to download an external module in order to do something as basic as finding the largest element of a list seems just bizarre. It should seem bizarre, because no one ever argues that. I think the perl community works incredibly hard at writing lots of CPAN modules to try and correct for perl's defects. The module of greatest use to me today allows me to iterate through cells in a spreadsheet. Is it really a defect in a language that something like Spreadsheet::Parse Excel or Apache POI exists?

peterwwillis 13y ago

First: you're confusing "missing feature" with "weakness". Some people actually prefer not having 100,000 built-ins. IMHO comparing how you eat an apple with how you eat an orange is stupid. It's not the same fruit, and they work a little differently, and that is okay. If you prefer eating apples because you think the way to eat oranges is stupid, that is okay too. Second: You don't have to use a module to find the largest element in a list. But you can if you want, and you may find the module does it better than you do. Also, List::Util has been shipped with core perl since 5.8.0, so you don't have to download it. Third: Perl does have a small core that everyone can learn and use. The fact that you don't understand it or what modules are for does not discredit it.

MichaelSalib 13y ago
Some people actually prefer not having 100,000 built-ins Have you actually ever looked at Python? The core language is pretty small; much smaller than perl certainly. My point is that if you design the core well enough with orthogonal components and capabilities, you can give people the equivalent of many thousands of purpose-built modules. I have no idea what you're trying to say with your fruit analogy. Perl does have a small core that everyone can learn and use. That hasn't been my experience; the core language seems to have a staggering number of rarely used quite odd features that accumulated early on. It seems extremely hard to write a new implementation of perl that supports all that cruft; one can't even parse perl correctly except by using the existing implementation.
- peterwwillis 13y ago
  Let's not get too wrapped up in language design. Perl was designed to replace 16 different Unix commands, and in that respect it is successful. Python was created as a scripting language with exceptions, and in that respect it is also successful. Thus my fruit analogy: Python and Perl are different kinds of fruit. They are designed differently and you use them differently. This is not a flaw. It is a feature. Arguing about how it should have been done X way is pointless. As for parsing, it is impossible to parse Perl, as it is Turing-complete and nobody has solved the halting problem (yet).
  - MichaelSalib 13y ago
    Perl was designed to replace 16 different Unix commands, and in that respect it is successful. Python was created as a scripting language with exceptions, and in that respect it is also successful. I don't think either of these statements is true. This is not a flaw. It is a feature. Arguing about how it should have been done X way is pointless. I disagree. This is not about subjective aesthetics. There are some fruits that are poisonous and are thus objectively bad, totally apart from the question of what fruit you think tastes best. Some of perl's language design features are objectively bad. For example, the way references are implemented makes it absurdly difficult to reason about simple things like nested sequences. If that complexity was needed to get some positive benefit like outstanding performance, then maybe it would be justified. But there are no significant benefits. They are the way they are because Larry Wall didn't understand anything about programming languages when he made perl. As for parsing, it is impossible to parse Perl, as it is Turing-complete and nobody has solved the halting problem (yet). With respect, every language I'm familiar with can be easily parsed except for perl. This has nothing to do with Turing Completeness or the Halting Problem. This has to do with having a sufficiently well designed syntax that tools can easily parse files written in the language without having to implement the whole damn language. That's an important property to have every language besides perl nails it because it is easy to do, but perl doesn't because Larry Wall didn't know anything about programming language design when he started.

chromatic 13y ago

Frankly, the notion that I need to download an external module in order to do something as basic as finding the largest element of a list seems just bizarre. It should seem bizarre, because no one ever argues that. I think the perl community works incredibly hard at writing lots of CPAN modules to try and correct for perl's defects. The module of greatest use to me today allows me to iterate through cells in a spreadsheet. Is it really a defect in a language that something like Spreadsheet::Parse Excel or Apache POI exists?