Disclaimer: this essay of a comment is sort of an ad for my ideas. At the time this article came out, I had been designing a language for 2-3 years. I'm still

Disclaimer: this essay of a comment is sort of an ad for my ideas. At the time this article came out, I had been designing a language for 2-3 years. I'm still designing it now, so I have more than 10 years experience. The author is right and wrong. The W3C principle is right and wrong. Paul Graham is right and wrong. The author and W3C are right in that the less power you have, the better for understanding, analysis, and even optimization/performance. Paul Graham is right that you need power. I only realized this recently after working on a build system, which might be the most hated type of software. As I designed mine, I wanted to do it right, to avoid the mistakes. The biggest mistake, and one common to nearly every build system was not providing the user enough power. The common opinion about building software is that it shouldn't be that hard. Most of the time, that's correct. But when it is hard, there is nothing that will work except raw power. When you need it, truly need it, literally nothing else will do, by definition. This leads to a quandary because by the time a project runs into a situation where building is hard, the build system is deeply entrenched. This means that changing the build system would be difficult and time-consuming for little perceived benefit. Instead, users find ways around a build system's lack of power (usually by writing a script; after all, a script is powerful) and moan about how the build system is a problem. I agree with them: such hamstrung build systems are problems. But at the same time, an all-powerful build system would be complicated to use, right? Spoiler: no, but to do it right takes actual design and user experience work instead of just coding. But let's assume it is too complicated to use. What can we do? We need the power, but the power makes it too complicated. Should we just throw up our hands and accept that the complexity is inherent, or should we hamstring the build system and hope we don't need the power? Absolutely not. Would we do that with our programming languages? No, so removing the power is not an option. Most of the time. What if we could remove the power some of the time? Let's say it's a config option we put into the build file. Maybe that option can be one of several things: 1. Only targets and commands, like a pure POSIX make Makefile. 2. Like the above, but add conditionals, like `if` statements. 3. Like both of the above, but add constrained `for` loops. 4. Screw it, add `while` loops and make it Turing-complete. 5. Let's go Hole Hawg [1] and add metaprogramming! Some projects will never leave level 1. Some will never leave level 2. Most will never leave level 3. Most of the remaining few will never leave level 4. But for those that need it, level 5 still exists! And more importantly, so does level 4. This means that the projects that don't need power won't use it and can have all of the advantages of a less-powerful language. It also means that the other projects won't curse their build system. Everyone's happy! (As a sidenote: implementing this idea is easy; the build system just needs to not allow certain "keywords" in each setting. In fact, you could make it even more granular by allowing users to forbid individual keywords!) This is an extension of a comment I wrote recently. [2] I replied to someone who asked if Guy Steele was right when he said to restrict the grammar of your language. My answer: he was, unless you need power. The more powerful your language, the more likely that an LR(1) grammar is not sufficient for it, to the point that for the most powerful of languages, only an all-powerful Turing-complete parser can parse them. There is no substitute for power. But use as little as possible. So yes, we need less powerful languages. We also need more powerful ones. Perhaps what we really need is a language whose power you can tune to your needs. (Shameless plug: stay tuned!) [1]: Read the "Hole Hawg" section of "In the Beginning Was the Command-Line" by Neal Stephenson. https://web.archive.org/web/20180218045352/http://www.cryptonomicon.com/beginning.html https://web.archive.org/web/20180218045352/http://www.crypto... [2]: https://news.ycombinator.com/item?id=34416730 https://news.ycombinator.com/item?id=34416730