yshavit

no profile record

Submissions

Show HN: Jq-Like Tool for Markdown

325 pointsby yshavitanno scorso75 comments

State of Infrastructure-from-Code 2023

14 pointsby yshavit3 anni fa1 comments

comments

anno scorsodiscuss

That's a great idea, thanks! I'll do that tomorrow or so.

As a preview, two specific cases I've seen:

1) In PRs, some companies like to have semi-structured metadata, like a link to a related ticket under a heading "Ticket". In mdq, you could find that using `# Ticket | [](^https://issues.acme.com/)`

2) Many projects ask people who submit bugs to check off whether they've searched for existing bugs. `- [x] I've looked in the bug tracker for existing bugs`

anno scorsodiscuss

Fair enough!

anno scorsodiscuss

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!

anno scorsodiscuss

For the markdown, I'm using https://github.com/wooorm/markdown-rs, which is a formal parser that produces an AST. For the query language, I have a very simple hand-rolled parser.

anno scorsodiscuss

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.)

3 anni fadiscuss

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::

3 anni fadiscuss

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.

3 anni fadiscuss

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.

4 anni fadiscuss

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.

4 anni fadiscuss

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"

4 anni fadiscuss

"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.

4 anni fadiscuss

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

4 anni fadiscuss

I don't know if shameless plugs are allowed here (sorry if not!), but I have an open source project for Mac that's aimed at exactly this problem. Every ~10 minutes (configurable), it pops up an unobtrusive prompt to ask you what you're working on right now. It then has some basic reporting and aggregating functionality. It's not specifically targeted for consulting / invoicing (I made it because I often ended my day wondering what the heck I'd done all day), and it's sometimes a tad rough around the edges, but it could help. https://whatdid.yuvalshavit.com / https://github.com/yshavit/whatdid

(I'm newish to HN, so please let me know if this message is inappropriate!)

4 anni fadiscuss

I only use Swift for a side project, but I found myself splitting my time between AppCode and XCode. AppCode is nicer in terms of feature set (both in completeness and in my familiarity with the shortcuts), but I find XCode is much faster. If I'm working on something with a bunch of renaming/refactoring/etc, I'll do it in AppCode; if I'm more or less just typing and running tests, I'll do it in XCode.

So, while this announcement is sad, I can't say it's shocking. In other languages I know, IntelliJ products are significantly better than the competitors. For Swift, it's a bit more... meh.

4 anni fadiscuss

/I'm (not )?sorry for creating this/

4 anni fadiscuss

It probably wasn't, but it felt like it was. And what I mean by it is: "people worked on the software, that took time, we should pay them for that time."

My sense is that a big part of why people don't like subscription models is that they figure, "I have to pay every month/year, but the developers don't actually have to write new features in that time." I think that mindset implicitly prices the software based on the cost to the company of developing it. I'm suggesting that another mindset is, "if I use this for 10 months instead of 1 month, then it's worth ~10x as much to me (relative to if I'd only used it 1 month), so it makes sense I'd pay ~10x more for it."

I was looking at it less from the business's perspective, and more from the emotional perspective of the buyer.

4 anni fadiscuss

I know lots of people hate on them, but honestly I usually don't mind too much. It does change the mental model for pricing: instead of being based on dev costs, it's based on value. If I use the software for a long time, then it's presumably more valuable, and therefore it makes sense for it to cost more overall (if you assume a value-based pricing model).

4 anni fadiscuss

For those who don't know, IntelliJ IDEA also has this. (I'm not affiliated with them at all, but I do love their IDEs.)

Personally, I tried it once and was too weirded out — I've lived with the side panels for so long that it feels wrong without them there, minimized and providing a nice little frame for my thoughts.

4 anni fadiscuss

[]any isn't "any slice", but rather "a slice of some type, and that type could be anything."

It's not just a detail of the underlying runtime; there are very real, semantic problems that would occur if two(s) compiled. Consider what would happen if instead of just returning its input, two([]any) modified it:

  func two(s []any) {
   s[0] = "hello"
  }

That's certainly allowed. Now imagine you had:

  someInts := []int{1, 2, 3}
  two(someInts) // this won't compile

It's a good thing that second line doesn't compile, or your []int would contain a string element.