I am writing a book set in a parallel universe where English is not the dominant language and the dominant language is a complex polysynthetic language that makes use of a complex system of word declension using affixation that contains both agglutinative and fusional structures.

While the dominant language of my world is not Cherokee, its grammar is very similar to mine. I have not finished creating my conlang, so I will simply give a concise and hopefully easy-to-understand description of the Cherokee language below. Since most people cannot read the Cherokee syllabary, I will transcribe all Cherokee words below using the traditional romanization system.

The Cherokee language is polysynthetic, meaning that words are formed from several smaller parts that form a word with the meaning of several different English words combined into one. The word tsiwidagilvwisdanelv'i can be broken down into several smaller parts that each have smaller meanings, but none of them can be used by themselves as standalone words.

  • tsi- means "at that time"
  • wi- means "over there"
  • d- (or de- before a consonant) means that it occurred multiple times
  • agi- means "I" in this context
  • -lvwisdane- means "work"
  • -lv'i signifies the remote past

This single word therefore means "I used to work over there back then, a long time ago." However, as I said earlier, I could not use any of the affixes or roots shown above in isolation while speaking.

In Cherokee, all affixes (although all of them have two forms depending on whether or not the following syllable begins with a consonant or vowel) can be used with all verbs except for those that indicate pronouns.

Cherokee prefixes that indicate pronouns not only differ depending on whether or not the following morpheme (unit of meaning); they also combine the subject and object pronouns into one pronoun and differ depending on the tense of the verb indicated using a suffix. Imagine if instead of saying "I told you," I said "Iyou-told," except that the prefix with I as the subject and you as the object is not a combination of the two base pronouns and cannot be predicted just from knowing the word for I and the word for you.

In addition, different verbs conjugate differently based on whether they are action verbs, passive/stative verbs, or irregular verbs. Irregular verbs conjugate in five different ways based on whether the direct object is living, flexible, long, indefinite, or liquid. There are also some predictable periodic changes to maintain a strict consonant-vowel syllable structure within the middle of syllables.

How exactly would early computer programming languages and text-based games (pre-AI) exist in a society that speaks a language that is so grammatically complex?

  • 10
    $\begingroup$ The real question is how would be possible for such a language to become dominant in an entire world. If we look at our history, none of the languages which have ever achieved predominance over large areas, Aramaic, Greek, Latin, Classical Chinese, Arabic, Spanish, French, English, Russian, are anywhere near such degree of complication. The entire point of a lingua franca is that most of the speakers are not native speakers, with the language serving as a means of communication between people with different native languages. $\endgroup$
    – AlexP
    Nov 11, 2023 at 9:37
  • 5
    $\begingroup$ Ho does this differ from Finnish or Hungarian? $\endgroup$
    – d-b
    Nov 11, 2023 at 20:31
  • 7
    $\begingroup$ I'm not quite sure what the relevance of a phrase meaning "I used to work over there back then, a long time ago." is to the development of computers? Is there not an easily identifiable morpheme for if, for, variable? $\endgroup$ Nov 11, 2023 at 22:49
  • 3
    $\begingroup$ Language does not affect how we think. Yes, it is a very common science fiction trope that different languages somehow makes humans think radically different, but no, in the real it does not. Your premise of using a different language on an otherwise Earth facsimile does not force or even suggest that computing machines would develop differently. And even if that was(!) the case, then the whole rest of human development would also be up-ended, and that would have a far more significant impact on the development of computers. (Continued) $\endgroup$
    – MichaelK
    Nov 12, 2023 at 13:13
  • 5
    $\begingroup$ How is your "word" different from a "sentence" in English? Yes, the various affixes can't be used separately (but really, can you use "over" or "to" independently in English?), the order, structure and grammar are different, but so what? As long as you can express something, you can reuse that in a computer language, if that language even uses words. $\endgroup$
    – jcaron
    Nov 12, 2023 at 15:41

12 Answers 12


