yshavit

Fair enough!

The Markdown parsing library I'm using supports MDX, so it shouldn't be too difficult to come up with syntax for those components. I haven't done that yet, but mostly because I didn't want to go down that path until I knew there was interest and had a concrete use case or two to inform the query syntax.

If you want to open an enhancement request issue, I'm happy to take a look (PRs also welcome, but not required). If you're not on GitHub, let me know and we can figure out some other way to get the request tracked.

Thanks for taking a look at the project!

I'm curious how ergonomic you find that? I did look at the pandoc JSON initially, and found it fairly awkward to work with. It's a great interchange format, but doesn't seem optimized for either human interaction or scripting. (It's definitely possible to use it for scripting, it just felt cumbersome to me, personally.)

I forget if LastPass does — 1Password does (though I haven't actually used it in practice, because my work doesn't use 1Password). Idk, maybe it's not actually a problem, but it's how I like to organize things. ::shrug::

Ideally I'd want to keep my _personal_ personal stuff separate from my "work personal" (ie my personal logins, but the one for work accounts) separate from my shared work stuff. So I'd want two accounts, one for my truly personal accounts, and then one for my work-personal and have the work-shared connected to that.

I just switched password managers from LastPass, and Bitwarden's lack of multiple accounts on their browser plugin was a dealbreaker for me. Such a basic feature, especially if they want to get widespread adoption. Otherwise, anyone whose work uses Bitwarden basically can't also use it for their personal stuff without jumping through hoops.

I'll keep it on my radar, because at an intellectual level it seems pretty interesting. But this smells a bit of "fun computer science, not terribly useful software engineering."

Firstly, my experience with Haskell left me pretty skeptical of pure programming languages. They're just that much harder to grok; debugging becomes harder (though it looks like this language has log functions, so it's not totally pure FP?), `for` loops are just easier to think about than folding, etc.

But beyond that, the problems this language tries to address just don't seem like the real problems I face. Let's take a few:

• distributed programming: shipping bits of opcode (whether it's machine code, Java bytecode, etc) is easy. The hard part is knowing which bits to distribute where, especially when they have to operate on shared state. I don't see how hashing ASTs helps with that.

• no builds: I mean sure, that's nice I guess. But tbh, I spend very little of my day or mental energy waiting for compilation.

• dependency conflicts: The bad ones of these don't arise from name conflicts — those are easy to get around. The bigger problems are things like two dependencies that each depend on different versions of the same library, and you want them to communicate: you want DepA to talk to DepB via some object defined in DepC that they both use, but DepA and DepB use different and incompatible versions of DepC. Hashing doesn't seem to fix this.

Now, that doesn't mean people shouldn't learn this, especially if they find it interesting. I don't use Haskell at all, but I think I'm a better programmer for having learned it, because it made me think of things in a new way. This language could well be similar — but I don't see it replacing mainstream languages.

And it contains its own tldr, in the form of "<h2>No. Just No.</h2>".

We need a new acronym: tl;dc: "too lazy; didn't click"

"Education" maybe the worst of them. One of the what-to-do steps is... learn what to do? Talk about drawing the rest of the freaking owl.

Ah, gotcha — my app won't help with that, then, sorry! :-)