4 ms·

"it becomes harder and harder to contribute to a Perl codebase, the bigger it gets." I've never written any perl, but is this really true? I fail to see how it

by aveeno 15y ago

"it becomes harder and harder to contribute to a Perl codebase, the bigger it gets." I've never written any perl, but is this really true? I fail to see how its really any worse than ruby/python.

zdw 15y ago
Perl and ruby are pretty similar (much of ruby was inspired by perl according to Matz), but perl is much older than ruby, and thus many people are used to language idioms that aren't particularly modern. There's also a tradition of writing one liners ala sed/awk in perl, and someone going from that to more complete programs isn't generally the best for program structure. Python's whitespace requirements tend to make it clearer to read, as there are fewer ways to format identical code, and it's a much less of a TMTOWTDI language than perl. tl/dr: Perl code is often written by old timers who expect everyone to be a perl genius like they are.
- pyre 15y ago
  > tl/dr: Perl code is often written by old timers > who expect everyone to be a perl genius like they are. While I can agree with this sentiment, it seems to come close to the idea that you should ignore language features in favor of making it newbie friendly. You don't want to ignore features of a language just because it might not be entirely clear to someone that is new to the language. That said, there is a lot of Perl code out there that was written in the past, or recently by people using old idioms/styles. I've even come across people (recently) expressing their dislike of Perl based on their experience with Perl 4.x (hint: Perl 5 was released in 1994).
  - sirclueless 15y ago
    > You don't want to ignore features of a language just because it might not be entirely clear to someone that is new to the language. I think this has a lot to do with why perl projects tend to accumulate complexity over their lifetimes. It's not an easy decision to ignore language features, and it's a decision that gets made each time a programmer writes more code, so it's inevitable that in a large program in a language with as many deep features as perl has, some programmer will choose to use each of them. The abundance of advanced features in use in a large project then forms a barrier of entry to a newbie who must understand each of them as he encounters them; while each feature and decision may make the most sense for its context, the preponderance of features means it takes a long time for new contributors to get up to speed. As to why this is different from Ruby/Python or many other more recent languages: Most popular recent languages are extremely resistant to the addition of any language features. They try to have canonical features that cover many use cases, for example Python's iterators and generators, or Ruby's block syntax. By having only a few options open for developers, new contributors are more likely to immediately grok the code of even large projects. Consider the statement "There should be one-- and preferably only one --obvious way to do it" from the Zen of Python[1], which is a gentle stab at the Perl motto, "There is more than one way to do it"[2]. [1] http://www.python.org/dev/peps/pep-0020/ http://www.python.org/dev/peps/pep-0020/ [2] http://c2.com/cgi/wiki?ThereIsMoreThanOneWayToDoIt http://c2.com/cgi/wiki?ThereIsMoreThanOneWayToDoIt
    - chromatic 15y ago
      ... the preponderance of features means it takes a long time for new contributors to get up to speed. What projects have you worked on that language features are a greater barrier to effective contribution than a deep understanding of the problem domain, adherence to project coding standards, and design principles of the code base? You can look up language features in the manual.
- chromatic 15y ago
  Python's whitespace requirements tend to make it clearer to read... What projects have you worked on such that consistency of indentation was at all a meaningful factor to maintenance? I worry more about duplication and near duplication, testing efficacy, proper factoring, symbol naming, effective error handling, the possibility of fencepost errors, and clarity of intent.
  - kamaal 15y ago
    Very well put. In my experience unless you are hiring exceptionally bad programmers. You don't really have to worry about code indentation. Seriously code indentation is all people worry about? I have bigger problems to worry about.
reactor 15y ago
"I've never written any perl" that says it all. Try it, you will understand. B/w what makes you think ruby/python is worse?
- pyre 15y ago
  > "I've never written any perl" that says it all. Try it, > you will understand. Let's not start a language war here, please. > I fail to see how its really any worse than ruby/python. > B/w what makes you think ruby/python is worse? I fail to see where the parent post claimed that ruby/python were worse than Perl. My interpretation is that the parent poster believes that Perl, Ruby, and Python all suffer from the idea that the larger the codebase gets, the more complex it gets. That complexity then becomes a barrier to entry for contribution to the project.
  - szabgab 15y ago
    ... and Java and C and C# and even PHP gets more complex as the code base grows. I am sure you don't pretend that naming one, or 3 does not send the message that that the others are not.
    - pyre 15y ago
      I only named those three because they were within the context of the discussion. Nothing more. The idea that complexity increases over time and become a barrier to entry applies to a great many things.
jleader 15y ago
Wait, are there programming languages where as a codebase grows, it doesn't get more complex? I've worked on reasonably large codebases in Perl, C, C++, Java, and Modula-II, and I'd say that in all cases, as the codebase grew, it got more complex and harder to contribute to.

