Re: Perl Code Quality

I found out in my experience, that if you are going to use lots of CPAN modules, you'd better encapsulate their functionality in your classes, at least for the most critical.

In this way, when some CPAN class changes the way it works over time, you are not going to be hurt for that, and you can always adapt (and improve) your code base.

Comment on Re: Perl Code Quality

Replies are listed 'Best First'.
Re^2: Perl Code Quality by steves (Curate) on Sep 25, 2004 at 12:49 UTC
Maybe it depends on the CPAN modules used, but I was just remarking to someone last week how, with over 300 installed CPAN packages, I can only remember finding one backward compatibility issue in 5 years. We do wrap some, but only if we're extending functionality. Still not a bad idea though. I would agree that the world is not all OO. We have mostly OO code but there are a fair number of procedural modules. I think the point a lot of people miss is that, regardless of the coding paradigm used, the most important thing is packaging -- things should always be relegated to packages, properly factored out, in a directory structure that allows for additions and changes over time. A friend of mine refers to the base directory layout and packaging scheme one sets up as the pegboard of the programmer's workshop: a place to hang everything and everything in its place. It seems that a lot of programmers are not very comfortable working by building packages, unit testing those, and building small scripts that use them. For whatever reason, I always find that the average programmer gravitates towards long scripts. I think a lot of people just can't see the pieces as they present themselves. For that reason I'd try to hire at least one senior person who has done a lot of package building. Typically people who have had to build APIs for others to use are a good choice, whether it be in the open source world (like CPAN) or for a company that sells software. The experience of having to define interfaces is not as common as it seems sometimes.	[reply]

Replies are listed 'Best First'.

Re^2: Perl Code Quality
by steves (Curate) on Sep 25, 2004 at 12:49 UTC

Maybe it depends on the CPAN modules used, but I was just remarking to someone last week how, with over 300 installed CPAN packages, I can only remember finding one backward compatibility issue in 5 years. We do wrap some, but only if we're extending functionality. Still not a bad idea though.

I would agree that the world is not all OO. We have mostly OO code but there are a fair number of procedural modules. I think the point a lot of people miss is that, regardless of the coding paradigm used, the most important thing is packaging -- things should always be relegated to packages, properly factored out, in a directory structure that allows for additions and changes over time. A friend of mine refers to the base directory layout and packaging scheme one sets up as the pegboard of the programmer's workshop: a place to hang everything and everything in its place.

It seems that a lot of programmers are not very comfortable working by building packages, unit testing those, and building small scripts that use them. For whatever reason, I always find that the average programmer gravitates towards long scripts. I think a lot of people just can't see the pieces as they present themselves. For that reason I'd try to hire at least one senior person who has done a lot of package building. Typically people who have had to build APIs for others to use are a good choice, whether it be in the open source world (like CPAN) or for a company that sells software. The experience of having to define interfaces is not as common as it seems sometimes.

[reply]