I have worked in several companies in my day, and I am sure that many people will share my laments here. There are two kinds of companies out there in the world making use of Perl. One set is who I would call "the right ones" such as eToys, TicketMaster.com. The reason these places are right is that they don't see Perl as just the language, but as a culture of contributing people all encountering similar problems and working towards similar solutions. Ticketmaster.com recently did a "buy a damian" thing on Stas Bekman, employing him to work fulltime on mod_perl development. In this way, Ticketmaster.com is spending money upfront to ensure that a technology that they rely on will be around and top of the line.

The wrong way to use Perl is to see it as a "free language" and then run off and write a bunch of unreleased code. Most of this code however, is doing nothing but what CPAN modules do : application configuration AppConfig could've done it for them, templating (take your pick), database connections DBI + the whole gang of application layers on it, regression suites (yes, there are places that don't use Perl's builtin Test and instead use homegrown things that are less capable.... aaaaaahhhh!.

The reason this is bad use of Perl is that most people are running into the same problem and you are just reinventing the wheel. The second reason it is bad is that incoming contractors (moi) have to get up to speed with Yet Another Version of something Widely Used and Loved on CPAN. The final reason is that your test suite only get's hammered under certain conditions. And also check this out: A specific application should be an instantiation of a collection of generically useful modules. And if it isn't then you can be sure that it will not scale well And finally, just look at all the free documentation you get!

This post is what I want to say to my boss' boss, but I would be talking to a brick wall to do so. I meant to write it 2 weeks ago, but I said "ah, forget it" but my effectiveness at my job continues to dwindle and largely for this reason.

Oh and the title of this post? It just means that Perl is like a tree. It has roots. stem, branches, and leaves. To only take the Perl language and leave the rest is like having a stump in the ground as opposed to a 500 foot redwood sequoia.

Comment on The worst amputation possible: Perl proper as Open Source software

I used to work at Ticketmaster. Well, CitySearch really, but it's the same group of people now. (The companies merged during the time I worked at CitySearch.) At the time, we had horrible management who insisted that we spend tons of money on Java application servers. This was before Java became decent, and it was close to a disaster. It was monstrously unstable and everything took ages compared to how fast we could have done it in Perl. Management there had no clue what open source was other than that they liked the price tag, and they didn't trust anyone on the development team.

So, I left that company and went to eToys, where they would give me the freedom to use the tools I chose. However, some of my friends stayed there. CitySearch went through some hard times and some changes, and there was lots of turnover throughout the company, but these few people I knew (good Perl programmers and open source advocates) stuck around, turning out sites and admin tools with Mason, DBI, etc. Eventually, they had been there long enough keeping things afloat that they started being given more authority. One of my friends from eToys left to go back to CitySearch, and became manager of the development team. Pretty soon, they had an okay to convert all the CitySearch sites to mod_perl. That project was a tremendous success. When eToys went under, they picked up a lot of the best programming talent. Now they've hired Stas.

This story may not be all that interesting to someone who wasn't there, but I'm telling it to show that sometimes if you stick around and put some effort into it you can steer things in the right direction. The important thing is having some other talented developers along for the ride with you.

I think I understand what you're going through. I've also been at clients that for one reason or another decided it would be better to re-invent the wheel, then did a poor job at it. It's not just Perl, either. I've seen it with many other languages and technologies. There seem to be a few common reasons (excuses) I run into:

We're unique. Nobody else in the world does anything like what we do, so we need new wheels that are rounder than everybody else's.

Job security. All the code was written by a genius guy who left us six months ago. Don't touch it or it'll break.

Budget justification. We had to find something for everyone on the staff to do so we could get funding next year.

Control issues. If everything isn't built in-house, one day it could go away. (This is related to the "but who would support it" non-issue.)

Each of these has a reasonable response, but you need to phrase it such that someone with a business perspective will understand you. Probably the strongest argument would be to remind them that CPAN can affect budgets and delivery schedules very positively!

It appears you've grown disenchanted enough to want to throw in the towel. I don't know your circumstances, so maybe that is the right thing to do. But if it's just a question of "better late than never", I encourage you to go ahead and try to make your case. If you need specific arguments, post again. Manyofourseniormonks are both articulate and wise, and would probably be only too glad to help.

