Programming uses the same words as regular English, but it is a completely different linguistic register, so there is never any conflict. It’s like working in any field with its own jargon — you use the meaning that is relevant to the context. In linguistics this is called the Relevance theory of meaning and interpretion, which explains why we do this contextual interpretation easily and mostly without thinking about it.
I am a native English speaker and former ESL teacher with a masters degree in applied linguistics, as well as veteran developer.
> Programming uses the same words as regular English, but it is a completely different linguistic register, so there is never any conflict.
Moreover, when you cross over those jargon terms into their regular meaning, hilarity ensues.
For example, you can easily prove that oaks are infinitely tall in winter. Start by observing that in winter, oaks don't have leaves. Then consider the graph-theory definition of "tree" and "leaf".
There's the old joke about the programmer who was told to go to the store for bread, and while they were there, to get eggs. Still at the store, getting eggs.
That's a good point: "never any conflict" describes the final state rather than the growth process.
When I was a younger programmer (as in, during the first few years), I discovered that assuming boolean / formal logic meanings for {if, or, else, and} in communication with my spouse (art + sales, and very smart, though not a programmer or trained in symbolic logic) resulted in, shall we say ... miscommunication. So I had some unintended help in building the separate registers of meaning / communication. :-)
Building separate meaning registers for communication does take some time.
Yes, "or" in English often is more similar to xor in code. For example if someone says "I want pizza or a burger", that person probably does not want both pizza and a burger for the same meal, whereas in programming an equivalent expression would be satisfied if both are true simultaneously.
But "or" in English doesn't always mean xor in code. Sometimes it is the same as or in code.
English "or" is ambiguous between inclusive and exclusive meanings. Most of the time, the intended meaning is inferred based on context, but one can make it explicit by using phrases such as "but not both", "exactly one of", etc.
There exist languages which lack this ambiguity. Latin has two different words for "or" – "vel" (inclusive) and "aut" (exclusive).
There's another way that or_English is different, as illustrated by this frustrating "joke":
1: do you think it's A or do you think it's not A?
2: yes (assigning a truth value to the or expression rather than indicating which or operand is true.)
> has or in English a different meaning than in code?
“Or” in English can mean either exclusive-or or inclusive-or (usually it means the latter), and/or is a means to specify inclusive-or without ambiguity (the parallel construct for exclusive-or is “X or Y, but not both”) used mostly in contexts where misconstruction can be exotics to the drafter of the text, such as contracts and formal policy documents.
In code, the meaning is already unambiguous; in all languages I am aware, “or” or the symbol referred to in speech with that name (e.g., “||”) is strictly inclusive, and do there is an exclusive-or operator, it is different.
> In most programming languages the boolean operation 'or' is actually 'xor'.
I can't think of any where that's true; logical “and” and “or” are usually exactly what they claim to be, and many languages implement both as short-circuiting operators, whereas XOR can't short circuit because you can never know the result without considering both arguments.
> Programming uses the same words as regular English
Let us be clear that this is US English and not British, but I agree with your sentiment: that the keywords are more a linguistic jargon than anything.
Although the main topic here is about other languages, there are also nuances within the two main streams of English that it's also a little wierd sometimes.
For me, I spell color with a U: ie. colour, but when coding, it's always been the US variant. I've typed this word so much that when I need to type it in my variant, that colour just looks wrong, even though it's the correct spelling in (my area).
Occasionally, when skimming British code, I've come across colour variables and it looks wrong. Similarly, I've looked at French code and there are similar strange things that leak out. The same for Russian and Japanese code I've encountered, eg:
> function <insert_diacritic_or_kanji_here>(char p)...*
The purist in me really wants to state: "everyone should type US English", but the more accepting part of me concedes that maybe keywords should be internationalised (/internationalized) too. Maybe a preprocessor system would suffice (eg somecode.c.jp -> somecode.c), but as you state: it doesn't seem right because of the 'jargon' nature of it.
The good news is that machine code and punch cards have no language, so maybe we could revert to using that and then we can neatly skip over this issue entirely ;-)
Yep. Virtually no word has a concrete meaning without a context. For example the word “guys” which may mean a group of males or just a generic collection of people irrespective of gender depending on the context in which it is used.
While some things are arguably vaguely close in meaning, e.g. `loop`, there are plenty of things which are essentially meaningless (or only coincidentally are words in English) like `car`, `cdr`, `cons`.
I am a native English speaker and former ESL teacher with a masters degree in applied linguistics, as well as veteran developer.