>The touch bar is hardly revolutionary.

Well...

>there have been plenty of (barely working) implementations before.

...but that's the key point, isn't it? That the existing implementations don't really work. Just like there were plenty of "non-lame" MP3 players and plenty of smart phones and plenty of tablets...that all didn't really do the job.

Making something work great that already kinda exists, that people have tried and failed to really make great, isn't that exactly Apple's MO?

I certainly have an immediate application for the TouchBar for interactions that (a) have the potential to be really valuable but (b) have so far been too fiddly to do well. And that was only the immediately obvious one, my guess there are a lot more.

So while I had the same immediate reaction (yawn, gimmicky, ...), I have revised that opinion. I think it has the potential of being more useful than a full touch screen would be, in a laptop setting, and that's despite the fact that I think a touch screen might be useful in addition, for example swipe for "casual" scrolling.

In terms of hardware being not that amazingly more powerful (a point made elsewhere). Yes. That's what the end of Moore's Law looks like. What faster Intel CPUs was Apple to have used? Kaby Lake? Apparently not available yet in the configurations/quantities required, and also not really all that much faster And yes, the geek in me is always m/sad about the 13" not having a nice high-perf GPU to play with, but the actual user in me has never really needed it.

Instead of seeking to be saved by faster hardware, we now have a lot more to gain from optimising the software side, and we're currently leaving that on the table. Hmm..."leaving on the table" is not really strong enough, more like pushing away with maximum force.

As a small example the Swift compiler is tremendously slower than the clang based Objective-C/C compiler is. And that in turn is a lot slower than it should be, with a big part being LLVM (see Jonathan Blow's video on Jai compiler performance[1]).

His goal is to compile a medium sized program in well under a second, and a larger one in a couple of seconds. Sound ridiculous? Really the only thing that's ridiculous is that we don't have that level of performance generally available, our machines are fast enough for it. For example, I tried tcc[2], and it compiled a (synthetic) 300KLOC C program in 0.269 seconds. Swift took 96.6 seconds, for a factor 359 difference. And that was purposely avoiding the various constructs that make the Swift compiler run into the weeds.

In my upcoming book [3] I talk about various simple examples that get order(s) of magnitude difference from a bit of tuning love. One example went from 20 minutes using the "standard" accepted techniques to slightly under 1 second...all without any heroic optimisations, just straightforward tuning.

So coming back to the MacBook Pros: yes, they're probably not going to get appreciably faster, that's the new reality. But maybe they don't really need to get appreciably faster, we just have to get off our collective derrieres.

[1] https://www.youtube.com/watch?v=rJ7-j1nK9gk

[2] http://bellard.org/tcc/

[3] http://www.pearsoned.co.nz/9780321842848