Slashdot Mirror
Damian Conway On Programming, Perl And More
Andrew writes: "My host pair.com has an
interview with Damian Conway
in which he talks a lot about his upcoming modules, and what skills
a Perl programmer needs. I'm personally waiting on
Parse::FastDescent." Conway talks about some interesting modules he's working on, Perl 6, and on programming in general, too.
Although slashdot loves to post Damian Conway stories, those who still haven't had their fill can follow his online diary at yetanother.org.
Damian mentioned design patterns as one of the skills necessary to become a better programmer. As very little has been written about implementing design patterns in Perl, I've started a project to produce Perl implementations (and explanations) of the Gang of Four's patterns. Later, I hope that Perl-specific patterns may emerge, but for the moment I'm just trying to create interest in this important area for OO-Perl programmers.
It's true that individualistic programing styles can slow down a project, and it's true that perl allows almost infinite programming style, or lack of same. However, the two issues are orthogonal, and Perl itself is not bad for cooperation. Just ask the CPAN developers.
:)
Next, 'programming' is not the same as 'coding'. Programming has come to mean all the terms the author of the above post used: Design, Engineering, Requirements, Documentation.
The author of this post is half-right, but missing the big picture. There are folks who develop with maturity and discipline with Perl, and there are folks who write garbage in every language. The freedom to screw ourselves over is necessary for us to learn how not to screw ourselves over.
So no, Perl isn't bad for teams, self-centered programers are bad for teams. I should know, I've been that programmer.
(If I felt like invoking flame-mode, I'd suggest that perhaps the poster is coming from an academic or corporate background where individualism is bad for the hierarchy...
I make my living as a perl programmer
/. are so quick to flame Perl. If you don't like it don't use it but don't flame people who do. I love Perl. As far is being hard to read or understand well I think that's people who have never tried. When I started coding Perl I was a complete newbie. I'd done a little C and a bit of Basic and I wanted to learn how to right CGI scripts. Someone showed me Perl and inside a week I was writting (badly but still writting) a message board. It took me weeks, it was horrid but it worked. I know very few people who can do that in any other language. In fact it was Perl that got me to move away from the darkside of Windows (this was before ActiveState made Perl on Windows a more manageable beast).
I do not understand why a majority of people on
Try it before you knock it. Give it a chance. If you don't like it then use the tool you like but don't keep spreading flames and lies about it. Saying its only good for 500 line programs or that its always unmaintainable or it can't be used by teams simply isn't true. And ANY language can have all of those attributes.
Perl also has a great community that I've not seen in other languages. Don't know how to do something, ask Perlmonks. Those guys are even one of the few places where newbies can come. Very rarely do I even see someone screaming RTFM at them. Most of the time you just get your question answered and answered fast. There are other places that aren't so kind.
Perl is great. Long live Perl
The Anti-Blog
The problem I see with Perl is a management problem. Everyone complains that Perl produces bad code, but in reality, programmers produce bad code. By our very nature as human beings, we all think differently.
I agree Perl provides a lot of freedom to solve problems in the way most suitable to you. However, to use Perl successfully, you still need to set standards for acceptable algorithms, approaches, and documentation. This is exactly what you would do in Java, and exactly what you would do in C++ (i.e., by saying no templates/operator overloading).
I'd argue that such standards are necessary for any significant development effort - its just the nature of the beast, when trying to get multiple people to work together to tackle a problem.
So how do you use Perl effectively in a structured environment with teams of programmers working together? Here's a few ideas:
1) Code reviews. All code written for a team msut be reviewed by the team. This is absolutely essential to keeping the system functioning. If the team rejects it, the code must be fixed.
2) Documentation. Perl provides POD, a simple and standardized way to document the code you write. Enforce a standard that code without *meaningful* POD is not acceptable.
Note that documentation also means you need to document more than the code - you need to document the design decisions, the requirements the code tries to satisfy, and the assumptions made for the system as a whole. Without proper system/process documentation, a development project will fail.
3) Create standards for acceptable approaches to solve the problem. For example, Perl provides eval for exception handling - you could mandate that all external error handling code make use of eval to keep error detection orthogonal to error handling. You could (and should) require team members encapsulate code in modules, and provide documented interfaces to those modules. Code not encapsulated in a module will not be accepted into the tree.
There are only a few examples to illustrate ways to make development in Perl successful for your organization. These are the same problems you tackle in developing a sizeable project in any language with a team of programmers - Perl is no different, and is not a panacea for those problems. However, if standard management and structured development techniques are applied, developing in Perl can (and will) work for large organizations.
Perl is no different from any other technology in this regard. that for a large project, it is essential to set standards