[nine_k]

> Does giving a K idiom a name make it clearer, or does it obscure what is actually happening?

There's a balancing act around that. It's called "abstraction".

At some point, you cannot afford to know 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.

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.

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).

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.

Also, I love this idea: «APL has flourished, as a DSL embedded in a language with excellent I/O. It's just got weird syntax and is called Numpy.» (https://news.ycombinator.com/item?id=17176147) The ideas behind APL / J / K are more interesting than the syntax, and haven't been lost.

[vintermann]

You certainly can do points-free programming in Haskell. It's the first place I ever heard of it.

Ironically, points-free programming in Haskell has a lot of '.' in it.

[the_af]

Haha, I never understood why the point-free (aka "pointless") form in Haskell actually is the form that requires lots of "."!

[tome]

"Points" means something like "elements". When you write

    \x -> f (g x)

you are defining a function that explicitly specifies how each "point" `x` is to be mapped. When you write

    f . g

you don't mention any point. You are abstracting away from the notion of point. That's why it's "point free".

[WillDaSilva]

I love the idea of using k as a DSL (domain specific language) for working on time-series data. Something like it would also be great for working on n-dimensional arrays, but unfortunately k doesn't really support working with them in any elegant or efficient way.

Python and Numpy would benefit a lot from having something like k to express vector/matrix operations elegantly.