>Simple languages are easier to learn, easier to implement, and it's easier to understand code written in that language, since the semantics are simpler. But "

>Simple languages are easier to learn, easier to implement, and it's easier to understand code written in that language, since the semantics are simpler. But "simpler" language specifications can also be harder to use in the real world. I made a previous comment on how the simplicity causes extra complexity in real-world code bases: https://news.ycombinator.com/item?id=14561492 https://news.ycombinator.com/item?id=14561492 For example, a "simple" language I used did not have bitwise operators like C/C++ (|&^~). However, my problem still had irreducible complexity that required reading individual bits of a byte so I wrote a bit reader using math: function bitread && returns .T. or .F. value parameters cByte, nPos return ! (int( asc(substr(cByte, nPos/8+1, 1))/(2^(nPos%8)) )%2 == 0) By eschewing the so-called "extra complexity" of "&" bit operator in C/C++, we end up using mathematical combination of exponentiation, modulus with substring extraction. Yes, one can argue that not having bitwise operators means it's "simpler to learn the language because it's one less piece of syntax to grok" -- but now you've caused extra complexity in the codebase. This extra complexity multiplies in other ways: - Programmer John spelled his custom bit reader as "BitGet()" - Programmer Jane spelled her custom bit reader as "bit_fetch()" - in addition to different spellings in the wild not being interoperable, each may have subtle bugs. (Did the programmer implement the math correctly?!?) Therefore, adding a bitwise operator adds complexity to the base language spec but also simplifies real-world coding. A lot of so-called extra complexity (extra keyword concepts in C#, Swift, Rust, Javascript ES6) in newer modern languages let you write simpler programs because the base language encodes a common pattern that a lot of people were re-inventing. E.g. C Language doesn't have generics but that doesn't mean the need for expressing a concept of generics goes away in actual real-world C codebases. See comment by pcwalton: https://news.ycombinator.com/item?id=14561664 https://news.ycombinator.com/item?id=14561664