by aveeno 15y ago

"it becomes harder and harder to contribute to a Perl codebase, the bigger it gets." I've never written any perl, but is this really true? I fail to see how its really any worse than ruby/python.

zdw 15y ago

Perl and ruby are pretty similar (much of ruby was inspired by perl according to Matz), but perl is much older than ruby, and thus many people are used to language idioms that aren't particularly modern. There's also a tradition of writing one liners ala sed/awk in perl, and someone going from that to more complete programs isn't generally the best for program structure. Python's whitespace requirements tend to make it clearer to read, as there are fewer ways to format identical code, and it's a much less of a TMTOWTDI language than perl. tl/dr: Perl code is often written by old timers who expect everyone to be a perl genius like they are.

pyre 15y ago
> tl/dr: Perl code is often written by old timers > who expect everyone to be a perl genius like they are. While I can agree with this sentiment, it seems to come close to the idea that you should ignore language features in favor of making it newbie friendly. You don't want to ignore features of a language just because it might not be entirely clear to someone that is new to the language. That said, there is a lot of Perl code out there that was written in the past, or recently by people using old idioms/styles. I've even come across people (recently) expressing their dislike of Perl based on their experience with Perl 4.x (hint: Perl 5 was released in 1994).
- sirclueless 15y ago
  > You don't want to ignore features of a language just because it might not be entirely clear to someone that is new to the language. I think this has a lot to do with why perl projects tend to accumulate complexity over their lifetimes. It's not an easy decision to ignore language features, and it's a decision that gets made each time a programmer writes more code, so it's inevitable that in a large program in a language with as many deep features as perl has, some programmer will choose to use each of them. The abundance of advanced features in use in a large project then forms a barrier of entry to a newbie who must understand each of them as he encounters them; while each feature and decision may make the most sense for its context, the preponderance of features means it takes a long time for new contributors to get up to speed. As to why this is different from Ruby/Python or many other more recent languages: Most popular recent languages are extremely resistant to the addition of any language features. They try to have canonical features that cover many use cases, for example Python's iterators and generators, or Ruby's block syntax. By having only a few options open for developers, new contributors are more likely to immediately grok the code of even large projects. Consider the statement "There should be one-- and preferably only one --obvious way to do it" from the Zen of Python[1], which is a gentle stab at the Perl motto, "There is more than one way to do it"[2]. [1] http://www.python.org/dev/peps/pep-0020/ http://www.python.org/dev/peps/pep-0020/ [2] http://c2.com/cgi/wiki?ThereIsMoreThanOneWayToDoIt http://c2.com/cgi/wiki?ThereIsMoreThanOneWayToDoIt
  - chromatic 15y ago
    ... the preponderance of features means it takes a long time for new contributors to get up to speed. What projects have you worked on that language features are a greater barrier to effective contribution than a deep understanding of the problem domain, adherence to project coding standards, and design principles of the code base? You can look up language features in the manual.
chromatic 15y ago
Python's whitespace requirements tend to make it clearer to read... What projects have you worked on such that consistency of indentation was at all a meaningful factor to maintenance? I worry more about duplication and near duplication, testing efficacy, proper factoring, symbol naming, effective error handling, the possibility of fencepost errors, and clarity of intent.
- kamaal 15y ago
  Very well put. In my experience unless you are hiring exceptionally bad programmers. You don't really have to worry about code indentation. Seriously code indentation is all people worry about? I have bigger problems to worry about.

reactor 15y ago

"I've never written any perl" that says it all. Try it, you will understand. B/w what makes you think ruby/python is worse?

pyre 15y ago
> "I've never written any perl" that says it all. Try it, > you will understand. Let's not start a language war here, please. > I fail to see how its really any worse than ruby/python. > B/w what makes you think ruby/python is worse? I fail to see where the parent post claimed that ruby/python were worse than Perl. My interpretation is that the parent poster believes that Perl, Ruby, and Python all suffer from the idea that the larger the codebase gets, the more complex it gets. That complexity then becomes a barrier to entry for contribution to the project.
- szabgab 15y ago
  ... and Java and C and C# and even PHP gets more complex as the code base grows. I am sure you don't pretend that naming one, or 3 does not send the message that that the others are not.
  - pyre 15y ago
    I only named those three because they were within the context of the discussion. Nothing more. The idea that complexity increases over time and become a barrier to entry applies to a great many things.

jleader 15y ago

Wait, are there programming languages where as a codebase grows, it doesn't get more complex? I've worked on reasonably large codebases in Perl, C, C++, Java, and Modula-II, and I'd say that in all cases, as the codebase grew, it got more complex and harder to contribute to.