Early computer programming languages were originally machine code, which was effectively a sequence of numbers that encoded machine instructions, memory addresses and the data on which the program would operate. A later development of machine code was assembly language, which uses mnemonics to represent machine instructions, and allowed users to name constants, memory locations and parts of the program in order to simplify programming, but in essence, assembly code bears a nearly 1:1 relationship to machine code.

In all of this, there is no need for the machine or the assembler program to parse natural language save where the program that has been written is designed to do so.

From there, the development of higher-level languages that more closely approximate natural language can be developed. I have no doubt that with a polysynthetic spoken language, the higher-level computer languages may be rather different, but I also have no doubt that the programmers would be just as capable of making such a language as the developers of the languages that our computers have used.

In some ways, a polysynthetic language may be simpler to parse. In the example given by the OP, the synthesis of the word involves specific prefixes and postfixes in specific positions. At each position, there would be a limited number of options for affixes, and parsing them would involve a decision tree of limited size. Yes, there are complications due to irregular word forms, but then many other languages have irregularities, including more analytic languages such as English.

So, natural language processing would still be a challenge, but the language still has a structure that makes such processing possible. The challenges would be different to that of parsing English, but not necessarily particularly greater. This language can be understood by humans, after all, and as long as a programmer can understand it, a sufficiently powerful computer can be programmed to do so too.

  • 2
    $\begingroup$ As a little tangent on NLP, Cherokee language is tonal. This would mean parsing speech would be more difficult. Incidentally, it probably wouldn't occur to a tonal language speaker to implement the thing you hear in voice chat where it drops the tonal part to save bandwidth. $\endgroup$
    – HAEM
    Nov 12, 2023 at 17:02
  • 18
    $\begingroup$ I doubt that computer languages would have developed any differently with a Cherokee-based lingua franca. Current programming languages are already very different from natural languages and I believe all the design constraints and requirements that caused programming languages to be the way it is would've caused programming in Cherokee-based lingua franca be more similar to our current programming language than they do to Cherokee. $\endgroup$
    – Lie Ryan
    Nov 13, 2023 at 6:18
  • 7
    $\begingroup$ @HAEM I think you are looking at this backwards. If the dominant language is tonal, one wouldn't drop the tonal part to save bandwidth but rather use a system that is optimized for this tonal language. I think extracting the tones in a language like Chinese is fairly easy for a computer if you program it to do that. Which one would do if that is a feature of the dominant language. $\endgroup$
    – quarague
    Nov 13, 2023 at 7:12
  • 5
    $\begingroup$ @HAEM and in a tonally dominated world, we wouldn't use ASCII but rather some other character set that is optimized for that language. ASCII only became the lingua franca of computers because English was the language of the inventors of computers. $\endgroup$
    – Questor
    Nov 13, 2023 at 20:13

Every computer language now in use is far and away simpler than the language of the person who developed it. Even the languages with the simplest grammar are more complex than the most verbose and elaborate computer language.

This is because computers, when compared to the human mind, are actually quite simple entities. Their basic operations are actually very few, and it is only because they can quickly and reliably perform these operations that we have any use for them at all. Giving instructions to a computer is very different from giving instructions to a human being.

Furthermore, each operation done by a computer, especially at the machine code level, is utterly devoid of context. When the CPU in the Commodore 64 reads the instruction 0xA9, it always takes the next byte in the program and loads it into the accumulator. For instruction 0xA9, it never does anything else. Everything required for the CPU to execute an instruction is contained within that instruction. No human language comes anywhere close to this lack of context.

