Are you happy with that? Does it pay well? But perhaps most importantly, are you proud of what you do? Sounds to me like one of the answers may be no. So maybe you need to find a more adveturous client. Or you need to find a stand-alone app with a windows (or portable, after all this is Perl) GUI.

I am 49 and Perl hacking pays far better than being an engineer, scientist or academic (I have done all three and more besides). But I wish I could get my clients to stay small! If you want to grow, find a client who wants to grow as well. This last few weeks I built a 1500 line Perl/Tk/DBI app for one client, added 5-6,000 lines to a CGI nightmare for another client, and I am planning a re-write of 20K+lines for a stock app and a Web-App which should keep me busy for months on that one project alone. The secret? I found a go-getter client who has a little money to pay for his dreams. He has been using me for 4 years now and his dreams, his projects and his budget just get bigger and more sophisticated!

And, yes, officially the language is known as Perl.

jdtoronto

absolutely, you should be learning new skills and techniques. the technology isn't standing still. if you don't keep up, you'll become obsolete.

how about more sophisticated web application frameworks? CGI::Application might be a natural next move for you. mod_perl? Object Relational techniques and modules like Class::DBI?

maybe branch out on the client end. take one of your server side apps, give it an XML-RPC interface, and make a GUI client in Tk, or GTK, or whatever that replaces the web interface but allows you to create a richer user interface.

check out other languages and their frameworks. see what you can learn from Tomcat and Struts. try to understand the design of Zope. figure out their advantages and disadvantages compared to your Perl based approach. can you figure out how to take some of their ideas and integrate them back into your development?

the fact that you can solve any problem with CGI and DBI doesn't mean that those are necessarily the best tools for a particular job. the only constant in our industry is change. other people are always coming up with ideas on how to make development faster, easier, and more flexible. you can either keep up and keep bringing in those new ideas, or slowly turn into a dinosaur and lose work to those of us who do keep learning the new stuff.

Not long after starting my first Perl job, I decided that for each new project, I should try something new. A new module, a new construct, a new methodology, a new testing strategy, whatever. It hasn't always worked out, but much of what I've done has saved enough time that my employeer doesn't mind my few failed attempts.

If I was interviewing someone for a potential job and he or she had been writing CGI applications for 5 years without seriously investigating what resources were available to do things better, then I would recommend against hiring. Here is why:

1. That person will be unfamiliar with every module that is at my workplace. That would be a long learning curve.
2. That learning curve is likely to be slow - you need to learn how to pick up and evaluate new modules. If you haven't learned, then you are unlikely to be familiar with the necessary techniques when you first encounter them.
3. I would automatically distrust his or her design sense. The heart of good design is a tendency to question whether problems that come up could be solved in a better way, and searching for what that might be. This is not consistent with sinking into a rut and staying there for 5 years.
4. I would be inclined towards distrusting his or her skill level. There is a difference between 5 years of experience, and one year of experience repeated 5 times. This sounds like the latter happened.

Sorry, but this is my reaction. Whether or not you care about it is your decision.

If you do care, then a few places to start are by looking into source control systems, playing around with Class::DBI, or searching for templating systems. Or you could read a book, either Perl-specific (O'Reilly has a pretty good library, add in TheConway's OO Perl if you want), or more general (Code Complete is a good start).

Oh, and as pointed out by Abigail-II, start calling the language Perl.

If I was interviewing someone for a potential job and he or she had been writing CGI applications for 5 years without seriously investigating what resources were available to do things better, then I would recommend against hiring.

And if I was interviewing someone for a job and they posted this I wouldn't hire them either, but that's not the slightest bit relevant now is it?

punchcard_don is not asking "would you hire me based on this post" he's asking for recommendations on whether other areas of Perl programming are worth learning¹. Saying "I'm wouldn't hire you cause you suck nananananana"² in response doesn't really add anything to the discussion.

In addition, he says he's been "working with Perl for 5 years now." That doesn't mean it's been his full time employment, it doesn't mean he claims to be an expert, it doesn't mean anything more than he wrote.

Either way, he's asking for advice and trying to learn. Your reply definately won't assist him in that area. I expected better.

¹Before it's pointed out. Yes, everything is worth learning, but currently time is finite so you have to prioritize.

²Not a direct quote.

Out of order points of reply.
• My presumption that he had been doing Perl for work is based on his phrase, ...but work has never brought me to these places.
• His phrasing, ...am I an accidental wise-man...is some of this other stuff marginal and/or just for elegance? strongly suggested to me that he is looking to validate his continued non-investment in self-education. I therefore wanted to write a reply that he couldn't possibly misinterpret. Yes, I am reading between the lines there. I know that my habit of trying to read between the lines sometimes gets me into serious unnecessary trouble. But I believe that the times I hit on something important that would otherwise have been missed pay for the occasional debacle.
• I think that it is relevant that you independently would have decided based on the above information to not hire. That demonstrates that my opinion is not exactly an isolated one. I think that it is nicer to honestly tell people who ask where they can improve than to be silent and let them be confused later about why they are being rejected.
• I thought that it was worthwhile to add to this thread a short discussion of some of the things that people (both the original poster and other bystanders) should look to get out of their own learning efforts.
• The only set of expectations that I try to satisfy are my own. I long ago accepted that trying to meet other people's expectations is a losing game which I won't worry about. OK, I'm not as extreme as Linus, but I certainly understand where he is coming from...

