Thanks for the kind words! I&#x27;m particularly gratified that you found the literate&#x2F; subdirectory. There&#x27;s some details about it at <a href="http:&#x2F;&#x2F;akkartik.name&#x2F;post&#x2F;wart-layers" rel="nofollow">http:&#x2F;&#x2F;akkartik.name&#x2F;post&#x2F;wart-layers</a>, but it sounds like you understand the point already so I&#x27;m preaching to the choir :)<p><i>&quot;What kind of things have surprised you about Wart during development?&quot;</i><p>I stopped working on wart at some point for two reasons. First, I realized that I was falling into a blind spot shared with many contemporary programmers: blindly assuming that the way to improve the state of programming was by creating a new language. But there is more to programming than languages. Languages just happen to be memetically tempting sirens to chase after. Second, I painted myself into a corner with wart because I made it <i>too</i> late-bound, so late-bound that it was incredibly inefficient and so hard to optimize. (I think it might still be possible, but I lost patience partly because of the previous point.) I still like my infix scheme and have a particularly soft spot for the way wart allows keyword arguments anywhere in any function call. See, for example, the use of <i>:from</i> in a webserver implementation that makes everything so much clearer: <a href="https:&#x2F;&#x2F;github.com&#x2F;akkartik&#x2F;wart&#x2F;blob&#x2F;ce64882c69&#x2F;071http_server.wart#L17" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;akkartik&#x2F;wart&#x2F;blob&#x2F;ce64882c69&#x2F;071http_ser...</a>. However, I&#x27;ve forced myself to harden my heart and ruthlessly ignore considerations of syntax, and focus on what I think are more impactful directions: conveying global rather than local structure of programs. More details: <a href="http:&#x2F;&#x2F;akkartik.name&#x2F;about" rel="nofollow">http:&#x2F;&#x2F;akkartik.name&#x2F;about</a>. In brief, I&#x27;m working on ways to super-charge automatic tests (by making them white-box, and by designing the core OS services to be easy to test) and version control (using the literate layers you noticed). It&#x27;s a whole new way of programming where a) readers can ask &quot;why not write this like this?&quot;, make a change, run all tests and feel confident that the change is ok if all tests pass; and b) readers can play with a simple version of the program running just layer 1, then gradually learn about new features by running layers 1+2, 1+2+3, and so on.<p>---<p><i>&quot;The problem is that it throws away the ability for the code to pull updates from library maintainers. If the import is &quot;pinned&quot; at commit f1d2d2f9, then you push a security-related patch to akkartik&#x2F;bar, most existing code will stay vulnerable forever, because most code is never maintained after being written.&quot;</i><p>I hadn&#x27;t considered hard-coding hashes in imports, because it&#x27;s historically been very hard to truly distinguish compatible changes from incompatible ones without introducing bugs. I think it&#x27;s more important to give people control over upgrades than to try to improve over the current advisory+pull method of communicating security issues.<p>You&#x27;re right that most code is never maintained after being written. But most code is also utterly unimportant to anyone including the author. So that failure of security is ok :) Trying to force concern about security only increases the moral hazard -- people get used to other people thinking about their security for them.<p><i>&quot;were there any ambiguities with indentation-as-parens? I haven&#x27;t thought about it rigorously, so I was just wondering if there are any corner cases to watch out for when I add it.&quot;</i><p>The big insight, I think, is to not fear parentheses too much. A common failure mode of such approaches (like <a href="http:&#x2F;&#x2F;readable.sourceforge.net" rel="nofollow">http:&#x2F;&#x2F;readable.sourceforge.net</a> and <a href="http:&#x2F;&#x2F;dustycloud.org&#x2F;blog&#x2F;wisp-lisp-alternative" rel="nofollow">http:&#x2F;&#x2F;dustycloud.org&#x2F;blog&#x2F;wisp-lisp-alternative</a>) is to create too many new token types and lose the simplicity of lisp syntax. My approach instead is to a) just use parens sooner than look &quot;outright barbarous&quot; (<a href="https:&#x2F;&#x2F;www.mtholyoke.edu&#x2F;acad&#x2F;intrel&#x2F;orwell46.htm" rel="nofollow">https:&#x2F;&#x2F;www.mtholyoke.edu&#x2F;acad&#x2F;intrel&#x2F;orwell46.htm</a>), and b) take it a step further and disable all indent-sensitivity inside parentheses.<p>Anyways, that&#x27;s my two cents. The precise rules I use are at <a href="https:&#x2F;&#x2F;github.com&#x2F;akkartik&#x2F;wart&#x2F;blob&#x2F;master&#x2F;004optional_parens" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;akkartik&#x2F;wart&#x2F;blob&#x2F;master&#x2F;004optional_par...</a>. (They&#x27;re really in the first couple of sentences there.)<p>---<p><i>&quot;Whoaaa, you use tangle&#x2F;weave! How do you like it &#x2F; what do you think about literate programming?&quot;</i><p>Like I said above, I like it very much, especially in combination with tests and a notion of layers. Here&#x27;s my take on why literate programming has failed so far: <a href="http:&#x2F;&#x2F;akkartik.name&#x2F;post&#x2F;literate-programming" rel="nofollow">http:&#x2F;&#x2F;akkartik.name&#x2F;post&#x2F;literate-programming</a>