Co-dfns Live Stream: Compiler Design and Architecture

What use is Chinese for someone who doesn't read Chinese? The S combinator written like that is perfectly legible and fine for someone who is already familiar with the S Combinator. I don't see the problem there and I don't already grok the S Combinator. I do appreciate writing code under the assumption people working on the code would have some level of prerequisite knowledge. I'm sure you'd get a kick out of Co-dfns [0]. But once you learn to "speak" APL programming it makes a lot more sense. I'd highly recommend, if you have the time, to listen to the author explaining the code for the compiler [1]. [0] [LINK] [1] [VIDEO] / HN discussion: [LINK]

One of the most memorable and interesting things I've ever seen on HN was an AMA from the creator of the Co-dfns parallel APL compiler. Here is co-dfns [0] and the AMA by the creator [1]. The video may give you some insight and at the very least may be extremely interesting to hear the APL code explained (jump to around 13:30 for the beginning of the explanation behind the structure + what the compiler is doing). He explains it very well - it's quite easy to follow along. [0] [LINK] [1] [VIDEO]

Nothing has ever convinced me about the potential for array languages in practice quite like watching Aaron Hsu describe how he develops his parallel APL compiler [0] using two Notepad.exe windows side-by-side: [VIDEO] He has also written many comments (arcfide on HN) about this stuff before, e.g. discussing "semantic density" [1] > The compiler is designed so that I can see as much as possible with as little indirection as possible, so that when I see a piece of code I not only know how it works in complete detail, but how it connects to the world around it, and every single dependency related to it in basically one single half screen full of code (usually much less than that) without any jumps, paging, scrolling or any movement. [...] The idea of semantic density is critical to this point. The semantic density of the APL code I'm using to solve the problem is at a certain rate. I maintain a consistent density rate by choosing my variable names in such a way that they visually align with the expressivity per character of the built in primitive symbols. And > [...] idiomatic programming methods that are so concise, they can begin to be read as we read and chunk English phrases. By doing so, it becomes actually easier to just write out most algorithms, because the normal name for such an algorithm is basically as long as the algorithm itself written out. This means that I start to learn to chunk idioms as phrases and can read code directly, without the cost of name lookup indi

I thought the same about APL until arcfide made a video about codfns a few years back. Was eye opening. [VIDEO]

I remember being floored by APL few months ago when I learned about co-dnfs and watched the stream by Aaron Hsu [1] with quotes like "This code is perfectly readable, it just isn't in English". Thing is, when I was thinking about trying it, I never figured out a good toy project. Like, when I wanted to try anything else, most of the time I would know I would be able to cobble together a web-service. Haskell, Erlang, even Prolog. I understand co-dnfs to be self-hosting, so maybe a toy programming language? [1] [VIDEO]

Old Forths with block-based I/O used 64/16 (so that definition takes ≤ 4096 bytes and fits into disk block). Makes no sense in the modern world of course, but, in the context of block editors, it creates a development environment where making complex and bloaty word definitions is actively discouraged -- an idea that Aaron Hsu briefly mentions in his APL talks [1]. [1]: [VIDEO]

Thanks for the link! I just found the one I was thinking of, which is older but perhaps goes into more detail: [VIDEO] .

Possibly related(ish): video about co-dfns, prompted by a previous HN thread (links in video summary), not written in C but put together in a similarly dense style: [VIDEO]