>Why should I learn this language that I've never heard of if it can't even do math in any sensible way? Not left-to-right, not order of operations, not lisp-li

>Why should I learn this language that I've never heard of if it can't even do math in any sensible way? Not left-to-right, not order of operations, not lisp-like prefix. Who thought that was a good idea? Of the three choices you mention only one makes sense as an alternative: left-to-right instead of right-to-left. Order of operations, as it turns out, has nothing at all to do with real computation (in the same way that pi really should have been defined as 2pi). Most educated people, after a moment of reflection, should agree with this statement. Getting rid of order of operations makes the parsing process simpler, both for the compiler and for your head. If order of operations wasn't so ingrained in your head there would be no reason at all to use it. K makes a lot of design decisions like these: doing what's right at the expense of what's common. I'm not sure where order of operations came from, probably as a nicety for mathematicians dealing with complicated polynomials, but when computers came about it must've been clear that it was the wrong way to do things. Here's a code snippet that makes order of operations look just as silly: a*b+c%d%e+f*g^h*i*j*k-l / ugly with order of operations, hidden levels of complexity Lisp prefix form, from a mathematical point of view, certainly makes more sense than order of operations. The reason it isn't used in K is, for one, K is inline, and two, Lisp syntax demands a lot more written code than K, and this goes against the philosophy of K. K wants to create the shortest programs in the shortest amount of time. For example, something that is perfectly natural in K 2+7%3*2+5 / k, 9 characters - 1 level deep looks ridiculous in Lisp (+ 2 (% 7 (* 3 (+ 2 5)))) ;Lisp, 25 characters - 8 spaces, 8 parentheses, 4 levels deep ;Two parentheses and one level of nesting for each operation for the reason that Lisp is not as rabid about brevity as K is. (And how could it be. K is a much newer language.) This leaves left-to-right evaluation. One argument against left-to-right evaluation is the following code: f g where f is any function. For instance g:3 f:{1+x} f f g 5 and so on. But this presumes that you accept two axioms (1. you should read left-to-right as in English 2. functions should precede operands). I am currently of the opinion that left-to-right evaluation is better given a left-to-right read order g f f / 5, fictional example because I've yet to discover sound reasoning why mathematicians believe the function should precede the operand. (The answer may be that there isn't a reason, and mathematicians did it that way only because they never cared enough to pay close attention to syntax. Or perhaps it's because written mathematics "executes" in English, and not in an interpreter.) The language designer has defended right-to-left evaluation with the following statements. "Why right-to-left?" so that it reads left to right. note k executes left of right, e.g. syracuse operation: 1+3* the basic math notation is: f g h x executes right to left but reads f of g of h of x I remain unconvinced, especially since there are benefits to left-to-right execution (presuming left-to-right read order) including on-the-fly processing. It just seems more natural to me, mathematically, though I admit it would be very unnatural for me to write in such a way. K is a beautiful language with a lot of nice features. Anything truly innovative is going to look new and different, and in K you get the statement 3*2+5 / yields 21 There are a lot of unusual looking things in K. There are also lots of very powerful ones. But these won't reveal themselves until you spend a time looking at the language. So my suggestion is if you are intrigued by the powerful stuff, keep looking, and don't be turned off by the strangeness of the simple stuff. In some cases you may find that your opinion changes on how things should be done. There is a lot of wisdom hidden in K.