use Perl

• only inasmuch as There's Only One Way To Do It (Score:1)

  by rcaputo (9040)

  "Inside every large program, there is a small program trying to get out." --Tony Hoare

  Abstractions incur overhead, yep. Fortunately, POE's higher-level abstractions (wheels, components) are entirely optional. The low-level abstract event loop primitives are still there: select_read(), alarm(), sig(), etc. There's a smaller POE inside. It's already out, but it's been a bit neglected.

  History has a bigger role to play than abstractions in the obstruction of change. A long-established, stable module like P
  • Re: (Score:1)

    by scrottie (4167)

    The context I was talking about POE in was this: a program written to use it versus one written to do something else looks very different. This means that it's hard to switch styles. A lot of changes have to happen to a lot of the program.

    Everything goes out of fashion eventually.

    That was part of the point of evaluating how entrenched any abstraction will make you. Being entrenched by an abstraction is a mark against it.

    Too much and leaky abstraction is another matter and I whipped on other things there
• I recommend you take a look at ORLite (Score:2)

  by Alias (5735)

  I created ORLite to address precisely the problem you are talking about.

  ORLite tries to use as little abstraction as possible, and in particular there is no abstraction of where clauses.

  my @objects = ORLite::TableName->select( 'END_SQL', 'Bob' );
  where name in (
          select name from people where husband in (
                  select name from people where name like ?
          )
  )
  END_SQL
• Thanks (Score:2)

  by jdavidb (1361)

  Thank you for the insights, and thank you for turning me on to Plack.

  --
  J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
• It takes time to realize what is the real core (Score:1)

  by zby (4817)

  Someone once wrote "I wrote you a long letter because I did not have time to write a short one" and it sounds like a paradox - but communicating clearly usually means communicating shortly and it takes time to work out what really is your core message. This is the same case with programming libraries - it takes time to realize what are the highly cohesive components and what parts can be decoupled into independent modules. It is a bit unfortunate how the big libraries have advantage in gaining popularity