I'm working my way through Bob Nystrom's Crafting Interpreters (recommended — extremely approachable guide to creating your own programming language) and this part in chapter 12 just felt super relevant:

We language nerds have a tendency to fetishize minimalism. Personally, I think simplicity is only part of the equation. What we really want to give the user is power, which I define as:

power = breadth × ease ÷ complexity

None of these are precise numeric measures. I’m using math as analogy here, not actual quantification.

Breadth is the range of different things the language lets you express. C has a lot of breadth—it’s been used for everything from operating systems to user applications to games. Domain-specific languages like AppleScript and Matlab have less breadth.

Ease is how little effort it takes to make the language do what you want. “Usability” might be another term, though it carries more baggage than I want to bring in. “Higher-level” languages tend to have more ease than lower-level ones. Most languages have a “grain” to them where some things feel easier to express than others.

Complexity is how big the language is (and its runtime, core libraries, tools, ecosystem, etc.). People talk about how many pages are in a language’s spec, or how many keywords it has. It’s how much the user has to load into their wetware before they can be productive in the system. It is the antonym of simplicity.

Reducing complexity does increase power. The smaller the denominator, the larger the resulting value, so our intuition that simplicity is good is valid. However, when reducing complexity, we must take care not to sacrifice breadth or ease in the process, or the total power may go down. Java would be a strictly simpler language if it removed strings, but it probably wouldn’t handle text manipulation tasks well, nor would it be as easy to get things done.

The art, then is finding accidental complexity that can be omitted. Language features and interactions that don’t carry their weight by increasing the breadth or ease of using the language.

Really dig that final summarizing sentence

The final paragraph about removing accidental complexity from a programming language is good, but there is a whole lot of detail about how you do this that remains unsaid.

I don’t think it’s the authors intention to boil it down to one variable power. He’s just trying to explain some design choices he made in that chapter. I have taken this out of context just because I hoped it would make some of you interested in the other stuff he has to say around that tiny paragraph, but I can see how it’s a little misleading. The goal of the book is teaching people how to craft a programming language and not to create the best possible language. A lot of the choices he makes are to keep it simple and illustrate important concepts. I think he’s doing an excellent job throughout the book making people aware of all the big and small trade offs that go into the design of a language and I hope you don’t get the wrong impression from that tiny piece that I chose to present here. That said, I do agree with your comment, @Doug Moen, what I'm basically trying to say is don’t blame the author because there’s a lot of context missing and blame me instead. :-)

@Stefan Your quotation hit a nerve, because I used to believe in that power equation. My university thesis took the power equation as its starting point, and tried to show how to design the "one true programming language" (not in those exact words) that had maximum expressive power. I no longer believe in this idea, so it was kind of exciting to see what I now consider to be a fundamental fallacy of language design expressed so bluntly and directly, as a simple equation.

We need this guy in this slack! @Ivan Reese

Hi

Bob Nystrom I mean :P

Yeah, hah. I should have been more articulate, but I was on my phone, so I hoped the joke answer would suffice. Sorry! I'm no more equipped to invite people to this community than anyone else. If there's someone you'd like to see join, invite them! The best thing would be for someone here who already has a relationship with that person to extend an invitation, so if you're looking to make a "they should be here" call, then that's the call to make. In this regard, I'm just another bystander.