The language of the natives who develop the computer will influence the computer language chiefly in the naming of the operations. As for the rest, it suffices to say that as different as Cherokee, English, and Mandarin are from each other, each is more different from 6502 assembler, SQL, or JavaScript than they are from each other.

  • 2
    $\begingroup$ You are mixing up computers, assembly languages, and compiled languages. The reason compiled languages have simple grammar is because compilers with more complicated grammar are harder to write. And while there is a sense in which assembly languages lack context, compiled languages can have as much context as one wants. $\endgroup$ Nov 11, 2023 at 19:13
  • 2
    $\begingroup$ @Acccumulation not just compiled languages; you still have to parse interpreted/transpiled languages, so its all the same $\endgroup$
    – Seggan
    Nov 12, 2023 at 2:05
  • 2
    $\begingroup$ @Acccumulation You're missing the point. Assembly is an EXTREMELY simple language. Contrary to what you say, its grammar is far simpler than higher level languages (most of it can fit into a single PDF: scadahacker.com/library/Documents/Cheat_Sheets/…). High level languages move towards natural language, and have more sophisticated grammar, which is actually why they're easier to write in. Computers talk in a way that is extremely difficult for humans (binary), so abstracting that into something more like natural language, helps. $\endgroup$
    – Chuck
    Nov 12, 2023 at 16:16
  • $\begingroup$ @Chuck "Contrary to what you say, its grammar is far simpler than higher level languages (most of it can fit into a single PDF" Huh? What? I never said that assembly is more complicated than higher level languages. I said the opposite: higher level languages can take context into account in ways assembly can't. When I said "The reason compiled languages have simple grammar [...]" what I meant was that giving compiled languages simple grammar is an optimization choice, not something forced on CS by the inherent nature of computer languages. $\endgroup$ Nov 13, 2023 at 14:02
  • 1
    $\begingroup$ @Acccumulation Ok, then you made your point badly. Emphasising the "simplicity" of the grammar of higher level languages made it sound like you believe that Assembly has more complicated grammar. Also, EvilSnack's answer is absolutely correct: Even the highest level programming language is far simpler than any human language for precisely the reasons they explained. It's got little to do with compiler complexity. We're talking orders of magnitudes of difference. $\endgroup$
    – Chuck
    Nov 13, 2023 at 14:33

Not a worldbuilder, but am a software engineer.

The different language would have no significant effect on the development of computers. The underlying fundamentals of computation are universal, and they are quite foreign to any natural human language.

Just as programming languages designed by and for English-speakers use some English words like “if” and “while”, a programming language designed by and for Cherokee-speakers would likely use some Cherokee words or morphemes. Just as English-based programming languages have nothing more to do with English grammar, nor would a Cherokee-based programming language have anything more to do with Cherokee grammar.

In our world, there have been some programming languages that attempt to resemble the English language more closely than typical programming languages. Generally this has proved more annoying than helpful and with the notable (and regrettable) exception of SQL none of these languages is in common use among professionals. If the Cherokee language had any effect on this, it would likely be to make those uncommon languages even less common.

Cherokee orthography uses eighty-six letters, each in both lowercase and uppercase for a total of 172 glyphs. This is significantly more than English, so it's likely that there would be some minor implications for text encoding. Probably the basic standard would be an eight-bit encoding rather than a seven-bit encoding like ASCII. But this is small stuff. It might be more interesting if there were many hundreds or thousands of glyphs to encode — but maybe not; there are obvious conventional solutions there as well.

  • $\begingroup$ Re, 172 glyphs. Early computers depended on mechanical devices—Teletypes, line printers, etc.—for character based input and output. I once used a machine whose entire alphabet was 26 upper-case letters, ten digits, and six punctuation marks—42 glyphs in all. The development of such machines might have been delayed if type wheels had needed four times as many symbols and, if the gears and levers and linkages that drove them had needed to decode two additional bits. (Q: Did any computer ever work with Chinese characters before the invention of graphics capable displays and printers?) $\endgroup$ Nov 14, 2023 at 18:04
  • $\begingroup$ A minor correction — Cherokee orthography does not intrinsically have a separate set of lowercase letterforms. The lowercase is a scaled version of the uppercase. This is a rather more manageable set of glyphs for a mechanical typewriter, though still more than we're used to. $\endgroup$
    – Thom Smith
    Nov 14, 2023 at 19:43

