Re:Programming languages are not languages (2018)
by Tainnor on Wednesday April 15, 2020 @08:59AM
(#22877159)
I don't think Sapir-Whorf (in a weak form) is just a case of inverted causality. Sure, matters of perception shape the language we speak; this happens all the time. But the key point is that the reverse direction happens too. Language is a perfect medium to transport preconceived notions and because we don't think so much about it (indeed, we think lots of things are natural, when they're actually particular features of a single language) it's particularly subtle. Examples of this include gender/classifier systems, colour perception, evidentiality markers, or one of my favourites, spacial recognition: one famous experiment shows that members of a particular Australian aboriginal tribe (Guugu Yimitthir) think in terms of absolute cardinal direction even in everyday situations instead of left and right; in fact they don't even have words for left and right. Of course, the reason for this development is originally due to the landscape around them, but now the language which lacks such terms serves to reinforce this worldview.
My only qualm with Sapir-Whorf is that it only credits language with this cultural transmission. But there are a lot of other things that can do this (arts, rituals, customs), even if language is a big part of it.
Well that and that the original version ("the Hopi don't know the concept of time") is a bit ridiculous.
I don't think it applies to languages, period.
The Sapir-Whorf hypothesis seems to me like a classic case of inverted causality ("wet streets cause rain", as Michael Crichton put it). Sure, it's definitely possible that in a given instant one's language might constrain or otherwise influence one's cognition, but it's vastly more likely to be the other way around: if the language is unable to support a concept in one's cognitive process, an individual is prone to bend the language, whether by grabbing a loanword from some other language, recombining roots to create a new word, or what have you.
That's the fundamental issue with programming language design that I think the author's trying to articulate: they're designed, and more fatally, they're designed in such a way that they're rarely able to evolve as needs dictate. The many Eskimo words for snow didn't come down from on high and conjure those forms of snow (and their perception by humans) into existence; rather, I strongly suspect people encountered (and had to describe) these different kinds of snow often enough that they found it worthwhile to give them names rather than merely descriptions. Phrases turned to compound words turned to shared roots.
This is in contrast to most programming languages; yes, at some point they were obviously created to satisfy a certain need and give "words" to certain computing concepts, but very rarely are they able to fully evolve to address new computing paradigms (at least not without rigidly declaring a new version or new dialect of the language with new syntax or keywords, which just punts the issue a bit farther into the future). There are a handful that are better at this (Lisp, Forth, and Tcl - and their respective descendants - all come to mind), and they happen to lend themselves well to DSLs, but I feel like they stop just a little bit short of being able to entirely evolve on their own; programming languages need implementations and runtimes to be actually useful, and few (if any) languages provide the mechanisms to freely manipulate their own implementations/runtimes (there are certainly plenty of Lisps that can bootstrap themselves and other Lisps, but that's almost always an ahead-of-time operation with little to no exposure to the language user, nor any practical means for said user to leverage that within one's own code to tailor the language and the implementation thereof to the exact problem domain).