When I started with Perl, the manpage was only 10 pages long. There wasn't enough of it to be intimidating. {grin}

Mostly what I find intimidating now are the people who look at Perl golf and Perl JAPHs and the slapped-together perl4-style CGI scripts and think that this is "normal" Perl. If I could eliminate those items from the Perl culture, I think we'd have fewer people intimidated by Perl in general.

One of my clients is in the upper half of the Fortune 500, and makes half of their revenue from tens of thousands of lines of Perl code deployed as mod_perl web servers and web services, and infrastructure support. And no, they're not running out to replace it with Java or Python or Ruby on Rails. In fact, they're writing a lot more Perl to go with it. Yeay. But why it works is because they have a great design, testing, and deployment strategy, which they would need for any large project in any programming language. Perl is never the issue when you have the rest of the infrastructure in place.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Makes sense; I don't even look at posts in the "obfuscation" section here anymore because I get a headache when I look at
some of them. However, I can understand the intellectual appeal to folks of creating code like that. It seems like it is partly art
and partly demonstrating a certain level of mastery of the language.

Scott

Maybe intimidating isn't the right word, but more than one way to do it can be problematic when you have a lot of perl code. In languages with only one way to do it, there are no discussions between developers as they try to convince each other to do it their way. There is no code sprinkled through the code base doing the same thing 5 different ways.

I've been in these discussions many times and they are difficult because everyone can have good reasons for their approach.

However, once you decide on how you're going to do it 90% of the time, you are set. And with Perl, you still have the flexibility to consciously decide to do it different 10% of the time to handle a strange corner case. If there is only one way to do it, you don't have this flexibility.

I believe Perl 6 will address this nicely. I think they will provide one recommended way to do things, but still leave in the other ways to do it.

So for environments without good structure and standards, Perl can be challenging because it will highlight the lack of management. But as merlyn says, this isn't Perl's fault, it's a problem with the environment.

In languages with only one way to do it...

I've programmed non-trivial code in about 10 languages in the last eighteen months (and read code in a few others). Which languages provide only one way to do something?

Although I did take a few programming classes first (Java, C, Cobol), Perl was really my first language. The code I learned from was a bit ugly to say the least (your typical poorly formatted .cgi). It wasn't anymore intimidating than any other language and thanks to great books like Learning Perl, I learned how to do some really cool stuff, really fast.

Perl fit like a new glove for me. It was a little tight at first, but quickly loosened up to a perfect, comfortable fit. :)

With development releases of Perl 6 expected to emerge this year, and perhaps a production release by around this time next year [...]

I somewhat suspect the author heard the standard "by Christmas" timeline and didn't get the joke... But then, we've got an April-Fools'-Day timeline in the works now that could turn out to be either sort of joke ("yes, it's for real. no, really. really, just look here!" | "April Fools!")... just like parrot.

<update time="Thu Mar 10 07:00 UTC 2006">
And reality keeps on getting faster... we have a beginning perl6-in-perl6-on-(perl5|pugs) compiler called lrep, which has bootstrapped itself... as of today, 3 weeks and a day remain. Come join the fun!
</update>