Mathematics has a very precise notation where particular symbols are given precise meanings. You can express the same relationships in words, but you lose precision.

Here's an example. The word 'cannot' is often explained as an abbreviation for 'can not', but it is importantly different. Imagine the following dialogue...

"I don't enjoy going to my family for Christmas." "Well, you can not go."

If the stress is put on the 'not' it would imply 'you have the option not to go'. If you wrote 'cannot' it would definitely mean 'there is no way you can go'. We do not usually put stresses in writing, so maybe 'can not' and 'cannot' is the imprecise, written language's way of coping with the amphibology.

Computer programming is much closer to mathematical notation. Each instruction should have a precise meaning. It will have a precise meaning according to your computer and compiler. Something will have gone badly wrong if it is not the same on all machines that can execute it. The APL programming language back in the 1960s tried to replace the typewriter keyboard symbols with a better, more precise set of symbols. We kept the keyboard, and adopted precise meanings for the ASCII symbols. For example the asterisk '*' commonly means multiplication, '!' means NOT_, and so on. The '.' symbol is dreadfully overworked, but we manage.

Computer languages need to express a precise idea. They have little in common with natural languages, which can express a great many things without precision. I don't think computer languages are a copy of mathematical notation, because computer statements are executed in order, rather than following one from the other as in a Mathematical proof. But they look similar because they meet similar needs.


As for the programming languages: There would be no difference.

Programming languages are not related to human languages. They respond to universal logical principles that are not affected by human language.

It is very easy to understand because programming is another word for "information logistics". Everything that a program does is it performs logistical operations on information. No program ever does anything else. Would logistics be different with the use of Cherokee language? Imagine a huge truck or trains delivery company or whatever is more popular in your region. Do they care? Hardly. Why? Reality.

To clear up some possible confusion: An average programming language uses a vocabulary of about 50 symbols, for which English words are used purely for mnemonics purposes. Therefore you get all the if, while, function, etc. words in a program. You might have seen huge program texts, written seemingly in English, but don't be confused: all this is just names given by humans to the logistical operations and entities within the program. A huge body of mnemonics for that.

As the laws of logistics are not influenced by the language, even if you use a language other than English, you would still be describing the same stuff like "Take A and copy it into D. Add D to B. If B is greater than C, then subtract C from B", etc. This is all there is, and all there ever was.

As for the text-basaed games: There would be no difference.

Whatever the game is, to a program it's just about moving bits and bytes, and combining them in various ways with logistical purposes. When you ship containers, there's no difference what's inside of them. Hence you may witness that software localization in our world does not influence anything: any program can be translated to any language and it hardly bothers the program. Cherokee would be no exception. You'd just pay additional $$$ for the localization service.

Disclaimer: there are, of course some practical technical differences in representing one or another language, like right-to-left writing support or complex ligatures, or different text lengths, etc.. And if you would need to parse the sentences in various languages, the parser might need to be adjusted for that, like "calibrated". But these are more technical problems akin to typography rahter than something that has any influence on writing programs.

Additional info on AI-based text games: There would be no difference

Because all AIs of any kind, from the simplest if-else AIs to neural networks, are programs. And they see no difference what stuff they're moving around. The mathematical and logical principles of it never change.

Additional info on more exotic programming languages

Funny thing but human languages also solve the problem of information logistics as a part of their function (or they try to). Thus they have different ways to "deliver the meaning" which are reflected in their structure. There were various experiments in structuring programming languages to perform information logistics using various principles as well.

You might be interested to read about the stack-based programming languages and the APL family of programming languages. These two paradigms are closer to what you might call Cherokee simply because their way of describing logistics is polysynthetic as well. Although there is some amusement and research value in these languages, they are very far from being practical in most of the use cases. There are some extreme use cases for them, but generally they have proven to hurt more than be useful. Thus they have not become popular. You might make them or their derivatives popular in your world, if you want to accept that most programmers that read your book are going to facepalm and wince at that part.

