Co-dfns

My YAML loader[0] is a condensed example of the architecture and techniques I'm thinking of. It's a couple years old, so the code is dirty by my current standards, but the couple of times I've gone back to read it, I have found the YAML-specific concerns to be quite salient. That said, it's specifically written for an audience that is familiar with YAML detail in particular, parsing more generally, and of course APL expressions of ideas. In fact, that is a big part of what makes the code readable and maintainable: it is optimized for communicating to the expert worker not for on-boarding new developers. The latter is more appropriately handled via other means IMHO. The poster child for this style of APL is Co-dfns[0]. It's a production APL compiler and a much larger example of the code I'm talking about. The entrypoint to read is cmp/PS.a

> Array programming is similar to functional programming – the primary way to control execution involves composition of functions – but APL tends to encourage the reliance on global properties and sweeping operations rather than low-level recursion4. This AoC solution is, indeed, quite the functionista! Better yet, it leans heavily into point-free expressions. The style is pretty popular amongst APL language enthusiasts and puzzlers. That said, you actually see quite different APL styles in the wild: - Pointed declarative style, also a popular with functional programmers (e.g. anything like this[0] from the dfns workspace) - Imperative, structured programming, very common in legacy production systems (e.g. this[1] OpenAI API interface) - Object-oriented, also common in somewhat newer production environments (e.g. the HTTP interface[2]) -

> Can't really do that as easily in APL. This doesn't match my experience at all. I present you part of a formal language over an AST, no cover functions in sight: p⍪←i ⋄ t k n pos end(⊣⍪I)←⊂i ⍝ node insertion i←i[⍋p[i←⍸(t[p]=Z)∧p≠⍳≢p]] ⍝ select sibling groups msk←~t[p]∊F G T ⋄ rz←p I@{msk[⍵]}⍣≡⍳≢p ⍝ associate lexical boundaries (n∊-sym⍳,¨'⎕⍞')∧(≠p)<{⍵∨⍵[p]}⍣≡(t∊E B) ⍝ find expressions tainted by user input These are all cribbed from the Co-dfns[0] compiler and related musings. The key insight here is that what would be API functions or DSL words are just APL expressions on carefully designed data. To pull this off, all the design work that would go into creating an API goes into designing said data to make such expressions possible. In fact, when you see the above in real code, they are all vari

My YAML loader[0] is where I first broke through the wall. It's still languishing in a relatively proof-of-concept state but does exhibit the basic design principles. There's also a Metamath verifier that does parallel proof verification on the GPU. It's unpublished right now because the whole thing is just a handful of handwritten code in my notebook at the moment. Hoping to get this out this month, actually. A DOOM port is bouncing around in my notes as well as a way to explore asynchronous APL. I'm also helping Aaron Hsu in his APL compiler[1] for stuff adjacent to my professional work, which I can't comment on much, unfortunately. Et hoc genus omne [0]:https://github.com/xelxebar/dayaml [1]:https://github.com/Co-dfns/Co-dfns

What a perceptive question! Learning boring technology and invisible infrastructure definitely can pay dividends. I don't think it's worth learning in isolation, but if you also engage in the relevant communities (think mailing lists, in-person conferences, company events, etc.) then the effort pays good dividends IME. I'm a bit biased, but I recommend looking at APL[0]. For one, it has a legacy almost as old as COBOL, with large pieces of European infrastructure running on the language. At the same time, it's cutting edge in both performance and the software architecture principles it encourages. Heck, APL even runs on GPUs these days [1], boasting a solid route for learning modern GPU programming as well. Also, the company behind the leading APL implementation these days, Dyalog[0], has some of the friendliest outreach around, and their