Features missing in perl IDEs?

[BUU]

I've seen a couple of recent nodes/articles that mentioned being unsatisfied with the current perl IDEs. Now personally I'm not really an IDE sort of guy, I prefer vim and the cli, but these complaints make me wonder. What do you think is missing in the current IDE's? What would cause you to use one?

Of course, off hand the the only IDEs I can think of are Eclipse with EPIC and Komodo. Are there any other good IDE's I'm missing?

[dragonchild]

(I'm going to go off on a rant here, about IDEs. Those on the ExtremePerl mailing list will probably recognize it. I've x-posted it in its entirety, originally sent on June 6, 2005.)

I'm still trying to figure out where my projects are going to get complex enough that I need my EDITOR to figure it out for me. To me, that's a CodeSmell and my design needs to be rethought.

I have always looked at IDEs as a bandaid. To me, they are the good programmer's solution to a bad infrastructure foisted upon them by mediocre architects. The Java libraries (and the C++ STL crap) are, frankly, overly complicated. Smalltalk is also rife with this - Bag and Collection and SortedUniqueCollectionThatOnlyWorksOnTuesdaysInMarch ... whatever!

Why should I ever need CodeAssist? Code Complete says that I shouldn't be dealing with more variables in a scope than will exist in 50 lines of code. Ideally, I should be able to see on one sheet of paper everything that I can affect. When I write, I have to justify to myself when the scope goes beyond the size of my window (52 lines).

The methodname completion thing sounds like a good idea. Except, you still need to have documented what those methods do. So, you still need to write the docco. Me - if I had to write the docco for 3245987305734 different methods whose names are 44 characters long and which differ after 12(!) CamelCased characters ... that's an OrganizationSmell to me. That's an organization that -wants- to be obsoleted, and soon.

I just left a contract with a company that, after giving 50% of their profit to the parent, makes over M$150/year. They have locked huge universities and several national patent offices to their products for several _decades_ - and they'll see their profits drop in 5 years.

Why? They rewrote their flagship product in Java. Now, I have nothing against Java per se ... any project that takes 100 developers/designers/testers/architects/etc over 5 years to get to the first beta is going to doom the company.

Now, everyone knows a story like that. Except, I've never heard of a story like that in Perl or Lisp or Haskell. I'll be glad to be corrected, but I only hear stories like that in Java, C++, and .NET ... and I don't think it's a coincedence. The languages that make an IDE go nuts are the very languages that are the most productive to work in.

If I told you I had whipped a project out in a week by myself and changes take 20 minutes, then it was rewritten in the corporate language and it took 4 people 3 months and it still doesn't work right and changes take a week ... could you guess the languages? I'd be interested in seeing a Java -> Perl conversion that meets those criteria.

Basically, there is no IDE for Perl or Lisp or Haskell, and there can never be one. AND THAT'S A GOOD THING. That's a sign that the language is on the right track. If you need an IDE, then that's a sign you will spend way too much time fighting the language (or library) and not enough time making your company money.

[hding]

There are some pretty nice Lisp IDEs out there. All other things being equal (although rarely are they, of course) I'd probably rather work in Lispworks than, say, Emacs+SLIME+CMUCL for example. A lot of people like the Allegro CL IDE as well. While certainly not necessary, there's still a lot to be said for having well integrated inspectors, browsers, debuggers, and so forth, even for Lisp. And I'd think it'd actually be easier (quite a bit easier, actually) to make a decent Lisp IDE than one for something like C++.

[dragonchild]

The Lisp machine was mentioned as an IDE on the list by perrin. My response to that was the programmer is redefining the Lisp machine, which means you're developing your perfect language and the perfect editor to go with it. Now, if you could do something like that with Perl, I'd be all ears.

[bofh_of_oz]

I tend to agree with that. Maybe my opinion is somewhat biased, but I see IDEs as a wheelchair for a programmer - it adds no real benefit over, say, a good editor with syntax highlighting. After all, you're supposed to understand the logic of your program before you sit down to type the code in, right? So all you need from the coding environment is to help you not to make typos.

That being said, a built-in debugger may be a good idea for many programmers, but that's the only thing I can see as useful...

[Ctrl-z]

With all due respect, IDEs are not wheelchairs that figure out the complexity of your program. They are tools that remove the menial, tedious, unproductive, uncreative tasks involved with programming on the CLI. In addition, a good IDE provides a level of support that empowers, not satiates, the developer.

The most compelling example of this, for me, is the ability to aggressively refactor projects and have the editor monitor broken variable references and method invokations across the whole project. Such radical changes on the CLI are big, risky commitments - generally avoided in favour of hacks.

As a human (as well as a programmer) IDEs are a huge step forward in terms of HCI. This may be a bitter pill if you have invested significant time and effort in becoming a vim-meister, but that old crufty UNIX engineer stuff is so passe.

Granted, a lot of IDE benefits are geared towards compiled, strongly typed, Object-Oriented languages. If you dont need that functionality, fine, but to suggest that those that do are in some way disabled is pretty ignorant.

[johnnywang]

The biggest shortcomming is programmable, I don't think any of these IDE's include a scripting language, although it's supposed to be easy to write a plugin for eclipse, in java. I think that's emacs's strength, although I'd love it more if I can script it in my own language. In other words, when an IDE claims to support a language, the IDE itself should be programmable in that language, I guess that's a tall order.

