> <i>Does giving a K idiom a name make it clearer, or does it obscure what is actually happening?</i><p>There's a balancing act around that. It's called "abstraction".<p>At some point, you <i>cannot afford to know</i> what's actually happening. If you try, the entire problem won't fit in your head. So you cut the thing you're working with to a name and an interface, and forget what's "actually happening". You do that right in the K code, because you e.g. cut your understanding of `/` to "fold the array with the preceding operation", and totally don't think about the way it's implemented in the machine code.<p>This, of course, does have a cost; the simplest case is inefficiency, worse are circuitous ways to arrive to logically the same result, when a much simpler way exists.<p>I'd argue that `/` or `+` are very much names, of the same nature as `fold` or `add`, just expressed shorter. So if you prefer point-free style, you can likely do a very similar thing in, say, Haskell (and some people do).<p>I'd hazard to say that APL and J are DSLs for array / matrix numeric code. They allow to express certain things in a very succinct way. What APL traditionally had, mmm, less than ideal experience was I/O, because the language is not optimized for the branchy logic required to handle it robustly. K is a next step that allows to escape into "normal-looking" language with long names, explicit argument passing, etc when you feel like it.<p>Also, I love this idea: «APL <i>has</i> flourished, as a DSL embedded in a language with excellent I/O. It's just got weird syntax and is called Numpy.» (<a href="https://news.ycombinator.com/item?id=17176147" rel="nofollow">https://news.ycombinator.com/item?id=17176147</a>) The ideas behind APL / J / K are more interesting than the syntax, and haven't been lost.