Donald B. Gillies Lecture: Dr. Michael Stonebraker

Yes, this is a development that has happened over time and has become pretty severe. Michael Stonebraker has written/talked about this in the context of DBMS research, but to me the same issues are applicable to other fields as well. Slides: [link] Talk: [this video] In short, the incentives/requirements in academia have changed so that producing working software is no longer feasible. He says he got his PhD with exactly 0 publications, became a professor with 5. Nowadays, you have to have 5 publications to get your PhD and god knows how many to become professor. That means 1 paper successfully published per year if you want to get your PhD in 5 years. Doing software is not possible, it is too risky and just takes too long. There's a lot more, I highly recommend the talk!

> academia’s ideal role is to simply advance human understanding in interesting ways Yes and no. This is an engineering science. In a pure science, the world is out there to explore and find out about, constraining what you do. An engineering science is very much about useful things we can build and how we can get better at doing that. Buildings that stay up and house people/things, planes that can fly, ships that float, that sort of thing. Without a world to find out about and without being constrained by stuff to build, things get a bit arbitrary. At that point, it's really more pure art than anything else. Math is sort of the exception where we allow that kind of freedom. Sabine Hossenfelder's Lost in Math is a reminder of the dangers of applying that approach to other disciplines. Anyway, I think it is actually wrong to pin academia's irrelevance to this fundamental divide. The problems in industry aren't too easy / boring to be of interest to academics. They are too hard to be solvable by anyone with the current insane level of publication requirements. Michael Stonebraker talked about this in detail: [this video] It's a great talk.

> compiler engineers have good reason Sure they have reasons. And for them , these reasons are "good". The problem is that what is good for the compiler engineers has ceased to align with what is good for most compiler users . The reasons for this are complex, but one huge one is that we all generally don't pay for compilers any longer, at least not directly. If you have paying customers, you don't pull stunts like that. Michael Stonebraker talked about a very similar phenomenon in database systems and research: [this video] The observation I found particularly interesting is that the few commercial companies that still interact with research, and I think the same goes for compiler/optimizer engineering, are the "whales", companies like Microsoft, Amazon, Google and Facebook. Their needs are very different from most everyone else who doesn't run datacenter where a 0.1% performance increase can mean millions of dollars of cost savings and therefore be worth quite a bit of pain. Particularly when it is pain for others. > C values performance over safety No. Well, yes, because it doesn't value safety much at all. Certainly not when I started, which was with K&R C, so no type-checking at all for function calls, for example. What C values is DWITYTD, "Do What I Tell You To Do". C makes it possible for programmers to write code that performs well, it doesn't try to make code perform well. That's a crucial difference.

Yep, that is exactly my analysis of the situation: an actual compiler vendor would never ( could never) pull any of these stunts, or they'd simply go out of business in a jiffy. Alas, we all got suckered into "free", and now the compiler writers no longer listen to their users, because they are not their customers. Their customers are they PhD advisers and Google, Apple and maybe a few more "whales" as Stonebraker described them, lamenting a similar situation in databases. Their needs are almost completely different from the rest of us! For Google, a 0.1% performance improvement in one of their key applications is worth quite a bit of extra pain for their own developers, and pretty much an infinite amount of pain for other developers. [this video]

The level of academic unhappiness with publishing and its surrounds is actually surprising to me. First, I never hear the counterargument.. that current publishing is OK. Does it exist, or is everyone unhappy while nothing changes? Second, I'm surprised at how much of a single institution academia seems to be. "Publish or Perish," for example, has to be supported by tenure committees, grant makers and such. Are they all the same? Michael Stonebraker^ suggests that tenure committees accept a limited number of papers on a resume. This is to encourage lower volume, higher quality publication. What stops some tenure committees from implementing such changes. I just don't understand what's locking everything into place. ^ [this video]

Working in research, I do see a clear business value that Elsevier&co are providing and why they continue to get their money. It's acting as an impartial rating/filtering service for the non-scientist administrators. In essence, the funding agencies want a way to evaluate scientists and institutions without asking their scientists and institutions to do so, probably because they don't trust them, and also because they have very strong incentives to avoid making any subjective judgment themselves but instead defer to some "objective" outside source - so they use paper counts published in "proper places" or the existence of papers published in "very good places" as the evaluation metric to circumvent the (genuinely very hard!) problem of evaluating the quality/quantity of the actual research done. And so this incentive, attached to much of the money flowing within academia, trickles down to evaluation of people when hiring and promoting (the committees also often look at paper counts and publication venue rankings instead of trying to evaluate the actual papers - which is time-consuming, and if the papers are not in "your field", then very hard to make an informed judgement) and so to the individual motivations of almost all the people in the system, who have to take into account the "proper publishing rituals" or severely limit their career. So having worked a bit with administration and evaluation of funding proposals I kind of see why something like that is valuable in gener

> I often fall into the thinking of top 10 or 20 appstore app terms You're not the only one. As far as I can tell, the vast majority of (particularly, but not exclusively) compiler work is driven by these edge cases. As an example, when I look a the justifications for pushing undefined behavior exploitation in C, invariably some Very Smart Compiler Guy™ will state with great authority that this is absolutely essential and completely unavoidable. When you check more closely, it turns out that it enables a somewhat obscure optimisation that at best most people can do without and at worst is just about completely useless. See Proebsting's Law, which was unduly optimistic, and also some of the work on variability in benchmarking, for example how different lengths of environment variables can dwarf most optimisation effects. Daniel Bernstein stated this a bit more aggressively as "The Death of Optimising Compilers"[1]. He's not wrong, either, but when I mentioned this at a Google event, Chandler Carruth basically blew up and said it was complete garbage. Apparently he and Daniel almost came to blows over this at some conference. At the time, Google was working on a far less optimising JS runtime for Chrome, after they found out that their super-simple runtime (mostly just interpreted) for small devices was beating their super-duper sophisticated Turbofan JIT on many real world tasks. And of course Microsoft found out that just turning off the JIT completely has marginal real-world