On Tuesday, December 16, 2003, at 05:36 PM, Chip Salzenberg wrote:
Speed is for users. PR is for non-users.
You want speed? OK, we can talk about the actual speed you actually need based on your actual usage patterns. But from a design perspective you're a collection of anecote, not a user base; so your usage patterns may be irrelevant to Perl in the big picture.
In a separate matter, non-users may perceive Perl {5,6} to be too slow for their needs; more to the point, they may *assume* that it is too slow without research and testing. That assumption is a public relations issue -- ironically, one which is fundamentally disconnected from the question of Perl's _actual_ efficiency.
Well, just for clarification; in my anecdotal case (server-side web applications), the speed I actually need is "as much as I can get", and "all the time". Every N cycles I save represents an increase in peak traffic capabilities per server, which is, from a marketing perspective, essential.
If a potential client company needs to decide between two server-based products -- my Perl based product, and a competing Java-based one -- one of the first questions they ask is "how much traffic can it handle for X dollars of hardware and software". I don't have to win that benchmark, but I have to be close. Otherwise I don't get to play.
I agree, it is frequently the case that the question of speed is made critical by people who most assuredly do not need it. But they still decide that way, and I have found that asserting to them that speed is not important has been... well, less than effective. I do not doubt that P6 will be much more competitive, speed-wise, than P5 -- but if it could actually _win_ a few benchmarks, it would turn my company's use of Perl from a PR problem to a PR advantage.
your usage patterns may be irrelevant to Perl in the big picture.
The thought has crossed my mind repeatedly, believe me.
MikeL
