|laziness, impatience, and hubris|
Is performance important in today's programming or is it no longer or rarely important any more? My answer is yes, performance is important, and it is always one of the most important measurement of the quality of your application. But its face is a little bit different now, and people no longer spend days just try to reduce the number of multipler in some math formular, as they do in the past. If one says that performance is not important, he is probably saying that he already gets enough performance, otherwise he is wrong.
The real question is not about whether you need performance, but how fast is fast enough, or whether the slowness is acceptable.
For example, I recently wrote a piece of Perl script to resolve Sudoku Puzzle. It took the first version more than half minute to resolve one puzzle. I didn't like that and thought that was too slow, so I tried to find different ways to improve it, and it ended up only took 1 second to resolve a puzzle. At that point, I knew there are still tweaks there that I can apply, but I said to myself, NO I am not going to change the script any more, as 1 second is fast enough, 0.5 second is faster, but 1 second is good enough.
Another example, in the company I work for, we have a piece of code that builds truck load, which must complete in 30 minutes. That is required by the business process, if the program doesn't complete within 30 minutes, starting from the 31st minute, we will have to pay truck drivers and other labours money even though they are doing nothing other than waiting for the computer to finish its job - so we are losing money. The program was in c, recently a guy changed it to Java, and it became slower and slow enough to pass the 30 minutes deadline. The whole team was threw in a big trouble.
So performance is important. If you are not under pressure to improve performance, it is not because that you don't need it to be fast, but because that it is fast enough. (Of course, it could also be that you are not good enough, you don't have enoguh time, or you are lazy enough.)
Now comes the second part: abstraction was never meant for performance. Abstraction was meant to make programmer's life easier. If you do the abstraction right, most likely you got more reusable code. (Side note: reusable code is not always reused. Other than some core components, the rest are never really reused, and people probably even don't know their existance. Donesn't matter what language we are talking about.)
The evil side of abstraction is the performance hit that usually comes as a twin. The good things are never good in all sense. At the beginning, abstraction is more important than performance, and OO programming opened up a new world where abstraction was made possible and much easier. Years passed, and lessons are learnt, and now people started to realize that they are forced to seek a balance point between performance and abstraction. As the most commercially successful OO language, Java world had the longest history that allows its citizens to learn the most valuable lessons in this area, and changes are being seen is the lastest Java versions and chatting in that world.
Perl is a comparatively new comer to the OO world, so not enough experience (positive and negative) has been accumulated, and lessons learned in other languages take time to spread to Perl world, and even not always welcomed. Perl is still continue its journey into deep (deeper)abstraction...
Now comes HOP. It is too early to comment on HOP in general, but one warning sign I can see is that: Higher Level could mean lots of things, but one of them is more abstraction. Slow is not slow, until you realize the slowness. Higher level of abstraction might soon tell us the other side of the story (than just the bright side it is supposed to tell).
Take Stream.pm as one example, its slowness should ring the bell.
A program can be fast enough that you no longer want to pursuit more speed. In the same sense, one day, people will realize that enough abstraction has been gained, and further abstraction is not practically needed.
It is a curve, at the beginning, the usefulness of the code is growing with its level of abstraction, but once it passes a point, the highly abstracted code is no longer useful, and you always need to write you specific code to patch them, and start to doubt whether you should move away.