Sapir-Whorf hypothesis for programming

For those who don't know, the Sapir-Whorf hypothesis is a principle suggesting that the structure of a language affects its speakers' worldview or cognition, and thus people's perceptions are relative to their spoken language. It's not uncommon to hear similar things but applied to programming: specially when talking about Lisp. Does the language used by the programmer affect the way they approach problems in a way that could be described as better? Can we shape the approach to programs limiting certain features from our language? How could we use this for our benefit? What are some languages and/or dialects that could fit into this description?

It very obviously does. APL is distinct from Brainfuck. I question whether this warrants a thread or not. https://cpsc.yale.edu/epigrams-programming >19. A language that doesn’t affect the way you think about programming, is not worth knowing. >Does the language used by the programmer affect the way they approach problems in a way that could be described as better? Yes. >Can we shape the approach to programs limiting certain features from our language? Yes. >How could we use this for our benefit? A system with no notion of time avoids internal timing attacks, for example. >What are some languages and/or dialects that could fit into this description? The only ALGOL-like I know is Ada; everything else is very different; I've programmed in machine code, APL, Common Lisp, and others.

Maybe you're thinking of something else, but what I typically hear claimed about Lisp is that learning it will make you a better programmer in any language, and therefore it doesn't come under linguistic relativity - it is simply a case of learning certain abstraction techniques that some other language families don't expose so clearly. This is a nitpick on your chosen example, not a counterargument. As for you actual question, I concur that the language does indeed affect the way the programmer approaches a problem, although not all the ways in which it does so are a case of linguistic relativity. Sometimes it is a conscious choice, an active search for a way to combine the tools that you have in order to solve your problem. I must admit, however, that when I program in different paradigms I often come up with different ideas to begin with. Your remaining questions are the real meat of the thread and I shall give them further thought.

I think an object-oriented programmer will come up with a solution to a problem that's structurally different from that of a functional programmer. Is that a case of linguistic relativity, though? It seems to be a consequence of the tools you use. A functional programmer thinks more like a mathematician, while the oop one thinks in terms of lego blocks. Likewise, a geometer will come up with a different approach to a problem than an analyst would, and both would be different from that of a physicist.

I think the data structure that is used is the major "feature" that controls how you think. the morris worm had a list structure because morris was trained in lisp and didn't know enough about datastructures to even think of a different one.

Pretty sure it's the opposite. Language is influenced by the people who made it.

>>30980 Why that should exclude the language for influencing people? I think both propositions are equally valid.

>>30980 While this is true, the language will also influence the people who learns it. Everyone who learns a language(not a programming language) that is completely different from his own(learning an eastern and a western language, for example), knows how one is forced to think different in both languages. I do believe it's also true that learning programming languages with different paradigms forces one to solve problems different. Jumping from Java to C# will not change anything at all, same from C to any of C-clones. Sure, you can solve a problem faster by skipping steps that would require you to do in C, but you are just skipping steps, not finding a different way of solving a problem.

>>30987 Some things just cant't be done in a certain language. C doesn't have proper coroutines for example, which would be the first logical step in thinking in terms of pipelining data, as is usual in functional languages (sources, sinks, filters), thus requiring finnicky workarounds. This kind of contradicts the language itself, since such a design is efficiently implementable at the assembly level, and as such not really an "ambiguous feature".

>>31099 >C doesn't have proper coroutines for example, which would be the first logical step in thinking in terms of pipelining data Could just use threads and pipes (or blocking ring buffers).

>>31127 That's the thing. We're talking about the language itself, not the library functions.

>>31099 >C doesn't have proper coroutines for example, which would be the first logical step in thinking in terms of pipelining data Not really, threads and thread-safe FIFOs are what come the mind of most CS graduates. >as is usual in functional languages (sources, sinks, filters), thus requiring finnicky workarounds. C isn't functional and that's "okay". >This kind of contradicts the language itself, since such a design is efficiently implementable at the assembly level, and as such not really an "ambiguous feature". Huh? If you want coroutines or green threads, you're basically looking at longjmp or ucontext stuff, nothing that can be considered efficient or simple, really. Let me be honest: coroutines are overrated as fuarrrk because there are only some rare uses for them. And they're one of the biggest and most opaque abstractions. >>31830 And you don't give a reason why it needs to be put in the language. C ring buffers have the inconvenient of being slow OR macro hell because C doesn't have generics, but otherwise, no problem; that's what I use at work in C++: generic ring buffers with blocking via condition variables and good old threads.

>>31832 Not that lain but >And you don't give a reason why it needs to be put in the language. I don't think they're arguing that it needs to be in the language, why would you say this? This thread is about languages and the "symbols" that the language provides to think about problems. It is true that you can implement anything in C, but the C Programming Language does not include symbols that allow you to think in terms of functional language pipelines. In the same way, a language like python does not give you the symbols to think about tabular data manipulation, although you certainly can process spreadsheets with it.