[Fletch]

I think that's emacs's strength, although I'd love it more if I can script it in my own language.

Have you seen Emacs::EPL? (Caveat: I never did much more than tinker with it; it seemed to work but I'm fairly well served by off the shelf elisp stuff)

[BUU]

Just curiously, what do you want to do by programming the IDE? Short cuts? Macros?

[educated_foo]

Here's an example. The other day I needed to number the lines of some code examples in notes I was writing up. Not a built-in editor feature, but a few minutes' hacking in the One True Editor yielded:

(defun my-number-region (beg end)
  (interactive "r")
  (save-excursion
    (let ((end (progn (goto-char end) (beginning-of-line 2) (point-mar
+ker))))
      (goto-char beg)
      (beginning-of-line)
      (loop for i = 1 then (1+ i)
     while (< (point) (marker-position end))
     do (progn
          (insert (format "%-6d" i))
          (beginning-of-line 2))))))

Being able to do this sort of simple customization without knowing about "plugin architectures" and what-not is what I think Emacs got fundamentally right, and is why I never have the patience for Eclipse.

[Ctrl-z]

What do you think is missing in the current IDE's?

A language with a type-system, a concise syntax and a well defined program and documentation structure ;-)

Seriously, I think Perl IDEs have a severe upper limit in functionality - syntax highlighting, capture stdout, debugger etc. The heavy-weight IDE features - refactoring, interactive documentation and debugging, UML modelling, project management, existing plugins - have a poor foundation to build from in Perl.

Most Perl IDEs I have checked out seem to reach this limit, then start adding bullshit features like Code Templates - Im happy sticking with a text editor. Contrast this with programming Java in Eclipse - woah!, vim/emacs and the cli look embarassingly quaint.

I tried EPIC about a year ago and it was pretty buggy, thanks for reminding me to drop by.

[techcode]

While I also use text editor with only sytax highlithing for Perl - I used Visual Studio on university for VB, C++ and now C#.

The things that I like about it are :
- intelisence or however you call it; the possibility that it shows you methods of some object after you enter -> would be nice

- the step by step debuger (maybe komodo has it ?)

Of course there is one thing wich realy makes me crazy about MS VS editor. I'm used to typing

if(expression) {

}

And it keeps "rearaiging" that to

if(expression)
{

}

[wazoox]

I use Nedit, with a perl calltips file I wrote (see it at Nedit perl calltips) and an autocompletion macro. Together, they provide autocompletion and contextual help for all standard perl functions.
I sometimes use ctags too, so I have the same functionalities for all libraries I may use. The only thing I haven't got is the step-by-step debugger, but I really never actually feel the need for it.

[GrandFather]

I use PerlIDE on Windows. The Delphi engine shines through somewhat and there are a number of bugs in the editor, but it is worth it for the debugging. Mouse-over variable evaluation is neat and most of the Perl cli debugger facilities are nicely wrapped up and presented.

I'd like a way to evaluate a piece of Perl in the command window, and I really miss regex serach in the Find!

[adrianh]

What do you think is missing in the current IDE's? What would cause you to use one?

Decent refactoring support is about the only think that I miss in the Perl world.

[BUU]

For my own edification, would you mind elaborating on what you consider to be "decent refactoring support"? What exactly is it? How would you use it?

[BrowserUk]

I wondered the same thing and found these.

[adrianh]

For my own edification, would you mind elaborating on what you consider to be "decent refactoring support"? What exactly is it? How would you use it?

What I mean by refactoring support is the ability to do safe automated refactoring.

For example in the Java world tools like Eclipse allow you to do extract method, push methods up/down the class hierarchy, add/remove attributes, etc. automatically. They become operations on the same level of granularity as "indent block", give you sensible error messages if the refactoring is impossible, and always work.

In Perl if I want to extract a method I have to select the code I want as a separate method. Wrap in in sub {}. Figure out what local vars it needs and pass them as arguments. Figure out what local vars it creates/changes and are used by the rest of the method and return them as results. Add the call to the new method into the old code. Spend a second or two looking at it to make sure I've not missed anything. Re-run the tests just to be sure.

If I'm writing Java in IntelliJ all I do is select the code I want as a separate method, hit Ctrl-Alt-M, type in the new method name and hit return.

It takes longer to describe that it does to do. The IDE does all the tedious make-work for me and it always works so I don't have to spend brain power catching my own typos or running tests to make sure that I didn't break anything.

This is just one example, but I hope it indicates how much developer time decent automated refactoring tools can save. Working without them is like working with an editor that forces me to indent blocks of text by moving the cursor to the start of each line and typing four spaces.

Fortunately Perl makes me more efficient in other ways, so it's still worth while. However I'd really like to be even more efficient - so good refactoring support is top of my list of wishes for my mythical ideal Perl development environment.

The problem is that doing decent refactoring support in Perl is non-trivial. Partly because of the only-perl-parsing-perl problem. Partly because of it's TMTOWTDI nature. Partly due to its flexible runtime nature.

The closest we have at the moment is EPIC/Devel::Refactor which only gives us a fair stab at method extraction. We do now have PPI which is an impressive piece of work and may make future development of Perl refactoring tools considerably easier.

I imagine that Perl 6's explicit grammar is going to make refactoring support considerably easier for that for Perl 5. Still tricky, just not completely insane :-)