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.
Legibility and domain modeling get mixed up with business models and incentives, so good-simple just isn’t the same thing to the people paying for simple and the ones fascinated by simple,
What mongo solved was user adoption and being legible to a specific type of person making a business decision with very high LTV (a web developer handling JSON and needing a scalable database for it they could dump it into). It’s aligned with the purchaser’s needs and incentives and honestly isn’t awful even if it does end up becoming enormously expensive later, because you might just really need a database your team understands and can use asap.
Mongo churns because what’s legible to a purchaser and what captures the essential qualities of some kind of application domain or abstraction are different things. Once immediate growth is covered and you can afford someone who knows a lot about databases to work on yours they’re like “what the hell” because it turns out that it didn’t do what you’d typically consider the bare minimum of a database: https://news.ycombinator.com/item?id=40901573
But what is consistency, and how nitpicky are you about it if your problems seem to be solved well enough that something’s no longer a problem? I like software because there is a certain mystique behind understanding things like “public key cryptography would be useful in any universe with numbers” or “you really couldn’t improve on TCP for what it does”, because these tie in to real world problems but are also universally applicable, so distilling them to their essential form reveals a kind of API of the universe. But you don’t need that to get value from software and computers, you just need to solve your problem, that being, you need a database now or you lose a sale. What’s “simple” or even what counts as a database isn’t legible between the two.
Tech has a lot of money wrapped up in it so there’s a lot of attempts at capturing mindshare and defining things because the payoff is enormous. It just doesn’t sound fun to me to build up a house of cards selling a database that isn’t actually a database and deciding to figure out that whole database thing later when churn, CAC, LTV, and market adoption metrics tell me to. But also, customers really did need to shove json into databases and weren’t too picky about the particulars. So fuck it, this is a database.
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.