Do not be confused: these languages still use the same logical principles, they just have awkward ways of writing them. Like if you try to talk like master Yoda for the rest of your life.

Also, maybe the functional languages, with their function combination, currying, functors, monads, etc. can be seen as remotely polysynthetic or at least lending themselves to such views, but this is already entering a very broad realm of theoretical computer science and related topics.

  • $\begingroup$ Hi. I have trouble following the arguments in your answer, and I feel like there is a bit of circular reasoning. Programming languages wouldn't be different with Cherokee because programming languages wouldn't be different with Cherokee. $\endgroup$
    – Stef
    Nov 12, 2023 at 14:06
  • $\begingroup$ Then you say that stack-based languages cannot be popular, which seems in direct contradiction with how popular reverse-polish notation calculators have been at some point, and how popular the stack-based language Forth was in the 1980s, and how pretty much every programming language uses stacks for function calls nowadays. $\endgroup$
    – Stef
    Nov 12, 2023 at 14:06
  • $\begingroup$ And then you conclude with a paragraph about functional languages which seems to contradict your whole argument and bring it all down, but then you dismiss that with the sentence "this is already entering a very broad realm..." which I don't understand. $\endgroup$
    – Stef
    Nov 12, 2023 at 14:08
  • $\begingroup$ Apologies for my harsh comments. I find this question really interesting and I was genuinely trying to follow the arguments in your answer. But I'm not convinced. For instance, what do you mean when yo say that "if... then..." and "while" are "just mnemonics"? It seems that "if... then..." and "while" are well-understood concepts in the English language, and these concepts translate well to programming, and that's why we have these words in programming languages. $\endgroup$
    – Stef
    Nov 12, 2023 at 14:11

If it helps to continue your writing:

  • Computer languages do not follow or resemble the spoken language of the programmer. Perhaps you imagined they did.

  • At a very basic level they use the concept of an "identifier" to represent the value of something, and an "operation" to convey what needs to done with the values of an identifer.

  • If your conlang doesn't have a writing system capable of labeling a value or concept with something that isn't a word in the conlang itself, you have problems.

    For an English example, if inhabitants of your world couldn't label "Mount Everest" as "mountA" and "Mount Fujiama" as "mountB" you're in trouble.

  • Similarly for operations: if the conlang can't express addition with a word or symbol ('+'), and additional operations such as subtraction ('-') etc, there's no deal.

While I immediately love and honor the existence of the Cherokee language, the details of its word formation and spoken usage don't actually have a bearing on its development of computer languages.

Programmers on Earth have to learn the syntax of the programming language they write in. Programmers on your world will need to do the same.

Finally, do you need to explain anything of the above to the reader?


Q: How would computers develop in a society where a Cherokee-like language is the dominant lingua franca?

A: It would develop in stages as on Earth. Ledgers written with quill pens would come before adding machines with levers to pull down the side, before computers built with electrical relays, vacuum tubes, transistors, integrated circuits, increasing density of transistors on a chip or whatever comes next.

Computer languages would not necessarily use words from the lingua in their syntax.


For the programming language part, i think the other answers allready covered that well enough. For the text adventure part of your question, i think that shouldn't pose too much of a problem. The room descriptions are just texts, so if you can write texts in your language that part won't differ from an english text adventure. The more interesting part is the input parser. Some of the earliest and most primitive text adventures just had a very very limited list of exact phrases that you had to type in to create some action:

if (i$="open door") or (i$="open the door") or (i$="push door") then
   dooropen=true: print "The door is now open".

Anything not on that list ("open gate", "open that door", "unlock door, then open it") would just result in an "i didn't unterstand that".

