This paper[1] suggests that there is a 50/50 split amongst programmers in the way in which they trace programs:

> Given a straight-line program, we find half of our participants traced a program from the top-down line-by-line (linearly), and the other half start at the bottom and trace upward based on data dependencies (on-demand)

So it's possible that both viewpoints are correct in some sense and we should pursue languages which allow us to switch between the two viewpoints.

[1] https://arxiv.org/abs/2101.06305

Interesting read. It’s amazing more people don’t use runtime variable value annotation tools like Wallaby.js, or a debugger.

So much time spent mentally remembering what is in what variable based on the naming.

I often find myself adding “// e.g. foo, bar” to show example cases for some lines of code…like recedes for example. Wallaby.js is a godsend for this though.

I would be careful applying this one to imposter syndrome. I think of imposter syndrome as a failure to calibrate your expectations of yourself with the reality of what your work requires. Asking yourself what the "real" person would do that you aren't doing seems to me like it would play into that miscalibration. You might be better of asking _someone else_ what your replacement would do.

I love AsciiDoc and want to use it more. The main problem is, as noted, that it's hard to get this ruby library into whatever platform you want to deploy to. Consequently it's hard to build tooling based on AsciiDoc.

I've had a brief play with trying to implement AsciiDoc in Rust (and others have too, see https://github.com/Veykril/pagliascii). I got bored of trying to figure out what the semantics should be by reading the implementation and decided to wait until the upcoming specification effort at https://asciidoc-wg.eclipse.org/ bears fruit, the Zulip seems a bit more active recently

> The main problem is, as noted, that it's hard to get this ruby library into whatever platform you want to deploy to

There are JVM (via Jruby) and JS (compiled by Opal) versions of Asciidoctor, to the extent that is a problem with the Ruby version.

This optimization is indeed in the pipeline, although there are other things nearer the front because performance is currently Good Enough ™ that other things are more pressing (other things being e.g. completing the Peritext implementation, improving the sync protocol).

There are other considerations though aren't there? Assuming that you trust the hosting entity:

* You may not want to trust the hosting entity for all of time. If you trust that E2E is deployed now, then you don't have to trust the future version of the host

* You may want additional protection against the host database being compromised. If you trust that E2E is deployed then a compromise of the host would not mean anything for your users privacy

My reading of Seeing Like A State was not "central planning bad". The author explicitly acknowledges that there are many benefits to what they refer to as "high modernist" projects which we all enjoy on a daily basis. My reading was more that large scale projects designed to entirely change the way something is done in order to make it legible to a central authority necessarily throws away an enormous amount of local information and this leads to a tradeoff. You end up being able to build much bigger systems, but those systems are not as flexible.

In the context of microservices that seems like a pertinent point because the purpose of a microservice architecture in the first place is often to allow an organisation to be more flexible and accommodate local knowledge.

Im one of the authors of this. Right now the code is very unstable as we're tracking the performance branch of the JS implementation. Once the JS version hits 1.0 I'll be putting a bunch of effort into making the API cleaner and more rusty and documenting things.

It does work and can actually be used as a backend for the JS implementation if you use the wasm backend we've built. In fact, this is how we have tested it, by compiling to WASM and running the JS test script against it.

I read the javascript part as specifically referring to JSON, not to all javascript code.

Interesting. I don't think that's the intended reading, since there are lots of references throughout to "programs", but JSON files aren't programs in the same sense as JavaScript files are. Also there is an explicit distinction between JavaScript and JSON in the article: "...a JavaScript program is not provided as a JavaScript object (or JSON object)".

You might be interested in https://radicle.xyz/

papercut?