J and K remind me of the essay about the Lisp Curse[0], which mentions that the expressiveness of the language became a sort of Achilles heel in its culture. It talks about people writing their projects in Lisp and not expecting other people to adapt to their conventions or combine their efforts on one library, where every solution worked well enough initially - but only for one person, its author.

In K the error messages are far harder to understand than most languages, and you'd need either enough comments or many hours of experience with the language to understand what a piece of code does, due to its sheer expressiveness. Also, there's comparatively less documentation for when you're trying to do something practical. I can't imagine introducing J or K in an open source project will be helpful if other contributors have to catch up to my understanding of the language and need to internalize and remember which single-character symbols mean "print" or "iter." I imagine that at least a Python programmer could reasonably understand the gist of a similar Ruby program, merely due to the fact that "class" and "map" and "length" are sequences of characters that usually show up in both languages. Not so with K.

Still, I find the vastly different ways of doing things with K interesting to see, even if I will only use it personally.

[0] http://winestockwebdesign.com/Essays/Lisp_Curse.html