Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Golfing APL/K in 90 Lines of Python (aljamal.substack.com)
78 points by aburjg 13 days ago | hide | past | favorite | 18 comments




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

The August-1962-dated Lisp 1.5 Programmer's Manual already describes arrays. (Biblically correctly zero based.)

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


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 think the challenge was actually to do something like Whitney style C in Python, doing it in under 100 lines was more a part of the metric than the goal. I am not sure I would call it a success but I don't know Python well enough to judge.

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


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

If one is golfing, tacit would be tidier:

    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.

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

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.


APL predates ASCII by a couple years.

It originally wasn't even intended as a software language, but rather a uniform mathematical notation in the style of curry's combinators, but more practical for describing non trivial algorithms.

So he was in an era where the expectation was if you were typesetting a mathematical monograph you'd already be doing stuff like swapping the balls on your IBM typewriter for math symbols.

It's not a choice you'd make today obviously, but it was entirely reasonable then.

As for why it persists, simple answer is APL fans like it that way. It's trivial to translate to some ascii text representation. I think anyone strongly motivated to do that just switched to j, k, or if even those are two weird goes to numpy or such.


>It's not a choice you'd make today obviously, but it was entirely reasonable then.

More recently, BQN made this same choice and I think it is perfectly reasonable to do as long as you have a reason beyond simple aesthetics. Entering these symbols on a normal keyboard is not difficult and no different from learning a human language which uses a different alphabet than you keyboard.

Personally I find the custom symbols of APL and BQN to be easier to type and read than the ASCII of J and K.


>So he was in an era where the expectation was if you were typesetting a mathematical monograph you'd already be doing stuff like swapping the balls on your IBM typewriter for math symbols.

makes sense, maybe that would be more ergonomic to type for the public it targeted, indeed.

i won`t deny it is a stupid take of mine, but it makes me mad. i get the same feeling reading mathematical notations, so there is that.


> i get the same feeling reading mathematical notations, so there is that

the natural habitat for encountering novel mathematical notation is while furiously handwriting your own lecture notes, trying to keep up with whatever never before seen hieroglyphics and squiggles that the professor is introducing on the fly while banging out the details of an alleged proof across the blackboard


To be fair, even after reading the other guy's post, I'm still mad about it. They even sell APL keyboards now. The indignity.

> Why not choose normal thingies that can be typed using the main interface we have with computers?

Iverson answered this in his Turing Award acceptance lecture, which is literally linked in OP's article: https://www.eecg.utoronto.ca/~jzhu/csc326/readings/iverson.p...

You're free to disagree with him, but you need not wonder why!


thanks for the reference, appreciated



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: