This is the last m-word post for a while, I promise.
In Lack of Ceremony and the Marketing Gap, I talked about how Perl 5's deliberate refusal to force people to arrange their problems in any particular style helps good programmers write programs effectively and lazy programmers write poorly-structured code. One Perl perception problem is that there are a lot more lazy programmers than disciplined programmers.
In Whipuptitude and the Marketing Gap, I discussed Perl's suitability as a glue language for projects great and small and how the same ability to arrange effective large programs quickly lets people write awful small programs quickly... and there are a lot more small programs available for people to see than large programs.
The third aspect of Perl which I believe contributes to the perception that Perl is difficult to manage is its DWIMminess -- its tendency to work very hard to intuit what the programmer meant to do and do it. Often this DWIMminess goes unnoticed; it's when Perl does the wrong thing that people realize that Perl's heuristics do not match their expectations.
Consider the polymorphic print statement in almost any language
that's not C. Give it an integer and it prints an integer. Give it a string
and it prints a string. Give it a floating-point value and it prints a
floating-point value. Give it a reference object and -- well, DWIM suggests
that it invoke some sort of .repr method on that object and
produce some intelligible form of output. Whatever the case, you expect
print to produce some meaningful output for every type of
parameter you might possibly pass.
The same goes for simple arithmetic operators. Imagine the hassle of requiring different infix operators for adding an integer to a float versus a float to an integer versus two floats versus two integers. There are, admittedly, still complications regarding the result of such operations, but the potential combinations there make the problem worse.
It's much simpler for the compiler writer to lie a little bit and make these operators polymorphic even if the rest of the language does not allow such behavior.
Perl takes DWIM further.
Because Perl's type system cares more about context and container type than value type, it does provide separate operators to indicate the type of operation the programmer intended. In a sense, values aren't typed; operations are typed. (You can argue that this is the same behavior as forcing casting or conversions, with less boilerplate and ceremony. The real questions are how much caching you need to do to improve performance and how much type safety your type system can provide. C loses on both counts.)
In other words, it's no surprise when you want to compare two strings with
the eq operator. It's little surprise when comparing two numbers
with the eq operator works in many cases, but it's a big surprise
when comparing two strings with the == operator doesn't work the
way you expect.
The question is whether your expectations come from other languages which provide some DWIM (even if the implementation is inconsistent with the rest of the language) or from understanding how Perl works.
If you understand how operators and other grammatic components of Perl
enforce context of number and type, you can take advantage of DWIM. It's
obvious why 0 but true is true in a boolean but zero in a numeric
context.
If you don't understand operators and context but you're fortunate enough to enable strict and warnings or run Perl::Critic, you'll have the opportunity to learn what's happening when one of those tools identifies a situation where you might have done the wrong thing.
Sadly, far too much code exists without the benefits of either conceptual understanding of Perl's typing and contexts or the assistance of good tools which point out likely mistakes and recommend corrections.
For whatever reason, the Perl community hasn't done well enough explaining Perl's underlying concepts. People can still solve their problems with a minimum of ceremony and boilerplate by joining together multiple, interesting small pieces -- but until they understand Perl's philosophy and its strengths, they condemn themselves to writing verbose, clunky code that works against Perl's natural DWIMmery.
It's a good problem to have that novices to Perl and to programming can accomplish productive things without having to become Perl experts. Yet we also need to find ways to encourage them to greater understanding before they find themselves maintaining (or sharing or documenting or cursing) a big pile of spaghetti code.
No language can prevent that in and of itself. That leaves the community to fix technical concerns and these Perl marketing problems. How do we do it?
