Prepending Modules to your code

I program in Perl as part of my (Unix Admin) job. It can be fun to be clever and terse in Perl, but for me, it's more important that the code be simple and clear.

As a rule of thumb, I don't use awk when cut will do. I don't use perl when a shell script will do. I don't use modules when a built-in will do.

Of course some modules are essential and it's bad to reinvent the wheel.

My meditation has to do with the maintainability of Perl code that requires modules. I can be reasonably sure people have a relatively recent version of perl, but I'm less sure about modules. At my site, we work very hard to have a consistant environment, but there's more to do. Some people have some pretty bare-bones environments.

As a solution, I'm considering including the modules I need themselves in my code - in other words, my code would be one big program, with the modules themselves embedded. This way, I don't have to worry about someone's include path. Also, the program would be monolithic - non-technical people won't need to worry about maintaining their environments.

Is anyone doing this? Is this is bad idea? It makes your code bigger. Are there other disadvantages that make it not worth it?

Ken Beer

Comment on Prepending Modules to your code

Replies are listed 'Best First'.
•Re: Prepending Modules to your code by merlyn (Sage) on Jan 30, 2003 at 04:01 UTC
Don't reinvent the wheel. See PAR. -- Randal L. Schwartz, Perl hacker Be sure to read my standard disclaimer if this is a reply.	[reply]
Re: Prepending Modules to your code by Abigail-II (Bishop) on Jan 30, 2003 at 09:08 UTC
I don't think you are doing it right. I mean, the idea is good, but the execution is poorly. Sure, you have eliminated the include path. But what about the path to perl? Why depend on perl being installed? What if the installed perl was configured with the "wrong" options? What about missing system libraries, or wrong versions of them, or strangely set LD_LIBRARY_PATHs? Why depend on that? No, the least thing you should do is write a C program, include a Perl interpreter from the C program, and run your Perl code from within that interpreter. And then when you compile, statically link everything in. Only then you have a reasonable chance someone else will be able to run it. And it's really neat for the maintenance programmer. But it might even be better if you put this program on a bootable CD-ROM, so you will sure it's going to be run in the right OS. Code reuse is for wussies. Abigail	[reply]
Re: Prepending Modules to your code by Anonymous Monk on Jan 30, 2003 at 04:58 UTC
Hello :) I don't use perl when a shell script will do. Sometimes the best way to keep things simple is to use total overkill. If I can do all my work in Perl, then anyone who needs to maintain it (including me) only needs to know one language. I can also increase the time I can spend on fine-tuning my Perl skills (including time spent coding in Perl) if I don't have to write/learn more shell script. The most specialized/smallest tool isn't always the best for a job. Especially when you consider how projects have a strange way of growing beyond their original specifications. Just something to consider.	[reply]
Re: Prepending Modules to your code by Aristotle (Chancellor) on Jan 31, 2003 at 02:37 UTC
Try Acme::Intraweb `;-)` Makeshifts last the longest.	[reply]
Re: Prepending Modules to your code by diotalevi (Canon) on Jan 30, 2003 at 04:05 UTC
I misread the root node. This is a bad idea. I use modules for two reasons - it's faster to reuse someone else's code and they get to maintain it. It's up to me to keep my copy of their module up to sync (if I'm doing that) but in general it's a time saving measure. I don't have the time to write new code when I've got tested and stable code available in a module. I also don't have time to maintain code that someone else is willing to do for free on their own time. ~~Module use is pragmatic.~~ Seeking Green geeks in Minnesota	[reply]
Re: Prepending Modules to your code by Anonymous Monk on Jan 31, 2003 at 01:18 UTC
This is a bad idea because now if the module is fixed, you have to track down every script that uses it. Which turns the idea of a "module" into "cut and paste". Which is generally considered a Bad Thing...	[reply]