Golfing APL/K in 90 Lines of Python

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

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

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

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