As VSarkiss says, this is not just about Perl. I'm working for an Association of Public Transport companies in Switzerland, and we have a huge database with addresses of our members, including several addresses of people who are in charge at the respective company, people who get the bills, people who get the quarterly mailing, all addresses which may or may not be the same. Now, years before I started working here someone wrote a database application in dBase (!) which sorted out all possible mailing issues for the database just fine.

Nowadays, however, this database has become so big that that programme just doesn't work stable anymore. And because it is so huge and complex, not even the person who wrote in the first place knows how it works and what needs to be done. Still he insisted for a long time that no other database application could possibly do all that his could, and would therefore be suitable for our system.

Now, what would happen (and this applies not only for this, but more or less any such case) if this person didn't work for us anymore, or, as it has already started, didn't know enough about his own programme anymore? In the case of a serious breakdown we would not only have to immediately find a solution, but also cope with the consequences of not having access to this data for some time.

I think one of the problems here is that most people think only a custom fitted solution fits all their needs. With anything else, there would surely be something that it couldn't do or wouldn't do in the right way - which is often enough only the "right" way because it's the way it has been done for ages - never mind whether is efficient or sensible. And this unfortunately does not only (although mostly) apply to management persons.

Having said this, if we didn't have people who try to write something new just because it will do things slightly differently, we wouldn't have such a huge collection of handy stuff like CPAN. So, a little reinventing the wheel is not so bad as long as it makes sense and doesn't happen because some management type had a fancy idea...

Programming applications needs to be fluid. Fluid like a Glass of water. Rigid enough to hold in the water, (a la using standardization techniques) but fluid like the water so as to be able to adapt and cover the problem at hand.

I have noticed that this situation is usually brought about by persons who know what they want the system for, and who have very little understanding of software design processes and methods. Currently, I am in this situation writing a Java based reporting system, with a database backend, and have come to many of the same frustrated dead ends. Management wants the latest and greatest, and therefore, anything that is already written isnt good enough.

my apologies for restating some points mentioned earlier, but they were relevant._________________________________________E-Bitch
Tempora Mutantur Nos et Mutamur in Illis"The Times are Changed Even as We are Changed in Them"

I will second the remark on CPAN modules being hard to discover. Another issue is that sometimes the documentation leaves quite a bit to be desired.

And then there are us poor losers who haven't really gotten the perl OO model. Yeah, it's great, blah, blah... But I find in some cases it is more efficient to simply write the function myself. Using Win32::Process may save you some headaches later on down the road, but if all you need is a "rsh" to get the DF output from the Unix boxen, you have used the backticks about halfway through the module docs.

One final note, modules are essentially code I don't write and maintain. That just plain makes me nervous. Maybe I'm just paranoid, but I know the code I write, and I can read the code I write. Saves me from posting "Segfault using Storable" posts all of the time.

From the tone of your post, it sounds as though you have some specific beef with your companies use of Perl, and have extended it to the larger world of Perl outside of that enclave.

Perhaps an application should be a collection of generically useful modules. Perhaps you should rephrase "modules" as "objects" and we can get down to making Perl work like VB.

The trurth of it is my friend, Perl is a reporting language, not a RAD tool. It does an admirable job of being a RAD tool, future versions of Perl seem to be working to position Perl as a RAD tool, but at it's heart it is still a pathologically eclectic rubbish lister.

Does your boss not allow you to use modules?? Or is your programming team not up on module usage and you have to maintain their code? Then it is an issue of training and education either for your boss or your programmers.

Getting what you want generally does not involve saying, "You are an idiot! Now meet my demands." Inform him why a module might be better. "Hey boss, did you notice that the Bubble::Yum module can simulate chewing at three different speeds?? Our program only does one speed. Maybe we should check out that module."

So rewrite 2-3 programs that you think would benefit most from modules. Test for speed, etc. Since writing with modules is so trivial, it should take you hardly no time.

If you cannot find where the module is an improvement, then there should be no need for the module. Simple. Once you have shown him 2-3 programs that could be drastically improved by modules, he'll probably have you rewriting all of the code to use modules and you'll just complain about that.

I have to fully agree with princepawn when it comes to reinventing the wheel in your production environment, but I did want to add that I believe that reinventing the wheel isn't all bad. It is best done on your own system where nobody else has to troubleshoot it when you are gone.

Sometimes, reinventing the wheel is the best way to learn about something. You still have the good code from CPAN and from fellow monks, but learning from your own mistakes isn't always a bad thing. You just don't want to go doing them where it matters to more than just you