I'm happy to, and by all means reach out -- instructions to find my email are on my profile page and I'm on github, etc. I'm not speaking tongue-in-cheek when

I'm happy to, and by all means reach out -- instructions to find my email are on my profile page and I'm on github, etc. I'm not speaking tongue-in-cheek when I say the short variable names and terseness are a feature. I wrote briefly on this subject previously[1], but there's something difficult to get across here because I have been changed. Learning how to read very dense code changed the way I think about programs, and it has completely eliminated several classes of mistakes that I used to make. I can see repetition where I never noticed it before. I require far less abstraction to get the business problem solved. And yes, my programs are faster. It's also put me across the table- really, might as well be an ocean: q/Kdb is fast because it is written in this way. If you try to write another language/interpreter that isn't all bunched up on one line, that has friendly error messages and long variable names, it won't be as fast. From here it is plain and obvious why, and yet I struggle to show you over there. [1]: https://news.ycombinator.com/item?id=8476113 https://news.ycombinator.com/item?id=8476113 > The evaluation order is not clear to me. I understand this expression {x+2*y} scan 2 3 5 7 Single-character operators, and functions in the dot-q namespace (like scan, which is really called .q.scan) take an "argument" on the left-hand side. Everything else doesn't. > It would be great if a tool could convert this expression to parse[2] can do this, and it was really useful to me when learning q. [2]: http://code.kx.com/q/ref/parsetrees/#parse http://code.kx.com/q/ref/parsetrees/#parse