I find it much easier to read some Q/KDB I've written earlier than the equivalent C++ or C#/Java. For three reasons: 1) It is extremely terse. A small block

I find it much easier to read some Q/KDB I've written earlier than the equivalent C++ or C#/Java. For three reasons: 1) It is extremely terse. A small block of code will do what pages of boilerplate class definitions, interfaces, setters/getters, declarations, typedefs etc. will achieve. There is usually no need to navigate through a spaghetti chain of virtual function calls. 2) It is interpreted. I can quickly (without compiling) cut out chunks of the code and run them to understand what they are doing. I can create variables on the fly, fill them with test data, and run the function. If it calls another function, I execute the name of the function and it returns the function code, since functions themselves are first class variables. 3) It actually becomes easy to read because it is easy to parse, for both machine and human. K/Q is read right to left, and so breaks some traditional conventions. For example, 5*6+3 will evaluate to 45, not 33. At first this can be disconcerting, but eventually you will realise that parsing a line of code no matter how complex it looks is quite simple - you mentally start at the rightmost token and start gobbling. This is probably why the interpretor is so fast as well. As someone mentioned below, I'm not sure why you'd consider it "too cryptic". Anything is cryptic when you first encounter it. I suppose the difference is that Q/KDB provides an (extremely valuable) solution to the financial world - the handling of big data long before it was even called that (a tick database with billions or trillions of rows) so there is a valid motivation to learn the language and it doesn't feel cryptic at all once you've immersed yourself in it.