We know the answer to that. The result you quote (7500 MT) is MBP. Light fan, audible but not too bad. Power consumed probably around 15W, but we'll have to wait for serious measurement.

For MBA (no fan. passive cooling) same ST number, MT number is 6300. So fall off, but not that bad, large cores at maybe 80% of peak. Device gets slightly warm, not hot, under this use case. Device power maybe 8..9 W I would guess?

I think this sort of thing expresses the wrong attitude. It's like saying "I can do anything in assembly, so I have no interest in your fancy 'compilers' and 'scripting languages' and 'programmer methodologies'".

The issue is NOT Excel vs Numbers, just like software engineering is not a fight about whether Java is better than Ruby. The issue IS how can we use what we do know about making professional programming safer and more productive (limited though it may be) to make amateur programming in Excel safer and more productive.

And yeah, some of that WILL involve modifying the current wild and crazy world where anything goes for a world of more discipline. But you are not helping anyone if you are the guy screaming "keep your stupid for loops and your structured basic blocks --- I want the power to use goto whenever I want for whatever reason I want".

It sounds to me like the problems here are very much like the problems with SW development in the early 1990s. There is a social problem: lack of an engineering professionalism and lack of interest by management in fostering such professionalism AND There is a technical problem: lack of the equivalent of a source code control system.

One way to at least start to approach the problem would be to put the equivalent of a SCCS into Excel. You'd be expected to checkin and checkout spreadsheets, changes would be tracked, you could diff against older versions, etc.

The analogy is not perfect, not least because many spreadsheets consist of a logic part, written by one person, and a data part, filled in by another. Even so, forcing a checkin/checkout model would provide an audit trail and, as has been said, storage is cheap.

Perhaps the second easy modification that could be made would be to make it vastly more visually obvious which cells are locked, and which cells are logic. It should be possible to look at a spreadsheet and just see the logic portion separate from the data portion. Imposing this by visualization would at least make it less likely that spreadsheets get checked into the SCCS without appropriate locking.

I could add more, but in all cases it seems to me the idea is: look at the problems we programmers had in the 90s, and how we solved them, and do likewise. I've suggested SCCS and syntax coloring, but one could go to talk about, for example, code commenting, or making it natural for people to name cells (make that the thing that's easy to do, and make the cell names easily visible) so that faffing around with B$3 becomes a weird thing that normal people would not bother with --- just like in coding I don't tell the compiler to use register EAX, I just use a variable name.