Hacker News Reader

Comment by nemothekid | Hacker News Reader

I've never really had a problem with perl until I had to mange fairly large projects - including things like web frameworks or distributed modules.

Perl works best as CPAN glue. CPAN is wizards handbook, and you just have to write maybe 100 lines of code to glue everything together. However when it came time to write a large project on a team of even 2 or 3 people, managing a Perl project seems to turn into manager a C project. The "Theres more than one way to do it" mantra really sucks for people who learned Perl in differently. 00's university perl doesn't mix well with 90's hacker perl.

My huge problem with Perl is readability. Sometimes, across teams, there are just too many ways of doing some simple thing and one is plain perl code to one person, is a 5-minute and stare at this line hack to another.

Am I wrong? My experience is limited, but I would love to know why I haven't been able to get my Perl projects to "sync".

View on HN

For me (in the data world) perl works really well within the unix philosophy. Basically my perl programs are small, simple, reusable, and can be piped together. My typical perl program is less than 200 lines and works on standard input/output (and perhaps a file or two provided as parameters). This simplicity and modularity means that I can pass my perl tools around to my team members and they don't need to read the code; instead they can read the documentation and unit tests and treat it as a tool. This takes advantage of perl's strengths, which are speed of development and built-in text processing.

Also, once you know perl you can easily write "one-liners", which have made me incredibly efficient in certain cases.

I'm wondering, did you utilize helpers such as Perl::Tidy and Perl::Critic? I imagine they may be able to help, possibly by standardizing the style enough (with Perl::Critic, which is configurable) that the problem is reduced to something you get with peer languages.

To be clear, I don't know whether this is true, but I'm extremely interested in people results.

The "There's more than one way to do it" sucks for trying to teach Perl too. You can't just teach one way; you need to teach every way, so that students can understand what they're seeing in the wild. This makes it take three times as long to explain the basics of Perl, simply because there are, essentially, three times as many basics.

My experience is different. I spent a lot of time in the beginning teaching the three or four important theoretical parts of Perl (lists, context, monomorphic operators, and coercion) and then explained how to use the documentation. That leaves only a couple of places where the difference between approaches is substantial enough that it needs explaining. Dereferencing syntax is one such wart. Choosing an object system used to be another place where opinions varied enough that it mattered, but now teaching Moose by default is obviously enough correct that it's a boring choice.

Yup. I've not taught perl for a while - but that pretty much matches my experiences. The N ways of doing "good" OO was the biggest problem I encountered and Moose solves that.

I, personally, haven't noticed this happening any more in large Perl projects than with any other language. Yes they happen but, like with other languages, they're usually opportunities for team members to learn one thing or the other (either "this is what this does" or "please write comprehensible code to the rest of the team" depending ;-)

Reply on news.ycombinator.com