bluepnume

Sadly it's not settled in large part because many physicists have stopped caring about more fundamental interpretations or explanations for QM. "The theory works, the math checks out, so we're done" -- and we're left without a really satisfactory explanation for why or how it works.

If I have entangled particles A and B, and then B interacts with and becomes entangled with particle C, can that interaction not qualify as an "observation" that collapses the wave function of A + B and de-entangles them?

I take it you're a MWI fan then? Isn't the answer for why we "force wave-describing partial differential equations into a probabilistic model" because in our reality, when we look at an electron we observe something that looks like a particle and not a wave?

Sentry went down? My only question is - how did they find out?

You can certainly self-custody USDC -- but unlike Bitcoin, even if you self-custody you still have to trust that the USD backing the coin actually exists somewhere.

What does that have to do with the original point?

- Real estate has real-world use cases

- Stocks have real-world use cases

- Bitcoin has real-world use cases

It's meaningless to describe any of these as pyramid schemes because "to profit you must be able to sell at a higher price to someone else". That's true of buying or selling anything.

That which can be asserted without evidence, can be dismissed without evidence.

Bitcoin, just like traditional money, can exist as a non-blockchain ledger entry in bank's computer system. This is how most exchanges and custodial wallets work.

The difference is, you can also self-custody your Bitcoin. Obviously what's in your custody is just a private key; but for all intents and purposes that is self-custody. You are the sole person in control of those coins.

So Bitcoin gives you the choice of how you want to store it. Traditional money does not give you that choice. At a certain point there are physical and practical limits to how much cash you can self-custody (not to mention transport or transfer from one place or person to another).

In which case: do you think it's impossible for a bank to vault Bitcoin with the same level of security as traditional money?

Literally the only way you can profit with real estate is if people keep buying in at higher prices. It's the perfect instantiation of a pyramid scheme.

Literally the only way you can profit with stocks is if people keep buying in at higher prices. It's the perfect instantiation of a pyramid scheme.

You don't like it because it's possible to lose? Are all of your other physical possessions immune from being lost?

My advice is to get it in front of others as soon as possible. Even if it's just mock flows, it's fantastic getting feedback and even lining up real customers who are ready to onboard when you first launch.

We've been doing a lot of outreach on social media platforms like Twitter. It's been pretty easy finding people who are part of our target audience, and asking them if they'd be happy jumping on a 15 minute zoom call to help give us some feedback.

Classes are fine so long as:

- They're small and single-purposed

- They don't inherit (or at the very least, extremely light inheritance)

- There's a very clear relationship between the state and the methods (e.g. a counter class, or a future/promise)

For example in JavaScript, I think you can still uses classes and end up with functional-ish code: https://bluepnume.medium.com/functional-ish-javascript-205c0...

A malicious PR could also add the character to your eslintrc too though. You'd be forgiven for seeing the line change in the diff and thinking it was just some reformatting.

I was a Flow holdout for the longest time. TypeScript's support for discriminated unions is one of the things which finally won me over. Super glad to see it being improved upon here.

IFrames are both terrible and awesome. I built and maintain zoid, which turns iframes into full-fledged components; it's been an adventure: https://github.com/krakenjs/zoid

Probably pick a different hill to die on. The meaning of "REST" in common parlance is now just HTTP+JSON, nothing more. At best, the url might represent a noun.

I didn't spot any regexes here.

If the objective is to get the maximum 'visual' difference for two hashes, why not re-hash both of them first? That results in any small changes causing a huge difference in the final outputs.

I agree with you, it's definitely a trade-off between developer ease and perf.

I get around that in js mostly by avoiding classes and `this` entirely unless I'm sure I'm going to have a large number of instances of something. But there is the mental overhead of "Do I need to wrap this function in an arrow function before passing it around to avoid getting an unexpected `this`?"

So yeah, not saying I have a great solution -- just that none of the existing solutions really seem ideal.

I would rather re-implement `filter` in a way that is specific to `Foo`, than to attempt to use an array method on my class.

Right. If NodeList is compatible with Array methods, it honestly feels like it should just inherit those methods. Or implement them separately.

`Array.prototype.slice.call(arguments)` can be replaced with `Array.from(arguments)` (or as you mentioned `[ ...arguments ]`)

My advice is to start of with javascript by forgetting 100% about classes, inheritance, prototypes, and so on.

Just use vanilla functions and objects, and when in need of something that looks like a class, reach for the revealing module pattern:

https://gist.github.com/zcaceres/bb0eec99c02dda6aac0e041d0d4...

The fact that NodeList doesn't have a native map feels to me like a wart, and doesn't really justify `Array.prototype.map.call` having to exist as a fallback in the language.

Very interested to learn more about this use case. This is to protect against hostile environments blocking function calls by polluting prototypes?

I do a lot of work on SDKs which run in semi-hostile environments, so prototype pollution is something I'm frequently running up against.

> in x.y.f(), f() operates on x.y

Yep, and I think that determining `this` at the call-site is really awful, and has been the cause of many more bugs than is reasonable.

OOP you can do in JS with just `class` and `extends`, you no longer need to care too much about prototypes and how they work. Prototypes have become much more of an implementation detail in recent years.

I've worked full-stack in javascript for many years, and I've written plenty of libraries and tooling. I've used call/apply/bind/this extensively and I understand them to a fault.

I would still remove them in favor of arrow functions and spreads. Unless you can show me any code which is pivotal to writing some tool which absolutely can not be done using the alternatives.

You have my full agreement. You can write great javascript without ever touching prototypes, and probably even avoiding inheritance altogether unless you have a really succinct use-case.

Sorry, yeah, I did allow for closures inside class methods with that statement. That's fine by me.