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

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

Expand Messages
  • Rob Nagler
    ... I find cperl 5.0 gets 99.9% of the way there. It s fast enough for me, too. The only problems I ve seen have to do with defects in the code. For
    Message 1 of 107 , Jun 17, 2005
    • 0 Attachment
      Randal L. Schwartz writes:
      > --- In extremeperl@yahoogroups.com, J Matisse Enzer <matisse@m...> wrote:
      > > * Syntax-coloring text editor.
      > > * Syntax-checking - catch and display syntax errors as you type.
      >
      > You realize that this is not possible for Perl, correct? You can get 90% of the
      > way there, but there'll always be ways that a "perl editor" will be wrong compared
      > to /usr/bin/perl's interpretation of the code.
      >
      > Well, maybe even 97% of the way. But that's even more expensive.

      I find cperl 5.0 gets 99.9% of the way there. It's fast enough for
      me, too. The only problems I've seen have to do with defects in the
      code. For example, 5.0 seems to have introduced a bug that highlights
      builtins in the middle of identifiers, e.g. die_you_gravy_sucking_pig
      would have the "die" highlighted. This bug was not there in earlier
      versions.

      One of the important parts of XP is the coding style a team agrees on.
      The style guide defines what "readable" is to the rest of the team.
      While you can write "zany" Perl, it's rarely a good idea, and doesn't
      add business value.

      Another part of the style guide directly addresses some of the
      requests I've been seeing for IDE features. For example, at bivio, we
      ask programmers to code "fast fail". The net result is that I can't
      remember the last time we (junior or senior developers) used the perl
      debugger. Although Emacs has a Perl debugger mode, we don't need it.
      The stack trace is good enough, and Emacs brings us right to the line
      with the error with its "next-error" command.

      Since there seems to be a dearth of Emacs users on this list, I'll
      point out what Emacs supports today in Matisse's list of requirements:

      J Matisse Enzer writes:
      > * Syntax-coloring text editor.

      Yes.

      > * Syntax-checking - catch and display syntax errors as you type.

      Sort of. It does brace checking. It can't tell you that:

      $x = 1,
      $y = 2;

      is incorrect, because it is correct syntax, even if that may not be
      the semantics you want.

      > * Version control integration - checkout and compare code using
      > CVS, subversion, etc.

      Yes.

      > * 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.

      > * Bug/Request tracking tool.
      > Ideally integrated with the source control system:
      > Put a bug number in a check-in note and it automatically
      > creates links in the project web pages (Perforce does this.)

      I think this is more of a matter for CVSWeb (which I don't use). We
      don't track bugs with a bug tracking tool, because we release weekly.
      If there's a bug, it's fixed in the next release, always.

      > * Support for creating and running unit tests.

      Yes.

      > * Code generation, create commonly used stub code.

      Yes (see above), I consider this dangerous, though. One of the
      problems with stubbed out code is that it often is a target for
      refactoring. For example, the classic get/set of Java is a
      nightmare from OAOO's point of view. We have a base class that
      handles all of that so all you have to do is document the attributes.

      > * 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.

      > * Language-specific help (click on a keyword and the
      > language-specific help is available)

      Yes.

      > * 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. Either all the code is there, or you forgot
      to check something in. Your acceptance tests (this is the XP list
      after all :-) will detect that missing bit of code or they aren't very
      good acceptance tests, and the customer will find the missing bit of
      code, or the missing bit of code is simply not necessary. :-)

      > * Debugger - run your code under a debugger with real-time display
      > of results

      Yes.

      > * Automatic reformatting of code.

      Yes.

      > * Automatically build and test.

      Yes.

      > * Performance profiler.

      Not sure what this has to do with the IDE, because you have to run it,
      and see the results (best in a spreadsheet program imiho). Anyway,
      you can run this in a subshell in Emacs, and it will work fine.

      > * Some kind of networked, shared note-taking (e.g. a Wiki)

      There is Wiki-mode for Emacs, but I would just use the Wiki.
      Personally, I find Wikis less useful than checking in what little
      documentation you have in CVS. Indeed, the code and tests should
      speak for themselves, if this is "true" XP, and you don't need a Wiki.

      > * Ability to choose tabbed or floating display of resource windows.

      Yes. (Not tabbed, but "windows" or floating "frames".)

      > * "Tree" view of source files and resources.

      We get this from pod2html.

      > * Automatic email notice when other people commit code to the
      > repository.

      Part of CVS, if you like. If you are on an XP project, you really
      don't want this. We commit LOTS of files daily, and it would
      overwhelm even the most competent email user. Better to have the
      developer summarize the changes in an email -- even that overwhelms
      most developers. :-)

      Here's what I do to develop:

      * Edit a unit or acceptance test
      * Run it (C-c C-m)
      * Fix the module to make the test work
      * (Possibly) restart server web server (C-c h)
      * Run the unit test (C-c C-m)
      * Find next error (C-c C-e)
      * Repeat :-)
      * Register with CVS and/or check in (C-x v v <type comment> C-c C-c)
      * Release (b-release build && b-release install)
      * Email team (C-c m m <type away> C-c C-c)

      BTW, all of the above can be done in vim, but I only use vim casually
      so I can't tell you how to do it.

      The nice thing about using Emacs is that I get to pull up previous
      comments (M-p) easily. Cut and paste text from the code to my email
      msgs. And so on. All without using the mouse. That means ultimate
      efficiency. The physical movement of my hand to the mouse is at least
      ten keystrokes for me, searching in an analog space is at least
      another ten keystrokes, and then clicking (5-10 keystrokes).

      While it is great for an IDE to have GUI, it's not what an expert
      programmer uses. It's simply too much work to use the mouse to do
      stuff. You learn how to use the keyboard shortcuts. That's where GUI
      IDEs fall apart imiho.

      I've used my share of GUI IDEs and one of my biggest complaints is
      that the keyboard shortcuts are always different. While you may argue
      that Emacs keystrokes are random (and they are), once you know them,
      you know them for most modes. And, it's easy to get a list of them
      for any mode (C-h b) when I don't remember.

      The point is that an IDE is about "integration" not "graphics". Emacs
      has been an integrated development environment for over 20 years.
      It's very mature and robust. It lets programmers optimize their
      keystrokes, which is the whole point of an IDE. 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.

      Rob
    • 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.