If you can define a list of terms most probably used in your language, you're fine here - even if the list may be a bit longer. It's not totally clear from your post how much word building is usually done for simple terms - you may have to use conventions of how people have to formulate their input to reduce alternatives if that is too common (don`t say "open(with my foot)the door(that goes outward)(because i want to leave)".

When writing better parsers that actually understand reasonably simple sentences ("take the red key, then unlock the blue door and carefully open it") you will no doubt have a harder time than in english, but that should just slow down the advance from simple to complex parsers by a few years.


The question you should ask yourself is how your society would notate mathematics. Although a lot of math is influenced by western languages, it ultimately does not follow the grammar of any natural language. Programming languages are far closer to mathematical notation than any natural language, and a society that can develop the formalisms necessary to express mathematical ideas precisely will have no trouble designing programming languages that do the same thing (for instance, lambda calculus is essentially a purely mathematical programming language).

One of the main things that mathematical notation does is remove as much ambiguity and context-sensitivity as possible. This is part of what makes it look and feel alien to new mathematicians. It also makes no attempt to connect numerical ideas to natural language syntax, other than for names. Since names are considered "atomic", any declension/conjugation therein is irrelevant to the mathematics expressed. The names of variables and functions serve purely as markers or placeholders, and do not even have to have intrinsic meaning (hence, the infamous 'x').

Programming languages design their grammar not for the convenience of the human, but for the convenience of the parser. The grammar is far more rigid than any natural language, and unapologetically so. It is also unnatural, which is why beginner programmers often wonder why they can't write: "If 0 < x < 100". Things that are "obvious" in natural language, or even in mathematics, are outright forbidden in many PLs because of type rules.

So, my guess is that your PLs will look syntactically similar to ours, but the names will be the distinguishing feature. Fortunately, names are basically boring and irrelevant to parsers. They neither know nor care what language you write them in, as long as you use them consistently, and don't expect it to understand when you try to decline/conjugate them (i.e., don't expect the parser to know you want a container when you say "Widgets" even though you only defined "Widget").


Seems like someone interested in the unique features of Cherokee would be aware of this, but there actually is a Cherokee Syllabary, independently developed by Cherokee in the early 1800s.

This was created by Cherokee who could not read or write English, but observed English speakers doing so, and sort of reverse-engineered how to do it. As a result, their glyphs look rather a lot like Latin glyphs and Arabic numerals, but bearing no relation whatsoever to their meaning in any other writing system.

A "Syllabary" by the way is a writing system that uses a unique glyph for each allowable syllable in the language. This generally requires an order of magnitude more glyphs than representing a language with the consonant-vowel pairs that make up each syllable, but an order of magnitude less than logographs (separate glyphs for every word).

Think of a table where the rows are consonants and the columns are vowels. The cells would be all the possible syllables1. So in this simple case, a syllabary would need c * v glyphs (where c is the number of consonants the language uses, and v the number of vowels), while an alphabet would only require c + v.

However, figuring out alphabets seems to be a very difficult insight, that only provably happened once in human history2, while syllabaries have been independently invented multiple times.

It probably also helped Sequoia that he had English books and newspapers as an example. So he knew when he first tried a logographic system that it was using far too many glyphs. He knew he needed something more economical in glyphs, like a syllabary. He just had to work out a way to do it. Which he did after about 11 years of tinkering. He managed to come up with a scheme to encode the entire alphabet in 86 glyphs.

If you remember me talking about the vowel-consonant table above, here's a rendition of that idea with Cherokee syllable glyphs in the cells, and rough equivalent English vowel and consonants for the columns and rows.

Cherokee Syllabary Table

This was quite simple enough for the Cherokee in what's now South Carolina and Oklahoma to begin publishing their own newspapers, and reports are that about 90% of the nation was literate within 10 years (if true, that's probably better than the USA at that time).

This writing system is still in use today within the territory of the Cherokee Nation. For instance, here's a picture of a Stop sign in Tahlequah, Oklahoma:

Tahlequah stop sign in Cherokee, English, and transliterated Cherokee

As for how this would work, well you'd just need keyboards that can produce the 85 glyphs of Cherokee. The keyboard I'm using right now has 104 keys on it. Of course only 26 of those are used for my English alphabet, but still this doesn't seem like some kind of insurmountable obstacle considering I'm already using a keyboard with more than 85 keys.

In fact in many asian countries (where I understand they are pretty good at coding) native keyboards have far more keys than that. For example, here's a Japanese keyboard from the 1970's

1970's Japanese Keyboard

This is for Japanese's Kanji logosyllabary, but I understand for modern keyboards they just use a more western layout, but with the ability to switch from Latin glyph entry to their own syllabary, which is then automatically translated into Kanji for public consumption.

But the point of this is that printing and keyboards aren't really any kind of barrier with this writing system. They keyboards might be a little larger (without any social pressure to move to a size appropriate for a English's alphabet), but not inordinately so.

As for computer programming, its tough to say. We today have tension between rather verbose languages, like Pascal:

procedure procedure_name (parameter_1 in out typename) is
end procedure procedure_name;

and terser syntaxes like C:

function procedure_name (type_name parameter_1) { ... };

and even terser yet syntaxes like APL, that are essentially logographic for everything that isn't a variable name.

Which would win out in a world dominated by Cherokee? I'd like to think they'd be more partial to the easier-to-read verbose style, but likely human beings would make the same decision human being collectively made historically (as terse as possible without going into full logographic unreadability). We arguably haven't settled this issue yet as software developers though (talk to a Perl or Ada fan sometime), so perhaps they'd still be arguing about it too.

1 - This is actually just the simple case. Indo-European languages like English are not simple cases, and would require syllabaries with tens of thousands of glyphs.

2 - Its quite possible it only happened the one time it did due to a freak collision between a weird language family that had vowels so predictable that they didn't need glyphs for them, with a new language family that wanted to borrow their system, but didn't have that feature, and used consonant clusters that would have made a syllabary a nightmare.

  • $\begingroup$ I am aware of this syllabary, but I didn't include it because I wanted to focus only on grammar. $\endgroup$
    – Galactic
    Jan 7 at 8:30

The Minority Report for your programming question is they would use Perl ;)

Larry Wall, the linguist who designed that programming language, explains his thoughts on the similarities between natural language and programming which you may find more instructive than the many (not-wrong) claims that natural and programming languages have nothing in common. Or not

  • 1
    $\begingroup$ It's worth noting that Perl has a reputation for being very hard to read, and that its use has declined in recent decades in favor of otherwise-similar languages that are easier to read. $\endgroup$
    – Thom Smith
    Nov 13, 2023 at 21:40
  • $\begingroup$ Its decline has nothing to do with its disputed readability, anymore than claiming English is difficult to read. As I struggle through other people's code in many of these "easier-to-read" languages, I realize that it's not the language that's the problem, but the author's skill in expressing their ideas. Perl has issues, but readability is not one of them. $\endgroup$
    – Boyd
    Nov 14, 2023 at 12:12
  • $\begingroup$ As the saying goes, you can write FORTRAN in any language. But I'd still rather not read FORTRAN if I can avoid it. YMMV. $\endgroup$
    – Thom Smith
    Nov 14, 2023 at 18:57

Contrarian answer here. :-)

Of course current popular programming languages have English influence:

  • Typical control structures follow English grammar: if cond then action, while cond do action.
  • Paremeters to functions/procedures come (typically) after the function name, mirroring verb-object order.

As some other answer(s) said, you might want to look into stack-based languages such as Forth and its derivatives, array PL with weird notation such as APL and its derivatives, and other concatenative programming languages such as Joy and similar. And of course, Lisp.

If you wanted to be as much "science-based" as possible, you would have to look at the early history of programming languages. There was a nebulous point between simple assembly and the very first programming languages (Fortran and Lisp) when something in-between was developped (e.g. Plankalkül, Autocode), and that is where you have to insert your change, basing that development on your language instead of English. Also, Mathematics notation influenced PL notation, so you have to consider how Mathematics is writen in your world. Also, perhaps look into early developments in the USSR and Japan.

  • $\begingroup$ If you think about it, the way programming languages use English words doesn't really follow English grammar at all - you would never say in natural English "While not the file at end, do read a line, done". As other answers have pointed out, what's really happening is that you need tokens for certain purposes, and borrowing English words is one way to choose those tokens. That includes pairs like "do...done", "then...endif", or "begin...end" which can and often are replaced by punctuation like "{...}". Some languages even make up words, like using "fi" for "end if" and "esac" for "end case". $\endgroup$
    – IMSoP
    Nov 14, 2023 at 15:42
  • $\begingroup$ @IMSoP I beg to differ with the gist of your comment. Of course PL are not prose, so not English (at the time PL came about, natural language was beyond reach). But PL (typically) are influenced by English, they loosely follow English grammar. E.g. in Japanese, while-equivalent words come after the condition, and verbs come after the direct object. Re tokens: it's interesting to consider that PL are languages, instead of, say, evaluation networks (dataflow, circuits), flowcharts [shudder], or Piet. $\endgroup$
    – Pablo H
    Nov 15, 2023 at 14:38
  • $\begingroup$ I take your point that common programming languages tend to put keywords first, followed by their arguments (stack-based languages being a notable exception that do the opposite). I'm not sure whether that's because of English grammar, or other effects like the ability to see structure at a glance, and ease of implementing interpreters. Either way, it's hard to imagine an easy-to-parse language using aspects of grammar other than word order; even if "if" would normally be a suffix on the verb, programmers would pick some word meaning "thing that is conditional" to use as an invariant keyword. $\endgroup$
    – IMSoP
    Nov 15, 2023 at 16:04

It depends on the number system.

Programming languages are mostly based on mathematical notation, rather than natural language. For example, x = F(y) could be a line from a mathematical proof, or it could be a line of python code (poorly written python code, but I digress). This is because math and programming both need to have precise, unambiguous syntaxes, and they both need to be able to easily work with numbers.

If your parallel universe still uses European numbers as the standard, then their programming languages will be close to ours. There will be different standards and conventions, but that will mostly be from the butterfly effect, not the language being spoken. I expect a programmer from our world would be able to start writing basic programs in their languages the same day she starts learning them.

On the other hand, if all of their math is based on a number system where things like addition, subtraction, and equality are defined by the position of the numbers relative to each other, then the programs they write will be unimaginably different from ours.

As for text-based games and language parsing, it will probably be about the same as in our world. Early games would only try to parse one tense, and only allow a subject, a verb, and a direct object. In our world this was usually 2nd-person imperative, but it could just as easily be 1st-person present simple. Based on your example, the game will accept "agilvwisdane", but if someone types "tsiwidagilvwisdanelv'i", the game will only respond, "I'm sorry, I don't understand, please try again."

  • $\begingroup$ Is there a reason why it would more likely be 1st-person present simple and not 2nd-person imperative in a Cherokee-based computer programming language? Why would a computer favor "agilvwisdane" (I work) over "ditsalvwisdasi" (work in the imperative form)? $\endgroup$
    – Galactic
    Jan 7 at 8:32
  • $\begingroup$ It's just an example. It could just as easily be 2nd-person imperative. Whatever it is, the earliest parsers would pick one sentence structure and accept only that structure. $\endgroup$
    – BlockStop
    Jan 8 at 23:04
  • $\begingroup$ OK. But why did you suggest that a different sentence structure other than imperative might be adopted? Was it simply because you were unfamiliar with the Cherokee imperative form? $\endgroup$
    – Galactic
    Jan 9 at 1:38
  • $\begingroup$ I have no idea what Cherokee looks like beyond your question. The point I was trying to get across was that early parsers would deal with the complexity of their language by simplifying it down to one form. $\endgroup$
    – BlockStop
    Jan 9 at 23:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .