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

328Re: [extremeperl] Better Development Tools for Perl

Expand Messages
  • Adam Turoff
    Jun 9, 2005
      On 6/9/05, chromatic <chromatic@...> wrote:
      > On Wed, 2005-06-08 at 23:18 -0500, Ed Grimm wrote:
      > > Also, more to Rob's point, I find IDEs to be less than useful; when
      > > one follows coding principles that limit the number of global
      > > variables severely, and local variables must be scoped entirely within
      > > one screen, etc, the benefits of an IDE are greatly reduced.
      >
      > Ah, but if you encapsulate things in objects and modules, being able to
      > ask "what are all of the available methods on this object" (as you can
      > do in Python and Ruby interactive environments, for example) is really
      > handy. I would like something like that available for Perl sometimes;
      > reflection is useful.

      I saw a blog post recently that attempted to highlight the 'richness'
      of Smalltalk. Comparing the number of methods on common classes like
      (Array and String), C# had something like 19, Java had 14, and
      Smalltalk had 367. Factoring out the methods that come from Object,
      the numbers were more like 12, 7 and 117. That number was supposed
      to impress you if visit the Church of Smalltalk regularly...

      Sometimes reflection is useful. Other times, it's like a nicely
      scented antiseptic to bathe your gangrenous leg. The problem isn't
      finding a nicer smelling antiseptic, but rather avoiding gangrene in
      the first place. ;-)

      I get the point that Rob was trying to make about any task requiring
      looking at 7 +/- 2 lines of code, and keeping ~50 lines of context
      available at any point. If you can code in that style, then IDEs, big
      classes, forests of methods and the like just get in your way. Method
      auto-completion isn't a productivity boost as much as it's a coping
      strategy.

      A system where each component is comprehensible with 7 +/- 2 lines of
      code exhibits a kind of fractal complexity. It takes a long time to
      learn how to build systems like that, and the first step is accepting
      that this is your ultimate goal. Not everyone can do it. And if you
      don't know that your goal is going to be fractally complex, at least
      an IDE can help keep the complexity of your language or libraries out
      of your problem domain.


      Larry's most lasting achievement isn't patch, rn or even perl, but
      teaching us that the complexity of the problem should match the
      complexity of the solution. (And if that idea isn't his, well, at
      least he convinced a few of us along the way.)

      -- Adam
    • Show all 107 messages in this topic