Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • You make a good argument, but decreasing the cost of using something increases the quantity demanded: it doesn't affect demand itself. In terms of the pictures economists draw, moving the supply curve doesn't move the demand curve, but it does move the point both curves intersect (quantity demanded). For example, I tried to hook WWW::Selenium into Test::Harness a while ago but gave up as it looked like it would hurt too much. I suspect I could do what I wanted more easily with TAP::Parser. However, incr
    • I think we're in agreement, but my wording was a imprecise. "Demand" here can mean two things. The total "demand curve" over all possible prices and the "current demand" which is the quantity demanded at the current price. Its also interesting to note that a free software release doesn't really have a supply curve... not that I can figure anyway.

      Price doesn't immediately affect the demand curve. It does effect the current demand. And yes, I agree that increasing the current demand can eventually alter
  • Excellent post!
  • TAPx::Parser is now TAP::Parser and may be found here: []
  • Do I not write Test::Builder?

    Well, actually....

  • "Why should I put wheelchair ramps to X, handicapped people never come in here!"
  • I would add that Open Source is not about Adam Smith economics and group demand. I think it is about scratching an itch and it might happen that others might find it useful.

    Some see a need for using TAP::Parser in Test::Harness and bought maintainers seem to be in agreement, if others don't like it there is always the source and a fork.
    • I would argue that toolchain development is not about scratch and itch either.

      It's about brick walls.

      Tools are there to make "real" work more productive.

      So when it comes to improving or extending tools, the question is one of whether or not it's going to be more expensive in mental effort and human time to extend the current tools, or to just do the job directly.

      If tools are easy to extend, people will extend the tools, because that is going to be quicker compared to just doing the job directly. If they sta
      • Ha! I have been converting some of our Config::General files to YAML::Tiny this week. Part of the re-tooling effort for the project I am on. : )
  • I should note that as opposed to what Schwern thought that I said in the post, I did not make this fallacy, nor that was my intention. I told Schwern I was unhappy from him posting this here, and that he has done me a dis-service by that. See my response [].

    And for the record, my name was the first thing I noticed in this post, possibly due to the horizontal rule and the space and the quote afterwards.