The original Lisp in 1958 had only lists, by the 1970's many implementations already had all other key datastructures like arrays and hashes.

I strongly dislike this choice of using all the symbols that do not exist on normal keyboards. I can't stand this, seems very attention seeking. Why not choose normal thingies that can be typed using the main interface we have with computers? This makes me mad, even.

But programs written in K are so beautiful and terse they are unlike anything else I've seen. It feels like there is something about it we can't really comprehend, like this beauty could not be achieve by accident, like there is something fundamentally right there...like there is some fundamental truth here. And maybe this is true about APL also.

Partially reminds me (due to _V,_f,_F,f,F) Whitney's ksimple implementation[1].

[1]: https://github.com/kparc/ksimple/tree/main/ref#ac

I find such "X in Y lines of code" challenges not very interesting most of the time, because, as it is the case here, they usually just pack multiple lines into one instead of using clever tricks, from one of the lines in that file:

> right, left = lambda f: lambda x, y: list(map(lambda yi: f(x, yi), y)) if not atom(y) else f(x, y), lambda f: lambda x, y: list(map(lambda xi: f(xi, y), x)) if not atom(x) else f(x, y)

I still consider jax.vmap to be a little miracle: fn2 = vmap(fn, (1,2)), if i remember correctly, traverces the computation graph of fn and correctly broacasts all operations in a way that ensures that fn2 acts like fn applied in a loop across the second dimension of the first argument (but accelerated, has auto-gradients, etc).

It's a fun article and this really doesn't matter much but `5{|+\x}\1,2` does not give the typical fibonacci sequence. Either `5{|+\x}\1,1` or `5{|+\x}\2,1` do, if the results from this random online interpreter can be believed (https://ngn.codeberg.page/k/#eJwzra7RjqmojTHUMQQAFyUDkw==).

    5(|+\)\1,1

Nice article. Some passages have LLM smells (short sentences. No em dash but smells of em dashes). I wonder whether this comes from having an LLM improve the English formulation/typos/etc. I don't like the way how LLMs typically write. One can steer it to certain degree with a longer prompt, that's my impression.

Broadcasting is a great thing, but the author of this article missed the most important example of a language that handles higher order funcions, as well as broadcast and array operations as well.

That language is Julia.

The approach in the article layers an inefficient interpreter in a slow interpreted language. The result is going to be terse (and nearly unreadable) but glacially slow. Julia, otoh, is a high performance language.

An example of this performance with higher order functions is this implementation of cubic splines in 7 lines of readable code. The idea is to implement interpolation between points and functions and then define first, second and third order splines in that many lines of code. This isn't quite as terse as it would be in APL, but it has the virtue of compiling into code that runs as fast as a native C implementation.

``` import Base.+, Base., Base./

+(f, g) = x -> f(x) + g(x)

(t::Number, g) = x -> t * g(x)

interpolate(a, b) = t -> (1.0-t)a + tb b1(p1, p2) = interpolate(p1, p2) b2(p1, p2, p3) = interpolate(b1(p1, p2), b1(p2, p3)) b3(p1, p2, p3, p4) = interpolate(b2(p1, p2, p3), b2(p2, p3, p4)) ```

See https://discourse.julialang.org/t/seven-lines-of-julia-examp...