Re: Literate Executables

[Tim Daly]

Java code has the pseudo-ability to re-generate the original source

through decompilation. Unfortunately given the size of any executable

it would be years worth of work to reverse-engineer the understanding

without explanation. I struggle to even understand the traceback of

any Java failure :-)

Open source, by definition, already has the source available.

Only the URL of the github repository and the hash number corresponding

to the current executable is needed.

I haven't worked for IBM since 1995, the year IBM Research eliminated

the math department, including me. My ground-breaking work in Artificial

Intelligence has yet to be cited by anyone so their decision was probably wise.

Tim

On Sat, Dec 3, 2022 at 1:01 AM Terence Kelly <tpkelly@eecs.umich.edu> wrote:

Hi Tim,

Your observations seem sound.  Keep in mind, however, that we're not
confronted with an either/or choice.  The chicken/egg aspect of literate
executables means that, in your context, we can arrange for the PDF to
generate code *and* for the code to generate PDF.  Cyclic dependency
graphs take some getting used to, but one can learn to love them.

If literate execution isn't right for Axiom, perhaps it can benefit other
IBM open source projects.  If you circulate the paper among your
colleagues I'd be interested to see if they find useful applications.

_Queue_ readers are remarkably creative and routinely find uses for Drill
Bits ideas that I never anticipated.  I wonder what your colleagues will
come up with.

Thanks.

-- Terence


On Fri, 2 Dec 2022, Tim Daly wrote:

> ...
>
> The above considerations leads me to the conclusion that the PDF is the
> thing that generates code rather than the code generating the PDF.