>>31856 They are disagreeing that co-routines are a meaningful or useful symbol. In situations where the idea of a co routine would be useful, what I do instead is have what would be 2 functions in one function, and use labels and goto to jump between the different components of the function. I cannot think of a situation where the components of the function are so disconnected that you would want them to be separate functions, yet at the same time yield between them as a coroutine does.

I crave research about this. It seems like it should be possible to invent simple languages with slightly varying features, then assign a bunch of programmers to the same task with each language, and actually measure how intuitive/pleasant/readable/performant etc. the results are. Maybe it's out there but I haven't found it yet? I think there's a field of programming language design that is still in the infant stage.

>>34718 The Sapir-Whorf hypothesis is generally considered to be bullshit and holds about as much weight as Myers and Briggs personality tests. Popular enough in the main populations mindset that they believe it is a tested and true thing and hated by the academics who know it is bs and have to deal with idiots who don't know any better.

>>34721 >The Sapir-Whorf hypothesis is generally considered to be bullshit Care to share some links/whitepapers? Intuitively, Sapir-Whorf hypothesis sounds very real. For example, in Japanese language there isn't future tense. I would expect that learning the difference between present tense and future tense is probably hard when compared to learning Swedish as your 2nd language if you are native English speaker. In programming, I would expect the languages you know to affect the way you solve problems (compare a person who knows Java and someone who knows Standard ML). Another example would be Toki pona. It's a language that "challenges" you to get by with only basic grammar and small vocabulary.

>>34722 I recommend Steven Pinker's book, The Stuff of Thought [0], and George Steiner's book, After Babel [1]. Also I hate to link Quora, but the answer is from my former professor so regurgitating everything he said seems silly when I can link to his answer instead [2]. Honestly just go read his answer. Sapir-Whorf is a great, if entirely unfounded, justification for why certain words or phrases should be derezzed. It's how you get the cooky soykaf like "blacklist" is a racist term and should be changed to "blocklist" because "blacklist" subconsciously biases people to be racist because it infers "blacks should be excluded". As a somewhat related aside to this. The worst thing about many "pro-science" people is that they'll use science to back their decisions and then completely ignore that science is a process and when the science no longer supports their decisions - they'll willfully ignore the actual science. This tactic of keeping "the science controversial" allows them to continue peddling their bullshit. It's how the tobacco industry avoided litigation for so long. They would back studies to muddy the waters of what "the science says" and then when asked if tobacco was harmful to health they could fall back on "Oh - the science is still out on that! But our studies say it isn't!" Anytime you find a study that is for/against something - always look at who is backing it and what the social climate of the time is. "Gay is a choice" study from the 1930's? Can disregard it. "Everyone is at least a little gay" study from 2021? Can equally disregard it. Nobody in academia is going to commit career suicide going too much against the social norms of the time. At best you'll find "inconclusive" studies that if you actually read are... quite conclusive but they if they "conclude" what the study says they should they'd lose their career. [0] https://www.amazon.com/Stuff-Thought-Language-Window-Nature/dp/0143114247 [1] https://www.amazon.com/After-Babel-Aspects-Language-Translation/dp/0192880934 [2] https://qr.ae/prsoU4

>>34723 >when the science no longer supports their decisions also often just used in decision laundry. Official follows what the pocket expert says, pocket expert says what the official wants to hear. If the way winds are blowing changes later, the expert just offered a non binding reccomendation, he's not at fault, and the official just did the reasonable thing of trusting an expert, so he's not at fault.

>>34723 Apologies for double posting - but I also wanted to provide actual papers - they're a bit difficult to find because of all the pro-hypothesis bullshit in mainstream media nowadays and Cultural Marxist backed studies that want it to be true to justify their desire to change common vernacular. The [3]rd is most supportive of the weak variant of the hypothesis but their summation gives away their biases but even then they admit that the evidence is incredibly weak and that the only reason it continues to get studied is to try and argue against "Nature vs Nurture". Remember: modern political climate. "Nature" is bad and enables arguments that are politically untenable, "Nurture" is good. The current arguments over "Nature vs Nurture" is why there are so many pit bull apologists nowadays despite the breed making up something like 70% of all fatal dog attacks. It's politically untenable to try and argue that "nature" plays any part in why the dog-breed-bred-for-killing is naturally inclined to kill and that it is 100% "nurture" and because the breed is somehow always "raised by bad owners". [0] https://www.researchgate.net/publication/339124567_The_Rise_and_Fall_of_Sapir-Whorf_Hypothesis [1] https://sites.socsci.uci.edu/~lpearl/courses/readings/WolffHolmes2010_LinguisticRelativity.pdf [2] https://link.springer.com/referenceworkentry/10.1007/978-3-319-16999-6_633-1 (Steven Pinker, author of the book I recommended earlier) [3] https://docslib.org/doc/8007207/linguistic-relativity-from-whorf-to-now

