49 ms·

Hi Geo, Thank you for the time to respond. I understand that speed is very important and I'm happy that Q takes it seriously. I was never questioning that part

Hi Geo, Thank you for the time to respond. I understand that speed is very important and I'm happy that Q takes it seriously. I was never questioning that part. I also understand the beauty of functional programming paradigms (working with maps and applys), I wrote many lines in Mathematica without "for" loops. I also understood many code snippets written by developers working only with Q (I guess they are experts). I don't know the full power of Q, but I can imagine what is achievable. I haven't worked with Q for 18 months, the debugger sounds cool. Forgive me if my knowledge is not up-to-date. Also I wanted to use the language immediately without learning it for months, which might be the main source of my frustration. I believe that there could be a better developer environment without making the system slower, and that could reduce the time required to use the language efficiently from the several months to several days or hours. The evaluation order is not clear to me. I understand this expression: q){x+2*y} scan 2 3 5 7 (the result is: 2 8 18 32). However, I often had to read more complicated code which contained 1 or 2 character long operators. Without fully understand their syntax, I was unable to tell whether those operators take values from both sides, which stopped me from understanding the evaluation order. It would be great if a tool could convert this expression to q)scan[{x+2*y};2 3 5 7] and that tool also would replace cryptic 2 character long operators by long readable names (e.g., MapForTables). I think that the error messages need to be as verbose as possible. You mentioned that experts don't ask for the debugger and verbose error messages. I think that they simply got used to not having these useful features, but they would use them eventually. I'm okey with the limited number of variables until it gives a proper error message if violated. People working with Q told me that it was hard for them to restart working with Q after 1 month break, because they forgot the lexical knowledge needed for the efficient work. Peter

geocar 9y ago
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
- Firadeoclus 9y ago
  Short names and terseness are indeed features - for those who have already internalized the meaning of names and symbols. The problem is that bridging this ocean takes such a long time that for many people it's just not worth it (and for many others it doesn't _seem_ worth it). It's doubly frustrating because it doesn't have to be that hard. With a projectional editor descriptive names, explicit evaluation order, inline expansion of functions and macros (e.g. for the C code mentioned below) could just be a button press away. And it's not like experienced coders would never benefit from such tools, either.

geocar 9y ago

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

Firadeoclus 9y ago
Short names and terseness are indeed features - for those who have already internalized the meaning of names and symbols. The problem is that bridging this ocean takes such a long time that for many people it's just not worth it (and for many others it doesn't _seem_ worth it). It's doubly frustrating because it doesn't have to be that hard. With a projectional editor descriptive names, explicit evaluation order, inline expansion of functions and macros (e.g. for the C code mentioned below) could just be a button press away. And it's not like experienced coders would never benefit from such tools, either.