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)
> Despite my head start with J, by the end of the conference I found APL code easier to grasp – J seems more extreme to me. Roger calls J “executable mathematical notation”, and I’ve always been a bit more of an engineer than a mathematician.
I found this too, when I tried them both, first J then APL, perhaps because:
* APL uses () [] and {} in their pairs to parenthesize things, just like other languages, while J uses the 6 symbols as standalones, harder to read the code.
* All verbs in APL are single characters, whereas J symbols might be more than one.
* J, unlike APL, uses the concepts of rank, and forks and hooks, which are both difficult to grasp and don't seem to add much to the array processing idea.
0+':x -> "sum each element with one to the left
(0 left of the first)"
1_x,0 -> "drop first, add zero at the end"
(0+':x)+1_x,0 -> "sum each element with the one
to the left and the one to the
right (sum of previous expressions)"
a:2{+...}/x -> "do that; transpose; do that;
transpose again, and assign to a.
2{}/ means 'do twice'"
At this point, "a" has the same shape of "x", but in every element is the sum of the elements of x from that location, one above, one below, one left, and one right.
4=a -> "1 where a=4, 0 otherwise"
x*4=a -> "1 where x is 1 and a=4, 0 otherwise"
a-x*4=a -> "decrease a from 4 to 3 if x=1 in the
that place"
3=a-x*4=a -> "1 where one has 3 neighbours"
So, if x is a 1/0 matrix "life x" does one iteration of Conway's game of life. And "1000 life/ x" would seek convergence or return to first state (but no more than 1000 iterations).
There is code golfing here; It would have been purely readable K code if it wasn't golfed. But it would also have been two to three times as long.
Compared to how different k/j/apl are from mainstream programming languages, c/c++/c#/java/pascal are all dialects of the same language.
You have to think differently when using them - an exercise well worth the effort. Much like Lisp, if you grok them, your code in any language will be much better.
And they are not new - APL goes back to the 1950's. K is the refined-for-practicality version, J is the refined-for-purity-and-mathematical-beauty version (but it IS practical; in fact, it drops APL's special graphic symbols which made APL more beautiful but less useful)
K's successor Q is used heavily in financial systems and costs a bomb. Despite all the big data rage these days, I think Q has been handling very high volumes of data for a while now with some amazing performance.
The 32-bit trial version of kdb+ is available for non-commercial use [1], so I went and downloaded it. The linux zip download is 278KB. Uh ok! I was expecting it to download more stuff (much like Chrome's installation), but nope, that's all there is to it!
I used K and KDB full-time from around 2003-2005. Very, very good performance, but very steep learning curve and some frustrating bugs, but getting quick direct support from Arthur helped a lot (even if his emails were frustratingly terse! ). What else do you expect from a guy whose email address was a@kx.com? It forced me to learn functional programming before it was "in". Once you got the way to think about vectors and functions over vectors you could be very productive chopping up big data in finance. Fun stuff actually.
Long time HN lurker...I've worked with kdb+ / k the last few years, it's in every major bank and is great for storing and querying market data. If you're looking for a nice GUI I use qStudio, it helps make it a little more friendly.
Then there are great tutorials on the code k website. It's a beautiful language full of unique original ideas.
Q (post-K) is really fast. However, the arrogance of the language design is really irritating. It's quite enjoyable to write Q as every working line of code makes you feel very clever. That's the biggest problem with it, though.
* Disclaimer: I maintained/wrote Q programs for years in a production environment. I'd never choose Q as a production platform again. It's fast but not because it's cleverly written, it's fast because it does not do anything for you.
It doesn't do much for you, true - but after using K for awhile I came to the conclusion that the vast majority of what other languages give you is not required.
Sort of like realizing that a lot of lawyers, finance people and even doctors do not actually provide society at large and even their direct customers any benefit (though having nontrivial cost), and the world would be a better place if there were fewer of them.
I came to a similar conclusion when programming using a hex editor and the x86 instruction set manual. Without having to clutter my mind with the abstractions other languages introduce I found I had a ton of free memory to reason about my code and handle much larger portions of code than I usually do. Also, by typing in data directly I avoided having to do the mental translation of thinking about what a compiler or interpreter would do to my code. Additionally, working directly with the data allows plenty of opportunity to write self modifying code to minimize memory usage and optimize program execution to avoid cache misses. I do all my programming in hex editors now and encourage junior developers at my company to do the same.
I'm sure this was supposed to be funny. But unlike x86 hex coding, people actually get stuff done in k/q - in fact stuff that runs faster and better than equivalent systems in C++ and Java. So the reduction ad absurdum does not, in fact, add to the discussion.
What are you talking about. I assure you we get a lot done at the office doing x86 coding in hex, and even more in MIPS due to the simpler instruction set.
Can you still find usable MIPS hardware these days? You're probably eschewing keyboards and monitors as well, and program $20 routers by toggling connections on their serial ports.
NumPy is an array oriented library/language too. Idiomatic NumPy usage is quite terse too. I can see how you can start with NumPy like syntax and then want something still more terse, but starting from K/Q seems quite hard.
It's more than just terser notation for numpy-style operations. Q (verbose K) reads cleaner than numpy code - closer to English, in fact, without giving up any speed. K is the terse mathematical notation for that language.
K has 3 types: atoms, lists, and dictionaries. (atoms can be int, char, float, symbol, time or function). No objects, no strings, not even files. And yet, it is enough to express many algorithms concisely and efficiently, with bugs largely reduced to the class of off-by-one family.
The syntax is not just a superficial aspect of the language - it is fundamental to its evolution.
"The final impetus that got J started was the one-page interpreter fragment that Arthur wrote, recorded in Appendix A of An Implementation of J [29] and also reproduced in Appendix A below. My immediate reaction on seeing the page was recoil and puzzlement: it looked nothing like any C code I had ever seen. (“Is it even C?”) However, Ken counselled that I should reserve judgment. "
I have a really hard time understanding what APL-likes are useful for. I guess I don't do a lot of stuff with big vectors, but I feel like it would be hard to structure code (maybe you don't need to?)
Well, it is very different - but if you have for loops anywhere, then K is probably useful for what you do. It's like reading/wriing Japanese kanji for an English speaker - it looks foreign, but it is equally capable and much terser.
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.