Languages such as Python, Ruby, or JavaScript can take as little as one third as much code as C in order to implement similar functionality. C gave us similar a

Languages such as Python, Ruby, or JavaScript can take as little as one third as much code as C in order to implement similar functionality. C gave us similar advantages over writing in assembler. Looking forward to the future, it is unlikely that language design will give us the same kinds of improvements we have seen over the last few decades. That seems a bold assertion. I can think of many, many ways that today's mainstream languages could become incrementally more expressive, safer, or otherwise better. Quite a few of those ways have been implemented, just in less mainstream languages. The language trap is that to become successful you need not just the language but the surrounding ecosystem. It's not that there aren't still very significant gains available over the current popular choices. Our obsession with flexibility, composability, and cleverness is causing us a lot of pain and pushing companies away from the platforms and tools that we love. I don't think real flexibility and composability are the problem. In fact, throw in longevity and you've got a decent foundation there for building good software. I think the problem is that a lot of what's going on in certain parts of the software industry today, particularly almost anything connected with web or mobile apps, is only offering an illusion of those benefits. A big, monolithic framework isn't really more composable than a carefully selected set of libraries, it's less composable. A tool that requires hundreds of lines of configuration to build a relatively simple application isn't really more flexible than a few lines of shell script, it's less flexible. A million tiny dependencies because you couldn't be bothered to write a few five-line functions yourself aren't really giving you more longevity, they're less likely to make things reliable in the future. I would argue that cleverness, in this context, is mostly about having good judgement. Are the costs of starting from a big, monolithic framework or relying on an extra tool going to outweigh or be outweighed by the costs of any lock-in and long-term dependency? Are the benefits of composing very many small components going to outweigh or be outweighed by the costs of keeping track of all the relationships?