This is an interesting thread - thx for posting. I used to know a bunch of folks that used both J and K. I still use APL - the old APLWin 3.5 from APL2000 (Manugistics/STSC).

APL was the first language I learned as a tiny child. I write my pseudo code in it. I live in a ranch house out on the tundra, with a 50ft transponder antenna behind the place which links me to the 'net. I've used C, c++, Python with all the numpy stuff, etc and a few flavours of TensorFlow.

But it's APL that gets it done. I've heard of K, and I knew a guy who worked for Arthur Whitney. Languages like K and J and APL can be fast, if you use them right. And it is almost tragic-comical, that the genius of the APL glyphic character set was given up, just as wonderful devices were created which could paint any character at all on the screen. My girlfriend uses Japanese Kangi and Hirogana on her iPad, no problem. In a GUI environment, the original APL characters are easy and clear - no need for silly ASCII overloading.

See, I have these simple GUI apps, written many years ago in Windows, using APLWin 3.5. They still run, and I use them daily. They keep track of financial time series data, and I can use them in a variety of ways. The APL stuff can convert tables of various formats into conformable vectors, which can be transformed into input for GNUplot or TensorFlow or even (my favourite), Hinton's original Xerion product, which I have running on some Linux boxes.

APL is simply a wonderful, easy, useful language that can allow one single person to support some mission-critical production-grade software. Example: This AM, I discovered that all the data tables that my data-table downloader had got last nite, had a new format, with a zero-row of data, and today's date.

This meant when I updated the database of time series data, I got tables where every series had a bogus, zero-valued most recent date.

It was 7:30 AM, and markets would open at 9:30. A bit of code inspection, and a simple fix: Update the MERGETABS function with two lines of code:

       ZEROROWS <- 0 = +/PNEW[;(1 downarrow iota 1 downarrow rho PNEW)]
       PNEW <- ( tilde ZEROROWS)/[1] PNEW

And this solved the problem. Update the runtime version of the workspace by changing QuadLX latent expression to start the GUI when the W/S is loaded, and roll out the new W/S to a few different boxes. All done before Mkt open.

The code above just takes the new table PNEW, selects the data columns, finds those that are zero valued and removes them using a boolean vector reduction along the highest dimension (the table's rows). Easy peasy. Done quick, and done right.

With my data updated and correct, I run some stuff against it, and get the courage to hold my positions - concluding it will be an up day, as the stuff I run helps me make that decision. I close the day up, just under $40,000 to the good. (Crazy day...)

And oh, btw, the APL stuff runs on both Linux and Windows boxes - and the Linux is both 32-bit and modern CentOS 64-bit. I still run the old 32-bit boxes because they are very fast and very reliable. The APL stuff runs on the Linux boxes under WINE, which works amazingly well.

It's old school stuff, but it just works. APL is the magic that lets me do the other magic, that pays the bills. I gather that K can provide something similar for big corporate environments, when the datasets and timeseries get crazy large. You can write anything in any language - but one must not lose sight of the objective, which is to make the business side of things work well. One can write APL - or any language - in a way that is unclear and confusing. But you don't have to do so. If you are careful, you can build APL solutions that are fast, easy to maintain, and smoothly flexible. Maybe this is possible in K as well?