> 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

> 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