If you can do it all using simpler constructs, why would you want to complicate things?

Especially in a work situation, it's not about golf/obfuscation. KISS.

Have you had to get it all smoothly working under mod_perl?

That, for me, was the logical progression from CGI.

Next from that was optimizing as much as I can on servers to maximize client availability and accessability speeds - a long, occasionally random learning curve on server guts :)

.02

cLive ;-)

Well, it's equally possible that you've been an unwitting simpleton, coming up with your own solutions to problems that have already been solved by "exotic" modules. Have you written your own code to add one or more days to the current date so that you correctly form a past or future date string (instead of using Date::Manip)? Have you been using pure regexes to find or alter stuff in HTML text data (instead of using HTML::TokeParser)? Do you use system() calls to run commands that do things like file compression, base64 encoding, MD5 signatures (instead of using Compress::Zlib, MIME::Base64, MD5), etc? If this applies to you, then you've been working too hard to write your own code, and not working hard enough to improve your ability to write good code.

To your credit, your two favorite modules are heavyweights -- having control of CGI and DBI is nothing to sneeze at, and you can cover a lot of ground without getting bored. (Let's face it, you couldn't do what you normally do without them.)

is some of this other stuff marginal and/or just for elegance?

If you browse CPAN without a specific need in mind, yes, you will come across some marginal (even frivolous or downright pointless) modules. Maybe a lot of them. But quite a few things that you haven't tried yet do happen to be mission-critical and highly valuable for other people.

For example, there are whole classes of crucial apps that cannot be done without fork(), and the fact that you have not been involved in developing such apps (yet) just means that you haven't been in that particular line of work. (Indeed, it may be relatively rare for a CGI- or DBI-based app to use fork.) So, yes, you've been leading a sheltered life in that respect. Maybe that's a bit like saying a plumber leads a sheltered life because he hasn't used a torque wrench or a timing light -- which has nothing to do with how good a plumber he is -- but if you like the idea of being adaptable (like someone who can do both plumbing and car repair), then it's time to get your hands dirty with some different kinds of work.

If this applies to you, then you've been working to hard to write your own code, and not working hard enough to improve your ability to write good code.

I wasn't aware writing code and improving your ability to write code were mutually exclusive. There are even cases where you wouldn't want view existing code prior to doing it. Guess I'm just an unwitting simpleton ;)

I guess I didn't quite convey what I meant. My point there was: if you haven't been using modules to help with common or complicated parts of an app, then you're working too hard by trying to write these parts on your own, and you are probably going to make mistakes that a module author has already taken care of (so your code might not be so good). If instead you were investing time to learn the use of good modules, you would (usually) be able to write better code (and usually take less time overall to finish an app).

It's not that working hard and writing lots of code will be of no use for building skills -- surely practice leads to improvement. It's just that improvement can go much faster when you see how other people solve problems, and you "stand on the shoulders of those who came before you".

Have I been leading a sheltered life,

Abigail

I always kind of liked PERL. It has an ominous, all-powerful sound to it, kind of like COBOL ;-)

The real test is which sounds more impressive Perl vs Ruby, or PERL vs Ruby. Do not underestimate the power of the allcaps!

And to the original poster:

First a clarification of the above: Perl is the correct way to refer to the language, perl refers to the actual executable. Hence, you hear sayings like "Only perl can parse Perl." PERL is just a common incorrect spelling of Perl. Of course, anyone who actually bothers to learn these things, and especially bothers to correct people about them, has way too much time on their hands ;-)

As for leading a sheltered programming existance, do you know any other languages? Perl is just a language. There are a great many things Perl simply cannot do, and many more that it is horrible inefficient (in execution time, memory use, maintainability, and more) at doing. If you haven't already learned them, I recommend taking the time to learn Python (or Lisp, I prefer Python), C, and Prolog (that order is probably best).

If you already know those languages, or are just looking to expand in Perl's realm here are a few things you should definately check out:

• mod_perl Perl module for the Apache webserver. Blindingly more fast than CGI which has to start up perl for each request.
• CPAN, CPAN, CPAN An endless source of excellent inspiration. Pick any area you're interested, search for it and you're bound to find something useful (or at least interesting :).
• Future Perl (and related project development): Perl 6 and Parrot offer some very interesting advancements. Subscribe to the mailing lists, download the source, write some parrot assembly. Fun, Fun, Fun :)

