5 ms·

> let's say I have a finance team that have never heard of it - why might they be interested? In my experience it's very good at quickly developing real-time a

> let's say I have a finance team that have never heard of it - why might they be interested? In my experience it's very good at quickly developing real-time analytics applications with only a small set of developers. A couple of q developers can develop, maintain and operate the server side of 5 or 6 separate applications without breaking a sweat. Changes come in at a high speed too. It's a highly interactive language. A bit like a lisp, you start up a q process, open a port and then you iterate and update your application live without needing to restart. Typically on our projects we've had a well iterated program running in QA for a day or 2 before opening a PR (which becomes more of a formality for getting the solution to the problem into prod at that stage). The q language itself is quite wordy. Check the reference page: https://code.kx.com/q/ref/ https://code.kx.com/q/ref/ Many programs written in q consist mainly of the key words with the special operators interspersed. Also see some example libraries: https://github.com/finos/kdb https://github.com/finos/kdb It's been a fairly stable language to work with, having few breaking changes between successive versions. q code written 8/9/10 years ago on older versions will most likely still run the same today. We have source code on one project at work which hasn't had a code change in 6 years now (despite moving through different versions 2.8->3.0->3.3->3.5->4.0) and it runs daily without a hiccup. Mostly it's a joy working with it because I feel like I get to tell the computer what I want it to do, without also having to tell it how to do it.

ssfrr 4y ago
How do you think about the k/q split? Do you ever drop into k or use q exclusively? Is q mostly just longer aliases for k verbs or do the semantics differ?
- leprechaun1066 4y ago
  We stick with q as much as possible. We've found it's better for our front end developers who only touch it a bit here and there to make edits on the APIs they use. That said we do make heavy use of the functional form of querying tables (https://code.kx.com/q/basics/funsql/#select https://code.kx.com/q/basics/funsql/#select) in the more complex parts of our systems. The toolbars in the GUIs allow users to select a wide range of possible ways to request data. It's a lot easier to dynamically generate the functional format of the different parts of a select query than it is to try and play with manipulating lots of stored procs. Anyone with experience in a LISP would be familiar with this way of manipulating code as data in this manner, since it's a similar concept. Some would say this is k, not q and the lines are probably a bit blurred here. Either way there's no question that doing so has made things more productive. As an aside, there's no performance difference between using k and q. Most of the q keywords are implemented in k. Programs written in k do look quite different to those written in q, even if you stick to the mantra of one thought per expression, one expression per line. Myself, I used to only like q since it was easier, especially when I started. My only programming background was C# and Python; q made it easy to get into the different paradigm of the APL family. Now, after years working with it, I'd prefer to use k where-ever possible. The brevity is nice. When you write something non-trivial you see a lot of the same patterns of characters on the screen. And it just feels better to write one character for | instead of typing out reverse. Personally I'd prefer to go with Arthur Whitney's advice from an interview he did years ago (that I can't find a link to unfortunately). He basically said work in k until you need to do big database work with kdb+, then pull in q. Convincing the team and management to let me do that is probably a lost cause though.

ssfrr 4y ago

How do you think about the k/q split? Do you ever drop into k or use q exclusively? Is q mostly just longer aliases for k verbs or do the semantics differ?

leprechaun1066 4y ago
We stick with q as much as possible. We've found it's better for our front end developers who only touch it a bit here and there to make edits on the APIs they use. That said we do make heavy use of the functional form of querying tables (https://code.kx.com/q/basics/funsql/#select https://code.kx.com/q/basics/funsql/#select) in the more complex parts of our systems. The toolbars in the GUIs allow users to select a wide range of possible ways to request data. It's a lot easier to dynamically generate the functional format of the different parts of a select query than it is to try and play with manipulating lots of stored procs. Anyone with experience in a LISP would be familiar with this way of manipulating code as data in this manner, since it's a similar concept. Some would say this is k, not q and the lines are probably a bit blurred here. Either way there's no question that doing so has made things more productive. As an aside, there's no performance difference between using k and q. Most of the q keywords are implemented in k. Programs written in k do look quite different to those written in q, even if you stick to the mantra of one thought per expression, one expression per line. Myself, I used to only like q since it was easier, especially when I started. My only programming background was C# and Python; q made it easy to get into the different paradigm of the APL family. Now, after years working with it, I'd prefer to use k where-ever possible. The brevity is nice. When you write something non-trivial you see a lot of the same patterns of characters on the screen. And it just feels better to write one character for | instead of typing out reverse. Personally I'd prefer to go with Arthur Whitney's advice from an interview he did years ago (that I can't find a link to unfortunately). He basically said work in k until you need to do big database work with kdb+, then pull in q. Convincing the team and management to let me do that is probably a lost cause though.