http://www.perlmonks.org?node_id=788619

LanX has asked for the wisdom of the Perl Monks concerning the following question:

... and where is the line between IDE and editor?

There are so many threads asking for IDEs and comparing apples and oranges ...

What are possible¹ criteria?

just a brainstorm

Editor

IDE

(to be extended...please help)

Cheers Rolf

UPDATES: Adding updates from the discussion as italics

(1) of course there is no objective fixed set of criterias, my aim is to get the possible directions/dimensions for evaluating IDEs. For further clarification see this post

  • Comment on What are the criterias of a "good" Perl IDE?

Replies are listed 'Best First'.
Re: What are the criterias of a "good" Perl IDE?
by ELISHEVA (Prior) on Aug 14, 2009 at 16:20 UTC

    Thinking from the team management perspective, the most important features for me are

    • support for multiple development languages
    • support for integration with 3rd party and in-house tools:
      • ability to customize based on data stored in files and environment variable - ideally without having to copy data stored elsewhere for other tools into a tool specific format.
      • ability to accept inputs and send outputs to third party tools
      • ability to customize the entire menu - not just a dedicated list of plug-in menus
      • ability to integrate custom version control systems, build systems, debugging tools, diff support, refactoring tools, project management tools, and so on.
    • ability to set site wide defaults
    • ability to bundle up and distribute customizations
    • ability to layer personal customizations on top of sitewide defaults
    • not too difficult to learn customization/integration interface

    If all of the above exists we can make, buy, or download the rest - syntax highlighting, etc.

    Nice to haves would include:

    • trouble-free support for local editing of remote files
    • built-in syntax highlighting that can be replaced with custom tools.
    • built-in jump to error API (to facilitate integration with custom debugging tools)
    • built-in space-to-tab management
    • A robust plug-in/add-on development community
    • A customization language that lets team members customize their tools using whatever language they typically program in. A second best would be a language that is commercially important to us so that form-fitting tools to one's work habits also encourages/reinforces languages that I would want all team members to know. An IDE with Perl as the customization language would definitely pass that requirement!

    Best, beth

Re: What are the criterias of a "good" Perl IDE?
by SuicideJunkie (Vicar) on Aug 14, 2009 at 14:12 UTC

    In order to be an IDE, it needs to integrate enough things that are not just editing. How much and what depends on the user a bit.

    • For me, I would call anything that only requires interaction with the source files (and some editor config files) to be pure (if fancy and smart) Editor territory. Syntax highlighting, code folding, autocomplete, and even a bit of analysis like "jump to definition". The latter requires knowledge of the language rolled into either the executable or some fancy config files.
    • I would consider something that includes buttons for a few external things like diff and docs and cvs to be technically an IDE given the Integration and use for Dev purposes, but dismiss it as an editor with bloat and probably overspecialization too.
    • Once the editor hooks into a debugger, then I'm happy calling it an IDE. Breakpoints and variable inspection are a given, being able to eval arbitrary code while waiting at a breakpoint is bonus.
    • A "good" IDE to me, would depend on how well put together it is. Stability and UI primarily. This also depends on what competition is out there, as the subjective properties are very relativistic. The number of extra integrations required would also depend on the competition.
Re: What are the criterias of a "good" Perl IDE?
by neo_ (Novice) on Aug 14, 2009 at 13:00 UTC
    Code folding is always nice. Not sure if you mentioned it above under another name.
      Thanks, common terminology is always a problem... 8(

      Folding is called "outlining" in emacs, anyway IIRC outlining is also used to indicate navigating trees in filebrowsers...

      @all: Please don't hesitate to give input because you're not sure about terminology!

      ... I will try to update the list and trying to make it CIS="Cross-IDE-Speech" ;-)

      Cheers Rolf

Re: What are the criterias of a "good" Perl IDE?
by BioLion (Curate) on Aug 14, 2009 at 13:17 UTC

    I guess it is part of syntax highlighting, but what about error/style highlighting?

    For example - I love Eclipse for writing Java because it also gives errors/warnings highlights next to the code, and also style advice if you ask it too, so you don't even need to rub the code to find errors. I guess sometimes it can be too much (like that paperclip that everyone hates), but i find it very useful because i don't spend the majority of my time writing java.

    Maybe an IDE that supported perlcritic || perltidy would be useful too.

    Just a something something...
      Have you tried installing EPIC (Eclipse Perl Integration) for eclipse? It supports perlcritic and perltidy and pod::checker.

      http://www.epic-ide.org/

      I've been using it for quite a while now (learned about it at a YAPC conference... thanks to whoever it was that gave that talk... sorry, don't remember your name, and thankyou to the author... thankyou!).

      It is slow on UNIX (solaris) although I still use it because I like all the extra features.

      works great on windows.

      Sandy

        Yes - I tried it some time ago, and then moved away from it for some reason - it obviously has had a lot of improvements since then, so i will check it out. Thanks for the tip (Sandy++).

        Just a something something...
      Like in this image ?

      So you mean you prefer the error/diagnostic message and error line blended together instead of having both in separate subwindows?

      UPDATE: The technical term for this is "bubble text", right?

      Cheers Rolf

        Yes - the bubbletext is what i meant - call me simple but i like it when all that information is integrated, but without being too intrusive, The best example being the on-the-fly error checking i think.

        Just a something something...
