Readit Newspastelsky commented on Brazil's government-run payments system has become dominant economist.com/the-america... · Posted by u/jcartw
I wish we could make a comparison with Indian payment system calld UPI. I feel both are similar and I wish if we could know and compre all such govt run initiatives. UPI is Indian govt initiative and very reliable
UPI is great in terms of UX, but I don’t think it’s super reliable – especially big public banks go down all the time. The UPI base service had multiple incidents in the last 1 month too.
Did not expect to see Emraan Hashmi in this post!
One would’ve thought that after looking at modern day computers that being able to run a wire through two computers being able to transfer data quickly, reliably, easily would be a 101 feature these boxes offer.
It’s 2024 and it doesn’t really work!
pastelsky commented on Tsdocs.dev: Type docs for any JavaScript library tsdocs.dev... · Posted by u/webartisan
This is really awesome work!
This takes a big burden off of individual packages from publishing their own API docs (having done that I know how hard it can be!), and having a centralized API viewer can offer a lot of advantages over separate docs.
A couple of things I would suggest:
1. Track re-exports and cross-package references and allow crossref links to go into other packages. If package A uses rxjs, then links to the rxjs types should go to the canonical definitions in the rxjs package. (figuring out the canonical declaration can be tricky because it's not always the original declaration though)
2. Organizing by type isn't always a great introduction or way to navigate a package. On the Lit project at https://lit.dev/docs/api we re-organized the API docs by categories and the most important API surfaces. There aren't standard jsdocs for this, but a few straightforward things like @category could be used to offer an alternate top-level nav for a package. Also consider supporting the @packageDocumentation tag from tsdoc.
3. Consider showing files other than the README. Relative links to things like CONTRIBUTING.md currently break. Alternatively interpret all relative links as pointing to github.com or npmjs.com. It'd be great to have a way to link from the README into API docs to guide readers. The community doesn't have a great convention for this unfortunately.
> 1. Track re-exports and cross-package references
This should already be tracked — play around with the member visibility widget on the sidebar for e.g. For convenience, I've inlined the types from re-exports, but might be a good idea to indicate they were re-exported.
Pointing to the canonical source can also limit the usefulness in a few cases (e.g. d3 is just a bunch of re-exports), and users may not care about internal package organization.
> 2. consider supporting the @packageDocumentation tag Organizing by @category and @packageDocumentation should already be supported. e.g. See the functions in — https://tsdocs.dev/docs/lodash-es/4.17.21/index.html
> 3. Relative links to things like CONTRIBUTING.md currently break Yeah, this is known, thanks! https://github.com/pastelsky/tsdocs/issues/9
pastelsky commented on Tsdocs.dev: Type docs for any JavaScript library tsdocs.dev... · Posted by u/webartisan
Author here:
I created this because I found myself peeping inside type declaration files too often, and the only way to do that was by installing the package first.
tsdocs.dev helps you check the API surface of a good number of JS libraries and their past versions — usually a quick search away.
There's something powerful about speed and being able to answer questions in seconds that usually take minutes.
edit: The server might be overloaded with requests as we prime up our caches, but do visit back after HN's done hugging us to death.
You can show your support and help cover a part of server costs if this (or bundlephobia.com) saved you time.
pastelsky commented on Tsdocs.dev: rustdoc style documentation for JavaScript libraries tsdocs.dev... · Posted by u/pastelsky
tsdocs.dev helps browse reference typescript documentation for any package or version of a library.
So you don't have to rely on library authors to provide upto date reference docs for different versions of their library
If I understand correctly, the limited amount of "expressiveness" a quantum computer has restricts its ability to solve useful problems.
Couldn't you simply express useful problems as a function of problems that the quantum computer can already solve? Doing so might be extremely in-efficient, but give that there's so much performance leeway, it still might end up being similar to super computers of today?