> which can be used to force a code-style across the company (hence the name), which is a good counter argument to those that claim perl is unsuitable for large companies/projects.

Doesn't this contradict your later claim that Perl doesn't need an IDE??? ;-)

I like your line of reasoning. As I should state, this boils down to personal preference. I have worked in languages and technologies that are near unusable without an IDE. In many ways, it's also because the environment (read: Windows) doesn't support many of the userspace tools readily available to *NIX users, like grep, or has no readily-available way of printing out data-structures to STDOUT (e.g. Data::Dumper), and if and when you do inspect structures, they are unreadable.

Perl, OTOH, can dump any structure at any point, and you can always figure out "what does perl think X is" which is basically what you need debugging for. There's also less need of the "Intellisense" feature since you're not dealing with tens of thousands of classes and methods, and the libraries you choose have usually a simple and well documented API (yey CPAN Kwalitee).

As for company-mode and code style, I don't think this is an integral part of an IDE. It's more of a feature of existing IDEs, and you can accomplish the same in many other editors and tools, without having to lock-in to an IDE.

Emacs is not an IDE it's an IDE construction set!

That is definitely *the* selling point of emacs, and you can construct it to better suit your needs. Whether you want a debugger, or a code-style, or some sort of CI, it's all available in emacs. You can also integrate emacs with a bug-tracker or similar, and I again point to Org-mode as an excellent project management tool. Also, it has one of the better git integration with magit, which can be seriously helpful in development.

Come to think about it, I would say that, while perl doesn't need an IDE, software development of large projects or in a large company does need a lot of tools to assist the streamlining of the development, and emacs has all of those, and then some.

> I have worked in languages and technologies that are near unusable without an IDE.

I had a colleague once who was considered a "Perl expert".

His work pattern was pretty consistent:

When assigned a new task, he'll

• Fire up Komodo IDE
• As a start: rename an older, similar but incomplete script from the same problem group
• Google for a missing part with "Perl" included in the query
• Paste new chunks and wait if Komodo complains by underlining some line
  ( something like "fly-make perl -c " is activated by default here)
• Make some adjustments, always waiting if lines are underlined
• Repeat the googling process with other missing functionality
• Occasionally run it from the editor
• If it fails add a break point by clicking the line, it now runs under the debugger and stops there
• If inspecting the variables which are shown in a extra pane don't reveal problems stop at the next break-point
• In 80+x % cases he's "successful" with this strategy
• In the other 20-x % cases he came ranting into my office saying that Perl is totally inappropriate for the job ...
  ... and that obviously Python, Ruby, * (fill it in) is FAR better

OK you might say this is not a real "expert" ...

... he doesn't even know how

• to read documentation
• to use perl -c
• to start the debugger and use it's commands
• and other things

But management - which is non IT and has no clue about programming and the long term costs of boiler plating and cargo cult - will say

• that our group has a cheap company license for Komodo
• he gets most his jobs "done"
• that the investment was obviously justified.
• and he can't be blamed for Perl's complexity

Needles to say this "expert" will tell the world that:

Perl is near unusable without an IDE like Komodo.

Punchline? Already one week after I started in this project I knew Komodo (V6 back then) better than the rest of the team together. To be fair ... with all my Emacs experience I knew what to look for.

For instance I tried to help them to switch the internal REPL from Python to Perl - for vain.

That much about bundles with useful defaults.

Cheers Rolf
_{(addicted to the Perl Programming Language and ☆☆☆☆ :)
Je suis Charlie!}

For instance I tried to help them to switch the internal REPL from Python to Perl - for vain.

perhaps there is a global configuration that you could alter, and "sell" it to them as being a part of the regular system updates (I'd assume somewhere in C:\Program Files\...) :-)
P.S. I assumed a Windows "Terminal Server". if everyone is working on their own 'puter, perhaps your sysadmins might help you with a GPO or something...

I wonder how he "programmed" in any of those other languages he kept suggesting. I suspect the same way - and made the same complaints about them.

Well, that's a scary story, in a lot of ways... when I first started playing with the perl debugger I found that some people have a prejudice against debuggers, essentially because they argue that the debugger makes it possible to get code working without understanding it very well.

There's at least a *bit* of truth there... it's true that I resort to stepping through code when I'm having trouble just reading it... but it's always seemed to me that using the debugger encourages me to be a little neater (e.g. all of a sudden I care about having explicit return lines a lot, because that's a place where the debugger can pause... otherwise it returns on you and you lose the scope and can't examine any of the intermediate values any more).

(The difference in perspective between management and programmer's is always a problem... the last place I was working it was hard to convince management that writing tests and doucmentation is not a waste of time. I had the feeling that there were people there who were adrenaline junkies who kind of enjoyed it when things broke... then the whole team comes together and scrambles around finding a fix, and there's a sense of group accomplishment.)