trixn

Fair enough, just wanted to point out that banks originate money as part of the lending process. You could maybe call that "money out of asset purchases" whatever that means and yes its a valid balance sheet operation. I guess you would agree that a bank needs no prior savings or deposits in order to make a loan, i.e. it doesn't need to have money that it "lends out"?

Or let me ask you this: What would in your opinion be a valid example of "money out of nowhere"?

Very true but also understandable because that's how most households perceive it from their micro-economic standpoint. But its very deceptive because it suffers from a fallacy of composition. If households want to earn more than they spend (i.e. save), some other entity must spend more than they earn. This can be somebody taking a mortgage or the government running a deficit. Debt and savings are mirror images of the same thing, two sides of the same coin and we use double-entry book keeping to track them.

It is very insightful to view money as a creature of accounting for debtor-creditor relations rather than thinking of it as some kind of commodity.

You mean it happens when a bank borrows money from a central bank, right?

No I mean in the moment the bank grants a loan. The money the borrower receives is new money, its not taken from anywhere else. But at the same time the bank records the credit as an asset which makes it a balance sheet extension.

when you put money on your bank account, the bank's balance sheet grows

That's true, you hand over cash to the bank which becomes its asset and your account balance is marked up for the same amount. Not all money in circulation is accounted on a bank balance sheet, but most of it is bank deposits. cash is an exception, it's public money, not private bank money. When you "put money in a bank account", i.e. you bring cash to the bank you are essentially selling your public government money to the bank and it pays you with its own private bank money (which it "creates" as well).

But this is only a micro-view of a single event. In the aggregate money is created when either the government runs a deficit or when banks make loans and money is destroyed when taxes are paid or loans are repaid.

Money can’t be created out of nowhere

Well, in case of a bank it can. And it happens on a daily basis. In fact thats how most private bank money enters the system in the first place either when a bank makes a loan or when it buys any other asset like e.g. a corporate bond (you can conceptualize a loan as an asset purchase as well, the bank buys a promise to pay from the borrower which is recorded as an asset of the bank). Both are a balance sheet extension from a double-entry bookkeeping point of view.

The 4 operations double-entry bookkeeping allows are:

1. balance sheet extension (e.g. making a loan) 2. balance sheet reduction (e.g. loan repayment) 3. asset swap (e.g. a bank buying a government bond with central bank reserves) 4. liability swap (e.g. transferring money from one account to another)

So it may be more accurate to just say that every event that affects the balance sheet must be one of those 4 operations.

Also see "Money creation in the modern economy" - Bank of England Quarterly Bulletin 2014 Q1

Gold never really served as a currency, rather as collateral. If gold is a currency than any marketable asset is. A good definition of "currency" or "money" would be one that distinguishes its characteristics from commodities and the only useful one I know of is the "credit theory of money". Money is a promissory note, an accounting device and that is true for at least 5000 years of monetary history tracking it back all the way to ancient babylonia. Throughout that history money has taken many forms reaching from clay tablets, metal coins, tally sticks, paper money all the way to digital currency but all those share a common principle which is that they are all records of indebtness, promises to pay. Barter is not and has never been the default mode of commerce at all or a anthropologist Caroline Humphrey put it:

“no example of a barter economy, pure and simple, has ever been described… all available ethnography suggests there has never been such a thing”.

Barter as a form of commerce pre-dating monetary economies is a myth, a post-hoc rationalization of how money might have came about from the perspective of somebody that already lives in a monetary economy and it's entirely an armchair theory that does not rest on any historical and anthropological evidence.

What is true is that between parties that do not have an established relationship barter occurred and it is true that people seek to hold assets and demand tradable collateral during periods of unrest. But barter has never been a primary way to do commerce between parties that had a long-standing relationship. A theory of credit-money is way more useful to explain real world behavor than a metalist approach is. Gold isn't used in daily transactions, it primarily sits in basements and is also is not an input to allmost all of production. What makes us rich in real terms is not gold but knowledge, machines and technology.

