Presumably it’s one of those things where if you find yourself writing a lot of code, you really ought to question what you’re doing?
> Your code ends up super dense, with non-trivial stuff easily fitting on just a few screens, so you can keep track of what's going on.
I have found it really difficult to convince people that the latter follows from the former—that denser notations actually make code easier to grasp, as long as you know the notation. The farthest I’ve gotten is: “Look, in a language that rhymes with Slava, you often have to write an enormous amount of code in order to accomplish anything and keep it maintainable, right? Well, there are languages even better about that than the ones you use.”
You may be interested in concatenative programming, a cousin of tacit programming. Factor (http://factorcode.org/) is a good dynamic language with a great environment and helpful (though quiet) community in #concatenative on Freenode. I am working—alas, very slowly—on a statically typed concatenative language and hope that it will one day help take these ideas to the mainstream. :)
ps: just in case here's a very enjoyable talk, not about, but by Slava http://www.youtube.com/watch?v=f_0QlhYlS8g Beautiful and impressive.
(J is a different language; both J and K can be traced back to the origin of A, a 20 C line implementation of an APL dialect)
Get by the symbolic confusion (Arthur himself used to respond to confused students on the mailing list about such things) and it's really quite inspired. I can appreciate how an APL with proper symbols would be properly productive. Your code ends up super dense, with non-trivial stuff easily fitting on just a few screens, so you can keep track of what's going on. (KDB itself, the commercial column based DB product built with K, was notoriously small for the functionality). The real pain I seem to recall was interfacing it with anything else, but the entire environment is tiny.
This is one of those languages that really expanded my mind and made me hope the rest of the world would one day revisit the ideas of the APL family.