Consider this KL expression:

a + b * c - d / 2

In KL, it means perform these steps/operations: start with the contents/value of variable "a", then add "b", then multiply by "c", then subtract "d", then divide by 2. (Here "divide" etc means the KL definition of "divide" that is based on the true mathematical definition of division but is NOT the same.)

Compare with the C/C++ language. The above expression is executed/performed differently in C than in KL. In C, it is executed as follows. "Divide" etc means the C definition of "divide".

1. Start with the contents/value of variable "b".
2. Then multiply by "c" and store that answer in a temporary location #1.
3. Then take "d" and divide it by 2, and store that answer in a temporary location #2.
4. Then take "a" and add temporary #1.
5. Then subtract temporary #2.

Or:

1. Start with the contents/value of variable "b".
2. Then multiply by "c".
3. Then add "a".
4. Store the answer so far into a temporary location #1.
5. Then take "d" and divide it by 2.
6. Then subtract that from temporary #1.

KL executes the expression in simple straightforward left-to-right order. Whereas C has a rule that its multiply and divide operators have a higher precedence than its add and subtract operators, requiring that the multiply and divide be executed/calculated first despite the fact that they do not appear first in the expression (out-of-order execution).

C++ has 50 operators distributed across 17 precedence levels. It is impossible or impractical or onerous for a person to accurately remember/memorize the precedence of every operator in C++. Whereas KL avoids this problem by mostly not using operator precedence (or using only minimally), favoring simple left-to-right execution (a rule that is trivially easy to remember).

Both KL and C have binary bit manipulation (bitwise) operators. Following is an example expression using bitwise operators:

a | b & c ^ d << 1

Usually when a programmer writes such an expression, they formulate it in their mind by thinking in terms of a series of sequential steps/operations. Do this, then do that, then do something else. They naturally write the operations in the same order that they were thinking of them, that is the order that they want them to be performed.

Thus when programmers write an expression such as the above, they usually want it to be executed in left-to-right order (as it appears). The problem with C/C++ is that no-one remembers the precedence of those operators, and thus they do not know in what order the above expression will be executed. A precedence chart can be retrieved and consulted but that is painful/tedious especially when done repeatedly.

Programmers want the expression executed sequentially / left-to-right but they do not know how it will be executed so they force sequential execution order by inserting brackets/parentheses regardless of whether each bracket is necessary:

(((a | b) & c) ^ d) << 1

In summary, if a programmer experienced with both C and KL is reading some source code and sees the bracketless expression...

a | b & c ^ d << 1

...in C they most likely will not know what exactly it means (or they will be uncertain) until they retrieve and consult a precedence chart. Whereas in KL they instantly know and are absolutely certain that it is executed in the same order as it appears (left to right).

Also note that programmers can and do use bitwise operators and + - * / operators in the same expression (mixed together). An example follows, taken from a typical binary search algorithm. Thus bitwise and + - * / operators cannot be considered or treated as 2 separate/independent situations.

(low + high) >> 1

When a normal person who is not a mathematician and not a software engineer is asked to explain the standard mathematical precedence rules of the four basic operators and parentheses, the majority of people explain it incorrectly or inaccurately or incompletely or with difficulty. To confuse them further, ask them to include powers/exponents in their explanation of standard precedence.

Some people will attempt to quote an acronym they were taught in school as a way to remember the order of operations. For example, PEMDAS, BEDMAS, BODMAS, BOMDAS, BIDMAS, or BIMDAS. Even if they manage to remember the acronym correctly, all of those acronyms are misleading.

For example BODMAS is an acronym for "Brackets, Orders, Division, Multiplication, Addition, Subtraction". However, multiplication and division are of equal precedence, and addition and subtraction are of equal precedence. Thus using any of the above acronyms in the order of addition before subtraction would give the wrong answer to 5 - 3 + 2.

Note that KL is a programming language NOT a mathematical language, and programming is NOT the same as mathematics, thus conventions used in the field of mathematics are not necessarily appropriate in the field of software engineering. Furthermore, mathematicians are not the target audience/userbase of KL.

In mathematics an expression such as "a + b × 2 ÷ 3" is a theoretical construct or part of an equation whereas in programming "a + b * 2 / 3" is a series of steps/operations to be performed/executed.

Mathematicians have already implicitly or unconsciously realized/acknowledged that the idea/convention of giving the × and ÷ operators a higher precedence than addition and subtraction operators is a bad idea. This explains why mathematicians are rarely seen writing in the form "v × a + b × 2 ÷ 3". They usually prefer to write in the following form that eliminates × and ÷ operators:

This form works well in the field of mathematics but is unsuitable or impractical for a programming language.

KL cuts through all the mess by providing simple straightforward as-it-appears left-to-right execution of expressions.