Deleted Comment
Deleted Comment
In fractional reserve banking, money that is loaned out is accounted for as liabilities. These liabilities subtract from the overall balance stored (reserved) at the bank. The bank is not printing money new money, no matter how many times this idea gets repeated by people who are, ironically, pumping crypto coins that were printed out of thin air.
I think it’s incredible that cryptocurrencies were literally manifested out of bits, but the same people try to criticize banks for doing this same thing (which they don’t).
It is now widely accepted that bank lending produces new money[1][2]
[1] https://www.bankofengland.co.uk/-/media/boe/files/quarterly-...
> After the past several decades of humanity putting all of its collective knowledge online, we are seeing more ways to prevent us from accessing it.
This hits so hard, especially for someone who saw the Internet becoming this awesome, huge open library that everyone can access and contribute and then witnessing it being paywalled, drowned with ads and slop, monetized to oblivion, sometimes straight up disappear. It's heartbreaking.
Where so you start? If you have decided on using Python for the UI you have a handful of libraries each with their own documentation. To get started you need to choose one and then read the guides.
If you decide to use HTML you have a whole lot more resources. I'd argue you'll be able to make a frontend faster using this approach.
I understand the hesitation because of the complexity associated with JS. Maybe you're thinking about bundlers and minifiers when you think about writing a frontend with JS.
But you don't need that. You can create amazing user experiences with a plain HTML, CSS and a JS file.
1. It is inconsistent [1]
2. It does not have many features that programmers love and other languages have.
3. It has a community that holds different values from what other programmers value themselves.
If people want to continue development in JavaScript, they can. But since JavaScript has a monopoly on the (fairly large) 'frontend development for the web' market, there will always be attempts to find an alternative.
"Fields containing line breaks (CRLF), double quotes, and commas should be enclosed in double-quotes."
If the DMS output isn’t quoting fields that contain commas, that’s technically invalid CSV.
A small normalization step before COPY (or ensuring the writer emits RFC-compliant CSV in the first place) would make the pipeline robust without renaming countries or changing delimiters.
That way, if/when the DMS output is fixed upstream, nothing downstream needs to change.
[1] https://www.rfc-editor.org/rfc/rfc4180.html