Re: What are the criterias of a "good" Perl IDE?
by scorpio17 (Canon) on Aug 14, 2009 at 13:42 UTC
    I think a 'good' IDE is one that bundles all your other tools (editer, debugger, etc.) in such a way that you're able to work in a single, common environment. For perl I use Eclipse with the EPIC plugin. It supports the debugger, perltidy, revision control (with another plugin for svn, for example), perldoc, code folding, etc. Also has an integrated 'web browser' for developing cgi scripts locally.
Re: What are the criterias of a "good" Perl IDE?
by moritz (Cardinal) on Aug 14, 2009 at 13:21 UTC
    For me a brainstorming begins with collecting goals, not means. For me an IDE or text editor should make perl programming
    • efficient
    • fun
    • simple
    • not tiring

    The one means that I'd like and that is missing on your list is integration with a REPL.

      what about
      • producing a nice brown tan?
      • attracting beautiful women to my workplace?

      ;-)

      The one means that I'd like and that is missing on your list is integration with a REPL.

      some people consider the debugger a REPL, but as a frequent user of sepia I gladely add REPL to the list. 8)

      Cheers Rolf

Re: What are the criterias of a "good" Perl IDE?
by JavaFan (Canon) on Aug 14, 2009 at 23:45 UTC
    Here's what I think is a good IDE:
    • It doesn't get in the way of an experienced user. Or, more strongly, it's aimed at the experienced user. Remember, you're only a newbie for a short time, and experienced for a lot longer.
    • It works right out of the box. Even without your personal configuration file, it should feel "home". Little configuration should be needed in general.
    • It should be there when the OS is freshly installed, for any OS I work with.
    • It should come with a manual page. Manual pages are written in *roff. Not in infodoc. Not in HTML. Not in XML.
    • It shouldn't be geared towards a specific language. It should be equally usable whether I write Perl, C, LaTeX, SQL, an email or a plain text file. I don't want different IDEs for every task I work on.
    • It should run on any console or terminal that's capable of cursor movement.
    • It should be fast enough that it can work over a network.
    Luckely, vi and its lookalikes have been doing that for me for about 30 years.
      Oh, and one that's so basic, I forgot to write it down in the first place:
      • The entire things should be controllable by a standard keyboard, using keys that are in the same place on most keyboards. No mouse, nor arrow or function keys needed for any functionality.
      Remember, you're only a newbie for a short time, and experienced for a lot longer.

      I'm sorry to say that I've worked with people who have worked very hard to disprove this statement.

      But, I'm a vim user, so what would I know.<grin/>

      G. Wade

      I bet it is easy picking out your car in a crowded carpark: It'll be the one with Rostyle wheels, an eight-track player and a whip arial.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

        "I bet it is easy picking out your car in a crowded carpark: It'll be the one with Rostyle wheels, an eight-track player and a whip arial."

        Wot no furry dice!

        Mine is the fully mechanical old timer, which goes for $100,000 at auctions, and doesn't need a laptop plugged in each time a warning light goes on.
Re: What are the criterias of a "good" Perl IDE?
by doom (Deacon) on Aug 15, 2009 at 03:43 UTC
    Use cases:
    • Take me to the definition of this routine.
    • What routines are defined in this module?
    • What methods do I have available on this object?
    • Rename all occurences of this variable name
      • in the current scope
      • globaly, throughout the project
    • Rename this routine throughout the project.
Re: What are the criterias of a "good" Perl IDE?
by dekimsey (Sexton) on Aug 15, 2009 at 14:29 UTC

    For me, something that always bothers me is the fact that I generally work through on a server running putty (linux) on my client machine (windows). Most IDEs like EPIC expect that the libraries are installed locally. The debugging messages it provides are down-right useless. Attempts at using X11/Xming or the like to run across the network makes the interface slightly more laggy than I'd prefer. And some other random quirks.

    I'd love to see an IDE that supported editing files remotely over sftp or the like. And fully supporting the fact that the entire environment of where the application should be tested, debugged, and run occur server side at the remote location.

    I haven't found an IDE that can manage this. This is the one thing that prevents me from switching from vim.

    Danny.

        Unfortunately this solution does not take into account the system libraries and the environment the application is normally run in. Not to mention the pathing issues that arrise.

        I guess the editor would need to be able to edit/execute/test files through an ssh shell.

        Danny.
