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.
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
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.
How is this trackers buying themselves a free pass? I don't know much about Scroll, their website suggests that they are about paying publishers for content you view, rather than selling your data. Is there something sneaky that they're doing that I'm not aware of?
True, not particularly difficult. At the moment though I just keep GPG encrypted text files if I handle encryption independently of jrnl then I lose a lot of the value of it like being able to search by tag.
> 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