Also, you may wish to take a more detailed look at other methods of data representation. Compare different databases (relational or otherwise) and more advanced data structures and the algorithms that manipulate them. Information theory is also extremely interesting albeit a bit out of the scope of your question.

Oh, and one more thing. Avoid Perl poetry and Obfuscation like the plague. That shit will mess you up permanantly ;-)

There are a great many things Perl simply cannot do

Yes. These things include:

• Solving the Halting Problem
• Parsing natural languages (yet)
• Solving the Napsack Problem in polynomial-order time (or can it??? :-D )

I mean, come on... Perl is Turing Complete (standard boilerplate regarding assumptions about sufficient storage room, as Turing Machines, technically, have unlimitted memory), and thus can do anything that a Turing Machine is capable of. Every other programming language that currently exists (bearing in mind that there aren't any programming languages yet developed for quantum computers, which could, possibly be something beyond a Deterministic Turing Machine) is no more capable than a Turing Machine. Therefore, I can safely state that there is nothing which Perl "simply cannot do", but which other programming languages can do.

To paraphrase: Perl can do anything that can be done on a computer, and no programming language can make a computer do more than a computer is capable of doing.

Of course, you could have been trying to use hyperbole, or being figurative...


------------
:Wq
Not an editor command: Wq

But hey, I've seen people refer to Ruby as RUBY. I don't know what they think it stands for. Maybe since PERL is spelled in all caps in all the Teach Yourself PERL books, they figure RUBY should be too?

-- Mike

--
XML::Simpler does not require XML::Parser or a SAX parser. It does require File::Slurp.
-- grantm, perldoc XML::Simpler

too bad you posted as an anonymous coward, I would have ++ you if you had logged in.

s/PERL/Perl/g;

I don't know how enlightened or clever this is, but I follow a fairly strict pattern of behavior whenever I run up against a new problem; go to search.cpan.org and type in all the relevant keywords I can think of. Spending the time looking through the list usually quickly establishes if I'm contemplating a new wheel or at the very least, a better way to go about my new wheel.

Following links to modules from responses to perlmonks and other discussions is also helpful, since it at least exposes me to modules I might otherwise not even think about.

Having said all that, I've actually been criticized before for consistently recommending CPAN modules on a project... it seems anyone can download and install modules, but real code monkeys hand code everything. I backed away slowly, in case sudden movement caused the critical overload of this person's synapses.

Thank you all (or at least most) for your thoughtful replies. They have been as interesting a study in human nature as they have been informative on the subject of PeRl modules. :-)

Several have hit the nail on the head

- yes, I have written some interesting regex's to rewrite html pages and although that was personally satisfying to overcome that challenge through brute creativity, my schedule probably would have preferred I have a working knowledge of the applicable module

- the plumber analogy was an excellent one, as I do alot of plumbing too. 95% of the work is accomplished with boring old tape measure, pipe cutter, garnet paper, torch, solder and flux. But what really impresses is when you know how to properly adjust a pump's pressure cut-in and cut-out switches to make the whole thing actually work. On the other hand, those fancy wire-brush deburrers may be easier to use than garnet paper, but they don't prepare the surface nearly as well. They're the tool of the lazy man who wants a flashy tool in his toolbelt. And that was the gist of my question - looking beyond the torch and solder, are these other tools really helpful, or just all-too-common hype of those trying to look interesting?

- typical problem of the independent - setting aside non-bilable time to keep skills up to date. As much as I love being an independent, one great thing the employees have is that cozy security of being able to learn while somone else pays the bills. As someone said, time is not unlimited and must be managed. Time constraints have obliged me, in recent years, to adopt a needs-pull approach: learn as needs exceed knowledge; as opposed to a knowledge-push approach, but the motivation behind this thread is a desire to change that.

What I've taken away from this discussion is that there are a number of very useful modules, so off I go to check them out.

Well, this (and some of the other comments in here) raise an interesting point... search.cpan.org is, well, sort of hard to use. There are hundreds of useless or duplicative modules cluttering up CPAN searches. People never know where to start. It's almost become a matter of arcane knowledge what perl modules are good to use. I mean... how often on this site do you find questions like "between modules X, Y, and Z (which all do basically the same thing), which one is best / compare and contrast" only to have answers like "Oh, you haven't heard of module P or Q? They do that, too".

I guess what I'm getting at is: has anyone considered putting together a sort of meta-index of CPAN modules? What's actually a useful module? If I'm building X class of application, what are a few modules I should seriously investigate using? That sort of thing.

Are there already such sites? If so, where? (Hmmm... maybe I should have just posted this to meditations.)


------------
:Wq
Not an editor command: Wq

Something along those lines can be found here. It's beta, but seems useful or interesting from my limited usage. Watch out for folks venting their personal religious views, instead of actually giving a critique of the module.

Good points! Both you and the OP might consider digging up perl.com There are reviews and tutorials for the selective CPAN modules.

perl.com is the place I first found out about Class::DBI. It was love at first sight. :))))