More actions
Inaft began as a quasi-literate program. What affordances can we provide to make the triple script ecosystem a really top-notch environment for literate programming? Even if trplkt and the dialect don't evolve "far enough" in that direction, our focus on accessibility can surely lead to at least a 10x increase over today's status quo in literate programming.
Start with Knuth, but then keep Kartik's comments in mind.[1] A lot of the other attempts at "literate programming" systems I've seen fall short in worse ways than Knuth's. (And on that point, Mu is meant to be a teaching system, but if that's really true, then the use of C++ instead of targeting the world's most successful hypertext system can't be defensible, can it?)
Bob Nystrom's Crafting Interpreters build system detailed in Crafting "Crafting Interpreters" is also highly apropos. I've been thinking for a long time that dynamic languages' super powers could be applied to great effect when directed at the problem of literate programming.
One thing I want from a literate programming system is the ability to preface the implementation of something with some comments demonstrating the use case—the problem whose solution is forthcoming—and then the system should be able to automatically extract those bits and feed them into the test system. Similarly, it should be trivial to turn offhand comments about the way the code works into falsifiable assertions that can be verified by machine (and thus killing the excuse that there are no comments because of how hard it is to make sure comments don't go out of date).
And literate programming is the use case for continuing to permit arbitrary imports—right now we put them at the top of the file by convention, but there's an argument to be made, probably, e.g. to put them at the bottom of the file, or interspersed throughout. (XXX Would it be kosher for static imports to appear within a given method definition? In any case, we'd need to wait until trplkt dumps the partial parsing strategy, and even if it is a problem according to TC39's rules, we can always work around it, depending on whether we're willing to push that far out on This is not JS—and we probably do want to, eventually, whether for this or for something else.)
2020 September 29: In any case, regardless of what happens with the above, triplescripts.org needs to strive to "scrutability". I read Knuth once (XXX it was in Coders at Work) mentioning being in the hospital or something and having a printout of the listings of someone else's programs and having read through them. This seems quaint. Golang doesn't value this highly enough. (Imports and packages are a big departure from Oberon and too much like C where you don't know where to look for anything unless the programmer is really empathetic—you can argue that good programmers shouldn't be constrained/punished by rules meant to reign in the bad ones, but there are *so* many bad ones—where "bad" means inability to get outside their own head and therefore includes many "good" programmers. cf mantras about constraint and restraint)