> And here’s why I don’t think the Sapir-Whorf hypothesis fully applies to programming languages. When we program we categorize the world in English (or Spanish

> And here’s why I don’t think the Sapir-Whorf hypothesis fully applies to programming languages. When we program we categorize the world in English (or Spanish, or any other natural language), and then we encode that into a program. I certainly don't "categorize the world in English" before "encoding that into a program". I've also met dozens of programmers over the years who found it easier to "show code" than to explain in English (or Spanish or any other "natural" language). I would be shocked to discover this is an isolated phenomenon. In Iverson's book "A Programming Language" (1962) says in §1.1: Ordinary English lacks both precision and conciseness. The widely used Goldstine-Von Neumann (1947) flowcharting provides the conciseness necessary to an over-all view of the process. only at the cost of suppressing essential detail. The so-called pseudo-English used as a basis for certain automatic programming systems suffers from the same defect. Moreover, the potential mnemonic advantage in substituting familiar English words and phrases for less familiar but more compact mathematical symbols fails to materialize because of the obvious but unwonted precision required in their use. So I'm not sure Iverson would agree either. Maybe just start with something simple like: Why is it important to classify programming as "not a language"? I had a hard time understanding what the author might think the answer to this question is. The only thing that jumps out at me is this: > … after seeing what happened with Scala and SBT, where sometimes the project build description ends up written directly in Scala, I’m not sure having one language that encompasses all is something I’d want … > Is it worth to expose users to an alien configuration format, just so the developers of the project can program in just one language? If you seek a purely utilitarian answer; an answer to what makes the software best perform the intended function, then yes it is worth it: There will not be bugs in the code you do not write. However getting people to use your software (i.e. "Sales") means making the software accessible to other peoples expectations and that's a social exercise. This is a business decision with simple economic drivers, and not a technical one. Some languages are simply better at sales than others; English is the most widely-spoken language in the world, but that doesn't mean English poetry is superior to Chinese poetry.