>>34713 > I cannot think of a situation where the components of the function are so disconnected that you would want them to be separate functions, yet at the same time yield between them as a coroutine does. That's because specific case you cited doesn't even need a coroutine. The alternative solution you proposed suggests that you are (thinking of) using coroutines in wrong situations.

>>30959 I think an object-oriented programmer will not solve the problem, rather they will solve problems about the problem.

>>34722 >For example, in Japanese language there isn't future tense. English technically doesn't either, you slap the word "will" onto a verb to make it future, but it can also be implied, e.g. "We're going to Japan" can mean you are literally going to Japan right now or you are in the future, depending on context. Japanese is pretty similar in that regard. So much of language is essentially automatic, we don't even realize all the strange rules we're following to get our ideas across. This is why the Sapir-Whorf hypothesis is bullshit for natural languages, if it were real then languages wouldn't be so flexible. HOWEVER, for formal languages such as programming languages, its a different story. Design choices can clearly make it easier or harder to program things in a certain way. A classic example is that somebody trained in imperative languages will probably have a hard time adapting to the functional style.

>>34759 >HOWEVER, for formal languages such as programming languages, its a different story. Design choices can clearly make it easier or harder to program things in a certain way. A classic example is that somebody trained in imperative languages will probably have a hard time adapting to the functional style. Nope, still bullshit. Different schools of thought teach different approaches to solve the same problems. A Capitalist and a Communist will look at the same economic problem and provide two different answers. It doesn't make thinking about the problem any easier or harder - but it will change your answer to the problem. "Someone trained to use a hammer and nails will probably have a hard time adapting to using screwdrivers and screws."

>>34762 So, you agree? I'm really struggling to understand the disagreement.

>>34763 LRT supposes that *language* is what shapes your thoughts. How you approach a problem is not affected by your choice of language. Again refer back to Communism vs Capitalism. Thinking like a Communist or thinking like a Capitalist is not determined by the language you're using. You can be an English-speaking Communist or you can be an English-speaking Capitalist. Speaking English doesn't make it any harder to understand Communist or Capitalist approaches to an economic problem. What makes it difficult is if you are ignorant of the philosophy behind the approach. A Capitalist who doesn't understand Communist philosophy is not going to understand Communism. A Communist who does not understand Capitalist philosophy is not going to understand Capitalism. English is entirely irrelevant to the discussion - you can replace it with any language you want. Russian, Chinese, Portuguese, Japanese, French, Swedish, nothing changes. Functional vs imperative are two kinds of approach and both approaches are language agnostic. Multi-paradigm languages could not exist if it weren't. Functional programming is difficult for people who don't understand the functional programming *way of doing things* aka "functional programming philosophy". The language of choice is completely irrelevant to understanding functional programming.

>>34764 >Functional vs imperative are two kinds of approach and both approaches are language agnostic I disagree, in the sense that many languages are not agnostic to approach. Haskell, for instance, basically forces you to use a functional style, while writing purely functional code in C will be very inefficient and excessively verbose (since you have to use function pointers everywhere)

>>34765 The tools don't change how you thinking - they change how you approach. You're conflating the two and I'm not sure why. You can use most rocks as a hammer but you'll find it very difficult to use most rocks as a screwdriver. If all you have is a rock - you will find it easier to use it as a hammer than as a screwdriver. That doesn't mean you would have difficulty understanding screws and screwdrivers or how they work. If you're given a screw and a rock you're most likely going to use the rock like a hammer even if you understand screws are meant to be used with screwdrivers. The tool you have is limiting your available approach - but is not limiting your understanding of the problem. The imperative programming style is easier for most people to grok. You never hear about a functional programmer who doesn't understand how to program in an imperative style. If LRT had a grain of truth to it this affect on how one thinks would work in both directions: functional programmers would have difficult with imperative styles. But you never hear of that - it's always in the direction of imperative programmers struggling with functional concepts.

>>34766 >The tool you have is limiting your available approach - but is not limiting your understanding of the problem. It is if your thinking is informed by the tools you know how to use. Programming languages are not like natural languages in this respect, because natural language is (generally) *about* the world, which is mostly the same everywhere, while programming languages are *about* a particular model of computation. The model used is part of the programming language. > You never hear about a functional programmer who doesn't understand how to program in an imperative style. This is possibly because almost everybody learns imperative languages first.