4 ms·
This conversation almost always strikes me as a pointless exercise. We can't even agree on what it means to be "simple" or precisely define what it means to hav
by almostdeadguy 4y ago
This conversation almost always strikes me as a pointless exercise. We can't even agree on what it means to be "simple" or precisely define what it means to have "less features" in a programming language (or perhaps we can by saying complexity is anything more than what is provided by machine language, but we get no closer to an understanding of how much of this is necessary or when this is desirable). A programming language is an abstraction over machines and inevitably all languages introduce features to unburden the programmer from extraneous detail, toil, or precarity involved in orchestrating the operation of that machine. The author is correct that many "simple" languages like Brainfuck are actually very complex to use, but this strikes at the inherent feebleness of the premise that we can clearly define what we mean by a "simple" language (or at least any clarity on when the complexity tax is worthwhile or not worthwhile). Many programming language features are conditioned on a trade-off that having to think about X less in exchange for requiring knowledge of Y is a net benefit to the programmer. If we take the idea that simplicity means "less features" at face value, we throw out the notion of any high level language having the potential to be simple.
The oft-cited Rich Hickey talk [0] I think gets _somewhat_ closer to vindicating the concept of simplicity being something we can talk about more objectively, but I'm still not convinced the concept is worth redeeming. Instead I would propose that languages should have a clear purpose and context in mind. Designing a language with clarity about the intended scale and pace of change in software that will be built in the language, the domain/category of software it is well adapted to build (i.e. embedded, web, OS, compilers, mathematics, mobile, servers, games, and so forth), and the nature of the teams and the public community it intends to support supersedes and encompasses whatever we want to call "simplicity" or "ease". What is easy, simple, helpful, etc. is incidental to how purposefully built a language is to a set of use cases.
[0]: https://www.youtube.com/watch?v=LKtk3HCgTa8 https://www.youtube.com/watch?v=LKtk3HCgTa8