Padre?

http://padre.perlide.org/

I don't use it, too slow compared to just "vi" and a command line. I can type quickly, cannot click a mouse 1000 times quickly to do the same thing. Given that I find it uninteresting so I'm not a sympathetic reviewer, I have played with padre enough to see it works and has quite a few features and is free. I've seen it improve over the years. I'm not sure what specific barriers are reduced by an IDE like padre, as most of the features seem only of benefit to truly immense non-modularized projects which culturally don't "fit" well in Perl. If it can't all fit in your head at once, abstract something out into a separate package complete with unit tests and shrink it until it does fit. And a large full screen editor with no IDE in the way makes it easier to fit in your mind rather than a small postage stamp view of the code. That all said, I liked seeing the integration in padre with perlcritic and perltidy, just not enough to switch away from vi. I need my screen real estate and keyboard more than I need automated perltidy/perlcritic and mouse shortcuts which have an impedance bump with vi anyway.

Perhaps the best "ide" for a newcomer would be multiple machines/monitors with one very large editor for code, one web browser to google for questions/examples/ideas/docs and one large window for interaction either in the debugger or testing your code. So three monitors minimum connected to 1 to 3 computers? I feel cramped when doing "stuff" with less than three. I can't imagine doing anything other than emergency support with a small laptop screen although I've had to do it in the past.

I'd venture to guess that they aren't doing that because there's little to no market for it.

Although Perl is now a general-purpose programming language, it originated as a scripting language for UNIX systems administration and for parsing text files. Perl's traditional use case is one where you're working on a UNIX server through an SSH terminal, so you only have vi/vim or maybe emacs. In that situation, GUI IDEs are not really an option, and trying to use them kind of goes against the whole purpose and culture of Perl. If you're using Perl, you're probably already comfortable working in a command line terminal and have no need for an IDE.

Also, Perl is complicated and looks "like a cartoon character swearing" (-pg) but a nice thing about Perl is that to learn it, you really only need a computer with an OS (which will come with Perl installed on it as long as it isn't Windows) and the camel book.

Ever heard of Komodo? I've been using it for years for Perl development, plus it supports Python, Ruby, and a host of other languages.

I wouldn't consider doing any serious Perl dev without it.

is Komodo bound in any way to ActiveState perl distribution? or can it be configured to use any perl you have installed, including perlbrew stuff

No. If it were, I wouldn't even consider using it.

Switching between multiple interpreter installations is pretty easy (a drop down in a preference pane) -- it will find every interpreter on your path, and can index anything defined in $PERL5LIB for auto-complete goodness.

The debugger is great -- I love being able to set conditional breakpoints using a possibly complex expression in the native language (not just simple var=val type things).

a bit off topic, i really wish Perl CMSes would stop dropping Postgres support in favour of a MySQL only strategy (Movable Type and WebGUI [Plain Black], this means you). You'd think DBI did not exist or that this was really PHP.

PHP has a database abrstraction layer built into language that offers support for postgres in addition to a couple of fairly popular abstractions / ORMs / other alternatives.

This has nothing to do with either language and everything to do with the projects themselves. Stop dissing languages based on the distant past, especially not when using Perl.

Everything has a database abstraction layer available. The problem is that programmers often don't use them. The perl CMSes obviously aren't using DBI, or they'd still be supporting Postgres... no need to turn the thread into language-related complaining when it is a universal problem.

> ...obviously aren't using DBI

There's really no way to use MySQL without DBI. But at that level, one is still writing db-specific SQL -- perhaps you mean an ORM?

Agreed. I have told JetBeans that they won't get a sale from my company due to not having any kind if perl support (even syntax highlighting). EPIC plugin for eclipse ain't perfect, but its better than nothing.