It sounds like a total disaster, but after about two weeks (which is a long-ass time to learn a language), everything made perfect sense, and I really enjoyed using it for the rest of the time. It's very powerful and fast to execute, and after you get the hang of it, it's fast to write, too.
Also, I'm curious how their database stacks up: what's it better/worse at? It seems like magic for a program so small to do so much so well. I'd like to know what the tradeoffs are. (Either that or move to their universe.)
K is super-great at vector operations; element-wise addition between two lists of equal length, for example; more powerfully, mapping lists to functions.
The DB stuff we were doing were columnar databases, so it was incredibly fast at doing data analysis and correlations. Not so fast at adding single rows, but if you wanted to take a list of transactions and compare things day-over-day, or do sophisticated statistical operations, you simply had to write a line or two, and watch it take multiple million-element lists and give you an answer in milliseconds. I'm still pretty convinced it was voodoo magic.
When I used it, there was a pretty hefty license fee, but there's a trial version which limits the amount of memory it will use, but can still do quite a bit to give you a sense of the speed (as long as you're doing it right). Remember, no stinkin' loops!
I was kind of afraid you would say that. I wish they'd open-source it.
It's such a pity that Peter Seibel didn't include Arthur Whitney in Coders at Work. I suggested him, IIRC, but he didn't get in. As far as I'm concerned he belongs in the top echelon. Here is what Roger Hui, the J guy and no slouch, said (I love this story):
Someone once asked Peggy Lee who she thought was the best jazz singer. Her answer was, You mean besides Ella? Likewise, the answer to the question Who's the best programmer? is Besides Arthur?
Edit: maybe if I'd included that in my suggestion to Seibel it would have helped :)
Edit: It's like complaining that the Mona Lisa is a crappy painting, because you are insistent on looking at it as if you were a cubist. It's completely missing the point.
That is why mathematical formulas are written with x, y, and z instead of long names. The idea is that we are emphasizing the generic relations, not what might be fed to the function.
Similarly, when writing functional code it is good style to use single letters instead of long names.
I went through something like this hacking in Lisp, actually. When I started out, I used long descriptive variable names; it's the CL style anyway (MULTIPLE-VALUE-BIND, anyone?) Over time, I found myself using shorter and shorter names, to the point where my code is now of the sort that some of the commenters here would apparently fire me for it. Yet it's not like I somehow became less passionate about readable, clear code. What gives?
It took me a while to figure out. As programs get shorter (because the level of abstraction gets higher), the shape of the code itself becomes increasingly meaningful. (I mean the physical shape of the code as it appears on the screen.) This is doubly true of languages with very regular syntax like Lisp and K, and is a huge advantage to such regularity. Partly this is just that, since the program is shorter, more of it fits on one screen. But I think it's a deeper and more mysterious effect than that. You begin to develop an intuition for different patterns that have different semantics, as it were. Grokking these patterns becomes a big part of what you do when you read this sort of code. This effect is weaker in mainstream languages, so it's not surprising that people aren't aware of it. (Edit: although I used to joke that I could tell how good C# code was by printing out reams of it, hanging it on a wall, and stepping back 15 feet. That's an example of the effect too. It's just that in more powerful languages you don't have to step back 15 feet to see it.)
When you're working in a verbose language, long variable names are indispensable. You've got a whole lot of lines of code to read through, and a name like "x" does nothing to orient you as you switch contexts. But exactly the opposite is true of dense, concise programs. Variable names as long as even, say, "customerID" will dominate such programs textually, obscuring their natural shape. To increase overall clarity, you have to shorten those names to a length consonant with their semantic role. In other words, this style evolved not because people don't care about readability but because they are trying to maximize it. A convention like "one letter for local vars, two for global, and three for functions" is exactly the sort of thing that would help achieve this in a language like K.
Ironically, I have given a verbose expansion of what you just said:
Using single letters in a piece of code helps in outlining the structure, instead of the contents.[...] The idea is that we are emphasizing the generic relations
My excuse is exploratory writing: I've been meaning to write about this for a while to clarify how it works in my head. And I don't have time to make it shorter :)
I could, for instance, cut about 80% of my line count in the two Q projects I've open sourced if I used naming and spacing conventions as shown.
http://github.com/DannoHung/qutil http://github.com/DannoHung/qspec
[/Tooting Own Horn]