I had to write a lot of K at university (thus disclosing where I went to, and confusing people that have written any K with the idea you could possibly write a lot of it).
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.
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. :)
Mostly. Mona is k2/k3 (described in this post). K4/Q is much much cleaner - so it is easier and preferable in my opinion. You can get a free(gratis) 32-bit interpreter of that to play with; but if you insist on free(libre), kona is acceptable to dabble in. There's also J, which I think prefers purity and mathematical aesthetics to practicality, that you may like.
(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.