I used K professionally for a bit. The people who love it dearly love it, and it is exceptionally great for any type of linear algebra or relational database problem. One of the interesting insights I was made aware of: in K, the slowest operation is usually no more than an order of magnitude slower than the fastest. Since all of the operators are 'approximately the same speed' it's much easier to reason about a program's performance. It's also the reason K programmers obsess over the character length of a solution, often the shorter solution is the faster one.
On the downside, I found K to be very polarizing with respect to interoperability. There is a K way to do something and 'the other ways,' and attempting to bridge the gap leads to a lot of headaches. Part of it is that K is so good 'inside' that not as much effort is given to interacting outside of that world. The K programmers I know are aware of this, and I think this is more of a critique on the size of the community rather than its mindset. They're focused on solving actual problems rather than the gardening involved to keep the language friendly.
One nice thing is that K programmers tend to be higher up on the intelligence side of things[1], so if you meet someone who knows it you're probably in for a great conversation.
I think J and K are both worth learning; I find K more practical* , but J has many brilliant ideas buried in it. Whether or not you go on to use either directly, each will add a lot to your mental problem solving vocabulary.
* K allows "ragged arrays" (not every row has to be the same length), seems to favor pragmatism over mathematical purity, and is more of an APL/Lisp hybrid.
q (the current commercial K) has a restricted demo available at kx.com, and there's also Kona (https://github.com/kevinlawler/kona), an open-source clone of an older version of K. (disclosure: I'm one of the developers.)
There's tons of J tutorials and documentation at http://jsoftware.com/ (in particular, I recommend "J for C Programmers", http://www.jsoftware.com/help/jforc/contents.htm), and Håkan Kjellerstrand has a great collection of k/kona resources (http://hakank.org/k/). The "K user manual" and "K reference" links on the wayback machine are pretty close to the K version Kona implements.
But I've found that trying to use it for most things just isn't worthwhile. It feels like cheating every time I have to escape from its array programming core to the more familiar flow control structures that only came along in later versions of APL.
I think it makes a good puzzle language (i.e. the fun comes from figuring out _how_ to say something rather that just raw getting stuff done), but unfortunately, it's even more of a puzzle to figure out how code that someone else wrote works.
For full context: I've spent more time using J than APL itself.
It's an iconic language, full of sheer appalling genius (over-striking on printing terminals to get the special characters, for instance). It has bunch of interesting ideas, some of which have been stolen and bettered in more recent languages.
Like many historic languages, it's worth spending a little time with it. "Those who do not remember the past..." and all that.
I (partially and badly) learned APL while in high school in the mid-'70s, mostly because I liked being perceived as a weirdo with reams of pages bearing symbols nobody else could decipher. (If you're going to be different and noticed, might as well make a party of it, right?)
Much later, I found myself working with Lotus Notes as part of my programming duties. The main programming facility, Formula Language (a macro language that looked a lot like 1-2-3's cell formulas) had no loops (at the time; they've been added since) and only a hybrid if/switch construct for control. WTF? It took quite a while by my time scale, but I eventually realised that it was a conceptual descendant of APL, but with odd language tokens (in that you could actually read them). Once I relaxed into "everything's an array, and all operations are array-wise" mode, I was continually amazed at how much I could do how quickly with how little code.
When the paradigm is right, it's right. But when it's wrong...
It's worth it just to get a different view on how to solve problems. In this world of multi-cores I get the feeling that some of the perspective APL gives a person will come in handy.
APL was the first language I learned - I had a very interesting and forward looking Engineering Professor who taught us how to solve complex systems of equations using APL. I loved it, and am sorry that I don't use it anymore.
IBM APL2 was the 3rd or so language I learned. At Merrill, I remember workspaces with tens of thousands of LoC, possibly over 100K. Also we used to have "each" contests and obscurified APL contests, where nobody could read anybody else's code
Just browsing through I'd say an introductory course in linear algebra and one in discrete mathematics should be enough. I'm not an expert on mathematics or APL so take my advice with a grain of salt.
