Your dercuano looks pretty awesome. I skimmed the PDF so far. :-) I have to be careful with stuff like that or risk being "nerd sniped" and spending the rest

Your dercuano looks pretty awesome. I skimmed the PDF so far. :-) I have to be careful with stuff like that or risk being "nerd sniped" and spending the rest of the day doing something other than what I had planned, eh? In re: visualizing program behavior I look forward to implementing something like an SVG rendering of the dataflow diagrams implied by Joy expressions. It would be easy enough to use Dot but I want something more like the railroad diagrams that e.g. git history tools often have for visualizing branches. Long ago there was a wonderful website that showed 3D dataflow diagrams (hand-drawn I believe) that had recursion as data lines that went backward to earlier stages in the computation. (IIRC the demo was the GCD function.) I lost track of that, but there's a guy working on "generalized arrows" (in the Category Theory sense) that has something very similar. In any event, the train yard would be static with data/cars flowing through it. I don't know much about category theory or Haskell either, but in this case I kind of stumbled across the same thing, I think. I was writing a type inferencer in Python of Joy, and I realized I could use the stack effect comments as the stack itself, and just execute combinators, and that got me most of the way to full inference (it's still incomplete: looping generates one type per loop iteration, etc.) In a nutshell, the point-free style allows you to swap out the categories that your expressions operate over very easily, and get multiple meanings: diagrams, circuits, types, values, incremental re-evaluation, and so on, from one expression. In re: the quine gen, yeah I haven't tried it out much yet but the Prolog version of Joy can do that with "iterative deepening". I'm more interested in auto-generating and testing new semantics for existing functions that give greater performance. I appreciate the beauty of quines but I want self-tuning. I actually got into logic programming from studying a Kanren in Python implementation a few years back. Now you can also implement Prolog in Lisp, so I won't quibble about power, eh? I like Prolog. I found that embedding (imperative, functional) Joy into Prolog was so elegant and so powerful that that, combined with the research on compiling with it, turned me into a complete Prolgo fanboy. So I'm biased. But in general I think it makes more sense to work mostly in the logical paradigm and only "descend" to the more imperative paradigm when the shape of your problem requires it than to camp out in imperative land with mere excursions to the realm of pure logic. > Bjoern Hoehrmann's parselov takes such an approach to the problem of parsing context-free grammars, for example. (For better or worse, his favorite logic programming language is SQL.) Ha! That's awesome! I'm going to have to look into him. You probably know that the relational model is the same as the logical relations that Prolog models, eh? In other words, SQL is Datalog, more or less. > A difficulty I have with the programming-as-Kolmogorov-compression approach is that, at least in the case of Co-dfns, it didn't really speed up the process of creating the software; in fact, it slowed it down. I think you'd have to ask arcfide to estimate how long it would take to write Co-dfns again. It sounds to me like he bushwacked through a lot of conceptual ground that hadn't been explored before. I have just enough experience reading Joy code to credit the APL people when they say they can grok a page of line noise, the Forth folks report the same thing. "Intuitive" means "familiar" in computers (Jef Raskin.) I agree that ease of understanding beats mere compression of code. Thank you too! This has been great.