My dad used array languages throughout his career— APL at some point, A+ at Morgan Stanley, and K later on at Conning, a finance modeling company serving the insurance industry. They moved what I think is a flagship product (a macroeconomic monte carlo sim thingamajig) from K to Julia a while ago. Here's his old boss at JuliaCon talking about it.
I don't think he keeps any old code lying around, but in the past I've tried reading it without success. That makes me a DSF— a Domain Specific Failson :[
Heh, I consult in finance and there’s so much k/q code out there. It’s like the ultimate expert-friendly language, it’s extremely powerful, but it really takes a lot of dedication to learn, in a similar way that “pure” functional programming languages also take a lot of effort to learn if all you ever did was imperative programming.
I spent a couple of months last year learning q. When I went back to it this year, I realized it would take significant effort just to refresh my skills. I now program for fun in gawk.
It’s a bit like dismissing Chinese because you can’t read the letters I think.
But perhaps another failing of the current array languages is that they are sort of walled gardens. Not as easy to integrate or modularise as something like JS/Python (on the other end of the PL spectrum.
Computer language design is an intersection of applied mathematics, computer science, individual psychology, group dynamics, and history.
Syntax doesn’t exist in a vacuum. There is a significant adoption advantage that can be gained by reusing popular idioms. This is why QWERTY is more popular than Dvorak long after mechanical typewriter arms or even permanently marked mechanical keys! I’m pecking this out on a phone keyboard which is just software.
I don't know that's a concern for users of the languages. When you can spend years tuning and optimizing a 'program' that fits in a tweet, those other things don't really have a chance to get involved.
REPL-driven development keeps me in the flow. I can write (and test) multiple different approaches to a problem in J or K before I can finish typing the first approach in C++. And that's not even counting time and context switching costs of compiling and running the C++ code.
Lisps and Smalltalk also have repl-oriented development, but they're verbose. Even tab-selecting a Copilot generated autocomplete takes more keystrokes than some array language programs.
I never worked with them but I assume it's the same reason cpp guys end up doing some in python, prototyping is easier with instant/short feedback. Later you solidify the solution in statically typed languages.
People have done (there’s at least one guy making games in BQN) , but nobody has really nailed heterogeneous (CPU/GPU) compilation, and gfx api integration from a ux perspective. We desperately need better API agnostic frameworks before things like this can take off
For the experts in this thread: is there any benefit to using these so called array languages compared to using something like numpy (or even pandas/polars) ?
The short answer is yes. There have been many presentations on this topic that tries to explain it in various ways.
The problem is that most people who are unfamiliar with APL usually don't see the larger picture, and you need to learn the language before understanding the reasoning. But once you understand it, you don't really need to hear the arguments anymore.
One argument that may be easier to digest is that the very optimised syntax allows you to easily work with the data in an interactive fashion. This is similar to how a calculator that forced you to write 1.add(2) would be rather painful to use, even if it functionally is the same as 1+2.
In programs that you save to a file and is part of a larger project, this benefit is of course less relevant.
For me, the feeling of being well-designed or expertly crafted is what sets the array languages apart. Learning one concept often (intuitively, for me at least) extends to many other parts of the language.
For example, in Q the comma operator concatenates arrays:
q) 1 2 , 3 4 5 // returns 1 2 3 4 5
...but it also merges dictionaries (duplicated key `x gets the new value):
q) (`a`b`c!1 2 3),`c`d!4 5
a| 1
b| 2
c| 4
d| 5
...and also joins tables by row. Sure this is "just" operator overloading, but it's so deeply ingrained in the language it doesn't feel jarring or bolted-on like in other languages.
Building a program is less about crafting bespoke abstractions and more about using the existing building blocks, which leads to a semantic uniformity that's rare to find in other languages. Or at least, it's easier to get your job done using only built-in features and not have to resort to custom abstractions.
K and Q are programming languages. Q is the successor of K.
Kx is the company behind kdb+
kdb+ is the database engine that K/Q can use to persist data. It’s literally as if all your code is executed inside the database engine (because it is), you can access all data by memory and variables, and it periodically synced to disk (using mmap iirc).
In this respect, probably nothing, and they probably all mean Q.
Q is a different language to K, implemented in K. There are more versions of K than Q- kdb+ is the only Q implementation, but there are others like shakti, ngn/k, and kona that implement K.
https://www.youtube.com/watch?v=EE2yz0ptSzQ
I don't think he keeps any old code lying around, but in the past I've tried reading it without success. That makes me a DSF— a Domain Specific Failson :[