Hello karpatov,

You'll likely find that much of the community here uses either vi or emacs primarily because they're simple and stay out of your way. One of the problems with fancier IDEs is in addition to learning the language you also have to learn the ide.

I'm aware of these in the way of Perl IDEs although I haven't really used them (i use vi myself).
Open Perl IDE - it appears simple and straighforward with breakpoints
http://open-perl-ide.sourceforge.net/

I've heard good things about Active states Komodo, but the IDE with debugging is somewhat pricey. There is also now a stripped down version of just the editor. Here are the URLs:
http://www.activestate.com/Products/komodo_edit/
http://www.activestate.com/komodo_ide

What I liked about perl from the beginning is it doesn't require you to program any specific way. (Many here may faint at what i'm about to say). When i started programming perl every variable was global and the entire programs I was writing were generally procedural in nature. No subroutines, and yes even a few gotos. Over time I started packaging things into subroutines just for convenience but still exclusively used global variables. Eventually I made the switch to scoped variables and did away with the globals. Then came the creation and use of objects, then CPAN, etc... At times I still find myself using the trusty print statement to drop variable states to the terminal.

I would suggest the following: (much in agreement with fenLisesi)

1. Make sure you put the line "use strict;" on about the second line of the program. It will make programming issues much more apparent.
2. Follow up that line with "use warnings;" it will provide convenient tips when you are straying a bit.
3. When getting started use a short code to test routine. Only add a few lines, save and run to verify that the next step works. With perl its trivial to do unlike compiled languages.
4. Keep it simple. Try to keep subroutines small. The larger they are the more that can go wrong inside them. Once a subroutine is finished and working, you can move elsewhere and trust you won't break whats inside it.
5. If you get truly stumped, write a separate test program to work out just the current problem. I often do this when trying out a new module or data structure that won't cooperate. Often i'll start by making the sample code thats usually in the module documentation work. Then tweaking it in small ways to get a feel for how it operates. Once you get whatever you were trying to do working you can then move that working code into a subroutine back in the main application.
6. The final one that I nearly forgot since I don't use it anymore is a decent syntax reference whether its a good website or perhaps a pocket oreilly perl reference book.

Hope it helps!

Update:
I forgot one of the most essential debugging tools:
Data::Dumper
You can stick nearly any data structure into it and get a decent picture of whats in it (objects not so much).