While that might be true there is still a point to be considered regarding vaping which is that it is an order of magnitute less harmful than smoking tabacco cigarettes because nothing is burned in a vape and the "burning stuff" is what makes normal smoking so harmful. Therefore I'd argue it should definitely be available for smokers at a price tag lower than cigarettes if they can't quit smoking to reduce harm. This would massively decrease the huge costs for health care.

That's correct, in normal use the coil (the term used for the metal) never glows, it's not even close to glow. This is because it is surrounded by cotton soaked in the liquid which always cools the coil and which produces the desired vapor. If the coil would ever start to glow this is called a "dry hit" and it usually happens if you failed to monitor there's enough liquid in the tank. In this case the cotton immediately starts to burn and believe me inhaling that is disgusting and you would immediately stop. In fact you even stop before that because if the cotton gets dry it stops tasting any good.

Vaping is (compared to actually smoking tabacco) definitely harm reduction and significantly less harmful (which doesn't mean its healthy and you should do it). Yet it is treated like smoking cigarettes by law. For example in Germany you have to pay tabacco tax on the base liquid (which doesn't even contain nicotine) if it is intended to be used in a vape (17 cents per milliliter) which increased the price of the base liquid from around 10€ to 170€. But the base liquid only consists of two things (propylene glycol and glycerol) and both those substances you can by cheaply in a vet doctors online shop for maybe 5€ each liter. It's ridiculous.

MMT proponent Bill Mitchell calls that "groupthink". It's really hard to get heterodox economic theory published and accepted.

I also feel like this really is one of the biggest pain points when writing single page apps. There is no good standard and everybody is promoting his/her way to do it that works well in a TODO app example but kinda fails in a big production application.

I agree that you could in a lot of cases get along without these classes. But sometimes you want e.g. an anchor acting as a button in a web application. Or you want a button element with browser styles. You could argue that this is also already an anti-pattern but it does way less harm then leaking inline styles into the namespace and it is still semantic. Also this was just an example (maybe not the best one) to illustrate my point that class names should be semantic and not express solely presentational attributes. The later is what styles are there for.

Especially in a javascript driven web application you may want to select all "buttons that are disabled". But you never want to select elements that "have a rounded border of 2 px and a grey background and italic font style and....". This takes class names ad absurdum.

I don't like that concept of essentially inlining styles in the class attribute. It is just a misuse of html classes.

Class names should be used sparingly and describe the semantics of an element rather than its visual appearance. It should be something like class="button submit disabled" instead of class="f6 link dim br1 ph3 pv2 mb2 dib white bg-black".

If anything these styles should be exposed as sass mix-ins that you can use in your own styles. So you have a named set of style mix-ins that do not pollute class names.

I feel exactly the opposite is the case. Hooks can improve expressiveness a lot by helping developers to separate concerns and keeping logic that belongs together in a separate place.

While I understand the argument that hooks encourage to make dumb components stateful this is already the case with class based components. At the end of the day a developer is responsible for separating concerns of his application and he can fail to do so with class based components and hooks the same way.

As I understood it you should not opt-in to use state conditionally in your component but you can still conditionally set the state. That means you should not conditionally call `useState` but it is fine to conditionally call the `setState` returned by the `useState`. That is not different to how you would use state in a class based component where you also wouldn't attach a state `this.state = {...}` somewhere in the middle of its lifetime. The component has state from the beginning of its lifetime or it hasn't state at all. There is not such concept as "Now that you are expanded you will transform into a stateful component".

A lot of my components contain something like this line: const Comp = ({children, className}) => {}.

If you need to merge it with some statically applied class names in your component you need to access it. This is an absolutely common thing. It would be terrible if i'd need to access it by using a string. And even then I would need to assign it to a name other then "class" which makes it even more confusing then naming it "className" by convention.

React is quite consistent in naming things and if you write 100's of components (which you should easily accomplish if you use it seriously) then you will never mix up className and class. In fact almost everything in react is camel case which is also the most commonly used style for naming variables in javascript. This makes it very comfortable to create objects from variable names and spread it as props. It really did never annoy me at all (Maybe the first 10 components I wrote :D )

Also if you use a sophisticated IDE that shouldn't be an annoyance at all.