Re: What are the criterias of a "good" Perl IDE?
by JavaFan (Canon) on Aug 14, 2009 at 15:08 UTC
    What are the criterias of a "good" Perl IDE?
    What kind of question is that? There's no answer to that. Different people will have different criteria, and even if they have the same criteria, they'll have different tresholds as to when it's "good" and when it isn't.

    I'd say, everyone should use whatever he/she finds to work best for them, and just ignore what other people find "good".

    Now, personally, the #1 criterium for a "good" IDE for me is that it should leave the colours as I define them. Text is black, and no other colour is to be accepted. Having a screen full of different colours makes it look like a kindergarden booklet. ;-)

      Different people will have different criteria, and even if they have the same criteria, they'll have different tresholds as to when it's "good" and when it isn't.

      No doubt, but most people can't express their criteria or usually are ignorant about the possibilities.

      Or do you have the time to test all products in deep???

      My interest is to break down this hole IDE discussion into understandable concepts, instead of all this confused "proto-flames" where apples are compared to oranges.

      The best outcome would be to be able to build up a matrix with criterias as rows and applications as columns, and everybody could choose which rows meet his individual needs to find the subjectively optimum IDE / Editor...

      Cheers Rolf

      A reply falls below the community's threshold of quality. You may see it by logging in.
Re: What are the criterias of a "good" Perl IDE?
by targetsmart (Curate) on Aug 17, 2009 at 05:38 UTC
    In addition to what you have told, having vim editor support would be awesome (like Eclim).


    Vivek
    -- 'I' am not the body, 'I' am the 'soul', which has no beginning or no end, no attachment or no aversion, nothing to attain or lose.
      Thanks for the link! 8)

      Anyway Eclim seams to be a very special and somehow confusing example of melting together a common IDE with a common editor instead of emulating.

      Do you rather mean that products should have UI compatibility modes for common editors?

      Many projects assume that emacs and vim keybindings are the two "lingua francas"¹ of editing.

      E.g. Komodo edit has "Vi emulation" and "Emacs keybindings"

      Or emacs has various vi-emulations like vi-mode, viper-mode, ... and CUA-mode to emulate windows copy&paste behaviour.

      That's what you mean???

      Cheers Rolf

      FOOTNOTES:

      (1) this standard is also reflected in bash and readline offering. From `man bash`:

      By default, the line editing commands are similar to those of emacs. A vi-style line editing interface is also available.

Re: What are the criterias of a "good" Perl IDE?
by SFLEX (Chaplain) on Aug 15, 2009 at 11:39 UTC
    I like to use EngInSite - Editor (IDE) for Perl it has some of the features you have listed for the free "lite" version. Its a windows editor.
    I don't need my Perl editor to do much, but the things I like a Perl editor IDE to do is;
    Syntax-highlighting
    Flymake (syntax check on the fly)
    Browser-subwindows and "variables"
    un/comment Lines of code

    Information is knowledge.
Re: What are the criterias of a "good" Perl IDE?
by jms53 (Monk) on Feb 10, 2014 at 23:01 UTC

    I'm not sure if this is included in 'Flymake', but I REALLY appreciate being able to execute my scripts from within Geany, and then once I've seen the result, close the terminal window. I know you can do this in Vim, but Geany has this beautiful documents sidebar...

    If I was able to controll the input from within the editor (similar to http://ideone.com, I would consider that an IDE feature

    J -
      > but I REALLY appreciate being able to execute my scripts from within Geany, and then once I've seen the result, close the terminal window.

      Yes this was (meant to be) included in Turnaround / Jump to Error

      I configured F5 in emacs to run the code, open a frame with the output and jumping to errors.

      Thats basic, every IDE should provide this.

      > but Geany has this beautiful documents sidebar...

      Geany is really neat, I think you generally mean a multiframe layout with specialized help windows like in ECB

      > If I was able to controll the input from within the editor (similar to http://ideone.com, I would consider that an IDE feature

      good IDE's allow multiple frames/windows and actions can be scripted, like saving a textbuffer automatically and feeding it as STDIN into a program.

      I'm not sure about the easiest way to do this in Emacs or Komodo¹, but I never really needed this on the editor level.

      Either it belongs to testing or it's handled with reading from <DATA>, both things happening on the Perl level.

      Cheers Rolf

      ( addicted to the Perl Programming Language)

      update

      ¹) see also http://docs.activestate.comkomodo4.4/run.html#run_advanced

      in emacs I'd define a macro recording keystrokes to saves the script buffer and runs command with another text-buffer as input. These macro can be saved to file and bound to a key.

      Having a code-wizard (like Komodo does) is for sure helpful.