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.
[1] like look at this crazy shit http://www.nsl.com/k/ray/ray.k
* 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.
Like many historic languages, it's worth spending a little time with it. "Those who do not remember the past..." and all that.
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...
* Exploring Math
* Math for the Layman
* Arithmetic
* Calculus