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

289Re: [extremeperl] Better Development Tools for Perl

Expand Messages
  • Rob Kinyon
    Jun 6, 2005
    • 0 Attachment
      > However, I think you would have an easier time getting South Korea to
      > hand over their nukes than getting a seasoned vim or emacs user to
      > switch to a different editor. Tools like vim and emacs are IDEs already
      > if you are a power user of them.

      North Korea. :-)

      > > I will say
      > > that using JUnit from within Eclipse is pretty damn easy so I'm not so
      > > sure about Test::More being easier
      >
      > I haven't used it from within Eclipse, so maybe that does make the
      > difference. It's hard for me to imagine anything being significantly
      > easier than Test::More, but Eclipse may make it a tie.

      I have a feeling that Eclipse + JUnit makes whitebox testing easier,
      but blackbox testing is going to be less emphasized. This ends up
      making the tests very fragile.

      > Take Class::DBI for example. If you open up the hood, you find tons of
      > symbol table manipulation, closures left and right, use of the "mixin"
      > approach of automatically defining methods in other people's modules
      > when a class is used, and probably other things that no editor is going
      > to grok. These are not practices that I encourage, but they are in
      > fairly common use by people who consider themselves good perl coders, as
      > you will quickly see if you post something negative about techniques
      > like this in a place like perlmonks.org. I have actually had people
      > tell me that perltidy couldn't parse their code and they felt that this
      > was a problem with perltidy rather than with the insane code they were
      > writing.
      >
      > So, new tools can only succeed if you can convince people that the
      > collected wisdom in books like Code Complete really does apply to perl
      > too and they should turn down the insane-o-meter a little in exchange
      > for some help from new programming tools.

      I'm one of those people who believes in both coder-defined imported
      mixins -and- Code Complete. And, frankly, I don't see the disconnect
      between them. Code Complete says that you should be able to predict
      what will happen, it should be testable, and your comments should be
      good. (A bit of a simplification, but you get the idea.) Good Perl
      code can be all of those things and be very dynamic. Take
      Class::LazyLoad, for instance. That exists _solely_ to override and
      mess with the importing package's head. Yet, I don't think Steve
      McConnell would find that out of place.

      All this talk of automatically refactoring and auto-generation of
      tests ... makes me think the code is just too complicated. Why aren't
      the common bits abstracted out? You recommend Catalyst, but not CDBI?
      Catalyst is CDBI taken to another level - instead of autogenerating
      methods, it autogenerates an entire class hierarchy!

      Rob
    • Show all 107 messages in this topic