What if your meaning is "run faster than a competitor"?

Well, if you enjoy that then have fun with it. But I don't think you should bemoan the fact that most of us find other things more interesting.

What are these other things? This idea that other stuff is more interesting comes up on xkcd often enough.

I have a hard time finding programs that don't push the computer interesting - media programs and so on interest me more than anything else. There's the top 1% of programs that people actually use and then there's a huge wasteland of stuff nobody uses. This top 1% usually have a lot of attention paid to their performance.

I can think of websites that don't really demand computer power that are interesting but only as businesses - not as programs themselves. And they have performance requirements in the background.

>What are these other things?

The realm of interesting things that are not squeezing as much performance as possible out of your code is enormous.

There's UX to be improved, there's robots to be built, and there's an almost limitless trove of science that could be applied to everyday life, or to business, or to art. There's improving human input methods. There are whole new genres of games to be invented. There's research into algorithms, where the objective is measured in big-O, not milliseconds, because we won't have hardware to make them practical for another six years.

Sometimes, you need micro-optimized code to do theses things well. Often you don't.

Don't get me wrong: I love digging into a hot spot and optimizing the hell out of it. But I'm going to have to agree with lmm that it's a good thing that we have the option of whether or not to think about it.

And if a super smart compiler were released tomorrow that could take any program you threw at it and give you the absolute optimal implementation, the part of me that would be sad for the loss of that intellectual pursuit would be much smaller than the part of me that would be crazy excited. Of course, there would still be lossy optimization to explore, but even if it could magically solve that, I'd still never run out of interesting problems to play with.

Oh don't get me wrong. I'm not saying it's a bad thing that there's programs you can write where you don't need to care about performance. I am saying that they aren't really that interesting to me.

All of the things you suggest seem to me to have important performance requirements, maybe not as hard as micro-optimized, but still they are there.

The few examples I can think of where the performance of code of popular products is not up to scratch - it's from users complaining - and a better performing product would have a competitive advantage.

I don't think that people who go after delivering the better performing software should be derided as being dullards pursuing something less interesting.

>All of the things you suggest seem to me to have important performance requirements, maybe not as hard as micro-optimized, but still they are there.

Sure, but in most of them, those performance requirements can be met simply by following a reasonably idiomatic style in any of a number of popular high level languages.

But I don't see anyone deriding people who find performance tuning interesting as dullards. You find that more interesting than other problems, while many people find the other problems more interesting.

We currently have plenty of use for both kinds of interest, and will for the foreseeable future. Compilers that completely magick away the need for optimization are a long way off, and there are plenty of applications where performance is paramount. But there are plenty of other applications where the performance you get from using high level tools is good enough, and choices like "float" or "double" are pretty trivial.

And high level tools are allowing more and more for you to make different choices when it really is important. In JS, for example, you have things like asm.js, and if you need the efficiency of single precision floats, you have Float32Array. Soon, we'll even have abstractions for vector instructions in the browser. And of course, if you really need extra horsepower for something on the server side, you can always pipe in and out of a carefully tuned native program.

But even if your end goal is efficiency, it actually makes sense for a language to use a less efficient default so that you don't have to think about things like precision requirements. The time you save on the 95% of that code that takes up 10% of your resources is time you can spend optimizing the 5% of the code that takes up the other 90%.

I think we agree if a reasonably idiomatic style gives the necessary performance then it should be pursued, not dismissed. I agree with what you write, what I disagree with is this above:

> It sucks that most people don't really care about performance any more. It sucks when people causally dismiss people who do care about performance with arguments like "premature optimization" and so on.

"Why? Really. To my mind it's good" etc etc

I also disagree with the "most of us" and "more interesting" angle, also exhibited here: https://xkcd.com/409/

I think a dismissive attitude to performance is a poor attitude, I'm not saying that high level tools should not be used.

I don't know if most people find it more interesting or not. I do think there's value in both interests.

I also don't think that arguments against premature optimization are a dismissive attitude toward performance. Avoiding premature optimization is about picking your battles. In an ideal world, you could optimize everything.

But optimized code takes longer to write, and longer to maintain, and in this subideal world, we have limited time to spend on code. The point of avoiding premature optimization isn't to excuse low performance code. It's to give you time to optimize the code that makes the biggest difference.

My first job was a system for building interactive SMS services, balancing power and expressiveness with user-friendliness, much like designing a programming language. But since the mobile phone system itself adds so much latency, performance was rarely an issue.

My third job was an insurance trading platform. Most of the interesting stuff was around the representation of contracts, making it possible to manipulate them by computer, and compare different possibilities, but still having them look like the paper contracts users were used to.

My second job was at a music streaming service, and was mostly about doing simple things in ways that performed well, or scaled up to millions of users. I found this a lot less interesting or creative than my first or third job. Of course, that could just be personal taste.

OK so I think I'm not alone in saying most people would find your second job more interesting than the first or third. Certainly Joe public would. I guess I'm more interested in the end result than the journey to get there.

My second job was a much cooler answer to "what do you do" at parties, sure. But in terms of what I was actually doing day to day, not so much.