I want to raise a point that so far I have not seen in the top N comments: Often simplicity and cleverness are not opposites, because you can only find the simplest way to express something, when you are clever about it. Your solution doesn't have to "smell clever", no, it can be deceptively simple, making the casual reader think "of course it works this way", but when such casual reader was supposed to come up with such a solution, they might invent something unnecessarily convoluted, because their mind has not cut through all the stuff like a knife through butter and they were not so clever. To find the simplest abstraction, that is still able to represent everything you need to represent, and at the same time doesn't have unpleasant consequences like being very slow, or super difficult to understand is the actual cleverness. Writing code no one can understand is not actually that clever. It might be clever in terms of oneself solving a problem at a specific time, but it is not so clever in terms of that thing being maintainable, adaptable, readable, improvable, in the mid and long term.
We don't write everything in lambda calculus or SKI calculus or something like that, even though those things are made up of very simple parts, complexity would emerge. They are not the right choice for most tasks. How do you make it readable? Can you write something that is very clear and performant at the same time, while preventing yourself from programming yourself into a corner? That's where you need to get really clever.
Yeah, I don't know about other fields but the way "simple", "complex", "clever" are used in software is so backwards and inconsistent. These terms mean nothing in tech and we should excise them.
Much of what MacKinnon is referring to here would be seen as simple, complex, or clever by many people. He advocates for static languages but when he does so he talks about "useful" and "tradeoffs", which are radically better terms if you actually want to discuss these topics.
One case he talks about is an abstraction over Mongo, but then the queries were designed for mongo. Is that an issue of simple or complex? I have no idea, I'd say neither. The issue was that you abstracted away essential properties of your system.
TBH, despite the title, what he says is seemingly radically more about tradeoffs and actual concrete ways to write software - I didn't hear him talk that much about "simple" or "complex" and what he said were instead reasonable cases where things went right or wrong, or his more nuanced opinions on why certain techniques and technologies lead to better outcomes. Ultimately any productive conversation ends up that way, if you find yourself saying "simple" or "complex" a lot in a conversation then you're probably doing it wrong.