Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

Features missing in perl IDEs?

by BUU (Prior)
on Jun 16, 2005 at 06:06 UTC ( #467179=perlmeditation: print w/replies, xml ) Need Help??

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?

Replies are listed 'Best First'.
Re: Features missing in perl IDEs?
by dragonchild (Archbishop) on Jun 16, 2005 at 13:06 UTC
    (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.

    • In general, if you think something isn't in Perl, try it out, because it usually is. :-)
    • "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"
      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++.
        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.

        • In general, if you think something isn't in Perl, try it out, because it usually is. :-)
        • "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"
      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...

      An idea is not responsible for the people who believe in it...

        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.

        time was, I could move my arms like a bird and...
Re: Features missing in perl IDEs?
by johnnywang (Priest) on Jun 16, 2005 at 06:16 UTC
    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.
      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)

      We're looking for people in ATL

      Just curiously, what do you want to do by programming the IDE? Short cuts? Macros?
        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.
Re: Features missing in perl IDEs?
by Ctrl-z (Friar) on Jun 16, 2005 at 10:03 UTC
    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.

    time was, I could move my arms like a bird and...
Re: Features missing in perl IDEs?
by techcode (Hermit) on Jun 16, 2005 at 09:03 UTC
    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) { }
      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.
Re: Features missing in perl IDEs?
by GrandFather (Sage) on Jun 17, 2005 at 05:33 UTC

    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!

    Perl is Huffman encoded by design.
Re: Features missing in perl IDEs?
by adrianh (Chancellor) on Jun 16, 2005 at 23:24 UTC
    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.

      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?

        I wondered the same thing and found these.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.
        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 :-)

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://467179]
Approved by idsfa
Front-paged by Old_Gray_Bear
[LanX]: before digging into deep debugging ... I have a strange UTF8 problem, probably it rings a bell:
[LanX]: two utf8 strings from different sources are base64 encoded, but after joining both the umlauts in teh second get deleted
[Corion]: LanX: You can't just join two base64 strings together
[LanX]: (not a high priority bug because I can use some HTML entities in the second string)
[Corion]: base64 is padded to a multiple of 4 chars (or something)
[LanX]: misunderstanding, I joined them before converting to base64
[Corion]: Also, I would be wary of encodings and try to make really sure that both input strings are UTF-8. Maybe join the input strings from one source together to see whether they decode as bad or not

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (9)
As of 2017-01-16 13:51 GMT
Find Nodes?
    Voting Booth?
    Do you watch meteor showers?

    Results (150 votes). Check out past polls.