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.