Loading ...
Sorry, an error occurred while loading the content.

Re: [extremeperl] Re: Better Development Tools for Perl

Expand Messages
  • J Matisse Enzer
    Rob, I really appreciate your point-by-point explanation of how you handle the various items in the list I posted. As you might know, I m working on an article
    Message 1 of 107 , Jun 18, 2005
    • 0 Attachment
      Rob,

      I really appreciate your point-by-point explanation of how you handle
      the various items in the list I posted. As you might know, I'm working
      on an article for perl.com about the need/desirability of better
      development tools for Perl and I'd like to refer to or mention the ways
      you do many of these things. I may include a link to the the Yahoo
      group page for this list and mention that the file area has the tools
      you mention.

      I do have some questions and comments about a few of your notes:

      On Jun 17, 2005, at 8:10 AM, Rob Nagler wrote:
      >> * Syntax-checking - catch and display syntax errors as you type.
      >
      > Sort of. It does brace checking.

      In the code fragment below the syntax checking in the IDE I'm using
      will highlight line 2 because of the missing right parenthesis:

      1. my $name = getName();
      2. if ($name eq 'matisse' {
      3. print "Found $name\n";
      4. }

      In this case it will show an error on line 5 because of the extra ' on
      line 3:
      1. my $name = getName();
      2. if ($name eq 'matisse' {
      3. print '"Found $name\n";
      4. }
      5. print "That's all folks!\n";

      In the following it shows an error on line 3 if 'use strict;' is in
      effect because $naame hasn't been declared:
      1. my $name = getName();
      2. if ($name eq 'matisse' {
      3. print "Found $naame\n";
      4. }

      Here it catches line 3 if there isn't a prit() function:
      1. my $name = getName();
      2. if ($name eq 'matisse' {
      3. prit "Found $name\n";
      4. }

      and so on. Basically it catches virtually all compile-time errors. I
      think that ability (you can turn it off) should be widely and easily
      available to programmers.

      >
      >> * Excellent refactoring support
      >
      > I think so. We have create class, create program (which calls a
      > specific class' main), rename method, add method, insert special
      > method (some methods in bOP have known signatures, Emacs will add
      > those signatures for you), and extract ViewShortcut. You can add
      > private refactorings that hook into the standard refactoring shortcut.

      That's pretty cool. The editor I am using has none of those, although
      it does have extract subroutine. In your case if you do a rename
      method does emacs correct or offer to correct the references to the old
      method name? and if so in just the file you are in, or in your entire
      project?


      >
      >> * Code-assist editor (e.g. get a menu of methods when you type in
      >> an object reference.)
      >
      > Not yet. :-) It's something we'd like to add.

      I haven't found any perl editor/tool yet that does this, but having it
      in Java has really made me miss it in Perl. I believe that in theory
      anyway (dangerous phrase :-) it should be possible to do this 80% 90%
      95%?? of the time - perhaps the new PPI module would help? The big
      trick of course is that the editor/tool needs to be able to figure out
      what is in the scalar - but I think in most cases of non-weird Perl
      code that is possible.


      >> * Managing of dependencies between code files, packages, etc.
      >
      > Unnecessary in Perl. I've found the whole dependency to be a red
      > herring in Perl. Having lived through it with compiled languages, it
      > adds no business value.

      You may be right about that - I added that item to the list based on
      conversations with others but that one doesn't seem to have the same
      weight as some of the other items on the list. The dynamic syntax
      checking discussed above should catch things like:
      use Matisse; # Immeadiate error if editor can't find package
      Matisse

      >> * Performance profiler.
      >
      > Not sure what this has to do with the IDE,

      Some people, doing certain kinds of work use profiling a lot, for
      example running a suite of tests under Devel::Profile, but I agree that
      this item is useful to a fairly small number of people right now,
      although, just as a thought experiment, imagine if it were trivially
      easy to do, just pretend that your tool magically made it a one-click
      operation to run something under a profiler and immeadiatly gave you a
      pretty graph or spreadsheet - in that case we might hit the "profile"
      key or button pretty often, just like running unit tests often because
      it is so easy, and we might learn more about what's happening in our
      code than if it wasn't so easy.

      That reminds me of a central point I think in my thesis here - it is
      not simply having these features somehow available, it is having them
      be really really easy that makes a huge difference. When you have most
      of these features, and they are all really easy to do, you do them
      more, and that makes developing complex projects considerably easier.

      >
      >> * Some kind of networked, shared note-taking (e.g. a Wiki)
      >
      > Personally, I find Wikis less useful than checking in what little
      > documentation you have in CVS.

      I have found in my research that people and teams vary widely in how
      they handle this. There are many variables (whole team in one room?
      different time zones? different languages? personal preferences? email,
      talking, instant messaging, wiki, bugzilla, perforce, CVS/subversion,
      unit tests, etc.) The only more-or-less constant seems to be that if a
      team has some effective way of doing shared note-taking then then do a
      better job.


      >> * "Tree" view of source files and resources.
      >
      > We get this from pod2html.
      >

      Can you explain how that works for you? Do you have something
      dynamically generating HTML and displaying it in a window? So if you
      add a new file it shows up right away?


      > While it is great for an IDE to have GUI, it's not what an expert
      > programmer uses.


      I think you have to admit that there are, in fact, expert programmers
      who use GUI IDE's, even if you don't.

      >
      > I've used my share of GUI IDEs and one of my biggest complaints is
      > that the keyboard shortcuts are always different.

      I think that is a common complaint about GUI's in general among those
      who prefer keystrokes. I believe that some GUI IDE's, like Eclipse
      support emacs an vim keybinding but I would be surprised if a dedicated
      emacs or vim user found that a reasonable substitute.
      >
      >
      > The point is that an IDE is about "integration" not "graphics". Emacs
      > has been an integrated development environment for over 20 years.
      ...
      > Until you've tried it (or vim :-), you can't really say that it
      > doesn't meet your needs, and
      > that it is "behind" other IDEs.

      I agree, and I am not saying emacs is behind other IDE's - although I
      might say that at some point :-) What I *am* saying is that taken as a
      whole, the tools for Perl *are* behind the tools for other languages.

      Let's stipulate for a moment that emacs with your extensions does 90%
      of my list, I would then argue that it still needs (and deserves) to be
      made much more accessible - it would be great if an individual or team
      of intermediate level programmers who *have not used it before* could
      install and configure the package and use 75% of those features
      productively in less than 8 hours of work, say spread over 2 or 3 days.
      That is easily possible for Java with things like IntelliJ, Eclipse.


      -------------------------------------------------------
      Matisse Enzer <matisse@...>
      http://www.matisse.net/ - http://www.eigenstate.net/
      415-225-6703 (work/cellphone)
      415-401-8325 (home)
    • Siegfried Heintze
      Since there was a helpful discussion some time ago on USB keyboards and mice for pair programming that was not specific to perl, I wanted to solicit the group
      Message 107 of 107 , Feb 13, 2006
      • 0 Attachment
        Since there was a helpful discussion some time ago on USB keyboards and mice
        for pair programming that was not specific to perl, I wanted to solicit the
        group for information on network software (also not specific to perl).



        I just set up openVPN on my openwrt/WRT54G router for pair programming with
        a headset and skype.



        (1) Can any point me to the documentation on sharing desktops on windows? I
        need to create accounts on Win2003 XP Server. When I created an account
        belonging only to the user group, my partner could not log in. He was
        receiving some error message about not being permitted to log in
        interactively. However, when I added the administrator group (reluctantly)
        to his account, he could log in. Is there a tutorial somewhere on the web
        for creating user accounts in windows for use with remote desktop logins on
        VPNs?



        (2) How do I share my remote desktop setting with a programming pair
        partner?



        (3) What about sharing sessions when I'm booted with linux? I think there is
        a vnc program out there, but I don't know how to use it. I'll need to learn
        how to create accounts and share linux desktops with remote VPN users. Is
        there a tutorial on this?



        (4) Are video cams very helpful for pair programming?



        It seems that this kind of knowledge would be very common for pair
        programmers.



        Thanks,

        Siegfried



        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.