Anyone planning to read anything interesting and future of code adjacent this weekend?

I mean, my particular FoC interests are quite visual in nature, and so I'm just picking up WebGPU now that it's about to ship in Chrome. So for a certain perhaps stretched definition of "FoC adjacent", I'll be reading webgpufundamentals.org (by @gman) and perhaps some stuff about ray tracing. You?

I’ve been going down an APL rabbit hole, lately…so, maybe that.

Ah yes, Apple. Good programming language, that. (Sorry — reference to next month's episode. Just hide it under your hat.)

@Eli Mellen I’d like to learn more about your APL weekend — what are you reading? Did you find a good resource that talks about an APL implementation (apart from the original Iverson papers)?

@Stefan I haven’t read anything about implementations, but I have looked at the few open source ones I’ve run across and found those pretty interesting. • Kona • oK • lil (embedded in the larger decker project) • bqn I’ve also found the J wiki and the kdb+ and q websites really helpful.

Also interesting in my opinion: APRIL, an APL dialect embedded in Common Lisp (https://github.com/phantomics/april). I see APL more as a DSL, so it makes sense to embed it into a wider ecosystem.

I can see why it comes across as a DSL, but I’m mostly interested in it for its fundamental design around arrays as the primary data structure. Kind of like Lisp with lists. Commercial implementations ride on that wave because it gives them interesting ways to optimize for parallel execution. But I think it’s an interesting design decision to basically treat everything as a collection and kind of look at a single scalar as an “exception” and design a language around that.

Arrays as a primary data structure are interesting indeed, but the problem of the APL family has always been that arrays are its only data structure (in contrast to Lisp, that has other data structures besides lists). Nested/boxed arrays were a big step forward, but they remain limited and, together with the weak abstraction facilities, make APL a pain to use for many tasks. Add to this that typical implementations don't care about interfacing to the rest of the world, and you easily trap yourself in an island that is fascinating but limited. However, as you say, the notion of plain values being a special case ("rank 0") of a uniform collection type is interesting and pratically relevant. It's what makes it difficult to implement APL ideas in other languages. This has been the main struggle in the early days of Numerical Python, when we tried to make Python scalars work as rank-0 arrays (and mostly failed). Later NumPy versions introduced its own scalar types for that reason, which have then been an eternal source of confusion for many users ("why is an element of a float array not a float?").

k has dictionaries, and derivatives like Kerf even added tables as first class constructs. Also Russ Cox solving the advent of code using ivy is pretty interesting…

Thanks! I haven't played with K yet, nor any of its derivatives. And Ivy looks interesting as well as a pragmatic tool that makes APL more accessible in a command-line environment.