> This sounds really interesting!

Cheers!

> I'm happy my article was helpful to you.

It was just the thing! Very helpful. Thank you for writing it.

> I really like how your notebooks integrate (judiciously chosen)
execution trace display with explanation. I think this is something
literate programming benefits a lot from.

Cheers again. I find those traces aesthetically pleasing in and of
themselves. I can imagine a (strange, niche) art gallery that had large
prints of them on display. Jupyter notebooks have so many good things
going on. (Not that they're perfect, but they hit a sweet spot IMO.)

> I wonder if there's a way to include a smooth gradient from specific
examples like your V('80 P') to more general cases, either with abstract
interpretation or a Bret-Victor-style overwhelming battery of data
points.

I'm sure there is, there are so many possibilities. Just the traces
alone could be animated or made into (partial) graphs (have you seen
http://pythontutor.com/ ?)

Concerning abstract interpretation, if you squint a little,
the Prolog code already does that. Markus Triska suggested using the
CLP(FD) integer constraints for the math primitives, which was brilliant,
so it's doing a kind of abstract interpretation. You can give it a
completely general stack "type" (just a logic variable) and it will tell
you, e.g. '+' is:

int(A), int(B) -> int(A+B)

and so on. It's also pretty easy to replace the main operators to get a
different (but related) semantics, and I'm pretty sure that relates to
what Conal Elliot's "Compiling to Categories".

I'm not sure which Bret Victor thing you're thinking of, but it's easy to
do things like evaluation over a domain (rather than a single value), or
partial evaluation (again with specific values, domain, or logic vars.)
And you can do that trick where you give it the result and ask it to
generate programs (as in http://webyrd.net/quines/quines.pdf) and
variations on that. I think it would also be easy to e.g. add slider
widgets and have them evaluate expressions (possibly already partially
evaluated for efficiency) when the user "sweeps" them.

Also, and this is more hand-wavey, I think there should be a way to use
the traces to extract information about how programs unfold over time.
What I mean is, the traces typically have clear initialization and
completion phases with a loop or recursive function in between, those
repetitive parts show up clearly in the traces, and it should be possible
to overlay them on each other and find the static vs dynamic terms, and
maybe do something with that information. (Unroll loops or create new
versions that do less work or whatever. Hand wave.)

> I watched an Aaron Hsu talk from Functional Conf not long ago where he
claimed that Co-dfns has a comment-to-code ratio of 400:1 or something,
because his dissertation is the comments, and there are several pages of
it per line of code. Having seen the glyphs in the talk, I haven't dared
to open the dissertation yet; I'm afraid it may open a gate, causing
cenobites to come out of xpdf.

Heh heh heh. Yeah, that makes sense if you're working in a system that
allows for easy refactoring: code should approach the Kolmogorov
complexity limit of the problem it solves as it ages, eh? Ripen instead
of rot.

> I really like RPN calculators because of their immediate feedback —
http://canonical.org/~kragen/sw/dev3/rpn-edit is one keyboard-driven
prototype with a structure editor —

Okay that is freakin cool. I'm probably going to have steal some ideas from
that if you don't mind? I like the idea of being able to edit and
re-evaluate sort of like a spreadsheet. And making the structure of the
expression visible like that seems like it would be very useful.

> but I think that while they reduce the gulf of evaluation, making it
easy to see if the step you just took was the right step, they may expand
the gulf of execution, making it harder to figure out what you need to do
to get closer to your goal.

> An extreme version of this, which is not RPN, is

InputStream s = foo();
return new BufferedReader(new InputStreamReader(s, Charsets.UTF_8));

> where it takes considerable familiarity with java.io to immediately know
how to get a BufferedReader given only an InputStream, because of the
intermediate step via an InputStreamReader.

That's where Joy seems to shine, it's been pretty easy so far to set up
the context for a function I want to write and then derive an
implementation in a kind of mathematical way.

> Today I was thinking about the cisco IOS CLI described in
https://news.ycombinator.com/item?id=22498665#22500151 — something I
haven't used in a long time — and it occurred to me that LOGO or REBOL is
close to being FORTH or Joy spelled backwards. Instead of reverse Polish
notation, it's forward Polish notation, enabled by all the functions
having fixed arity. So, if you're writing left to right, you write your
code top-down, as in C or bash, instead of bottom-up, as in Smalltalk or
FORTH. You've built a noun-verb system, like the Macintosh, while Unix
and IOS verb-noun. Is one or the other globally more usable? I don't
know! The Java above is hard for programmers new to Java to write, but
it's verb-noun.

> One thing that has occurred to me is that in purely functional
contexts, in a verb-noun system, it might be reasonable to execute every
type-applicable operation and display the results, maybe as a balloon
next to the operator name; then the user need only select which of all
the possible next states they want to go to. So, for example, if you have
two numbers on the stack, you might have their sum, their difference,
their product, their quotient, and the results of dup, drop, and swap,
each displayed next to the relevant operator; then you can select the
desired operator to go to that stack state. That seems like it might help
with the gulf of execution, providing you with one step of lookahead. But
maybe it would be more distracting than helpful?

I had that idea too. The Prolog code does that anyway to type-check (the
interpreter is also the inferencer, because Prolog is awesome that way)
so there's no reason to throw the result away rather than display it
somehow. But with infinite undo you've got that tree of possible
evaluation already, eh? It comes down to ergonomics.

> But then, you could imagine doing the same thing with a verb-noun
system, as long as all the arguments have reasonable default values so
that you can somehow get useful visual feedback on the results even
before you have chosen all the arguments; for example, for arithmetic
operations like that, the default value might be λx·x, the identity
function, so that you see graphs of all possible results.

That would be pretty cool.

> I used to chat with Slava when he was first working on Factor (before
he started working at Apple)

That's cool! :-)

> but I'm embarrassed to admit I've never actually tried Factor. (Or
Joy!)

Heh, me neither. I want to use it just because it's so cool.

> Is there a screencast of the hypertext features you mention?

Dunno, but you can just download it, fire it up, and click "Help". It's
nothing fancy, just a little mini-browser with hyperlinks.

> What do you think about Cat?

I looked at it when I first started with Joy but it wasn't quite right
somehow. Slightly too complicated, or wrong emphasis or something, I
forget.