Hacker News: explaininjs

New comment by explaininjs in "Bricked iPhone 16 Can Be Restored Wirelessly Using Another iPhone"

explaininjs — Mon, 23 Sep 2024 12:58:13 +0000

Verizon after 60GB is 600kbps on 5G/4G but up to 3Mbps on UWB. Pretty reasonable IMO. It’s AT&T that’s the holdout, 128k regardless of plan, after 60GB.

New comment by explaininjs in "Bricked iPhone 16 Can Be Restored Wirelessly Using Another iPhone"

explaininjs — Sun, 22 Sep 2024 23:04:33 +0000

I did in fact follow the link. I actually went further than you, all the way to the GitHub, where I saw that it was actually just a web app. All TS.

And you can 100% load PWAs offline, which might be slightly more progressive than your idea of a web app, but I hope not overly so.

New comment by explaininjs in "Bricked iPhone 16 Can Be Restored Wirelessly Using Another iPhone"

explaininjs — Sun, 22 Sep 2024 22:50:12 +0000

That’s a web app, it’s on them if they don’t want to offer their services without requiring me to let them out of the web sandbox.

New comment by explaininjs in "Bricked iPhone 16 Can Be Restored Wirelessly Using Another iPhone"

explaininjs — Sun, 22 Sep 2024 22:39:48 +0000

As someone who does a ton of networking/routing at the link layer for a day job, I can definitely see why they’re taking measures to reduce bandwidth hogs - to the extent I might actually prefer to be on a network that has taken measures to reduce hogging vs one that has not.

When it really truly matters, like when I have a business need to download huge items in remote areas, the $10/GB+ justifies itself.

New comment by explaininjs in "Bricked iPhone 16 Can Be Restored Wirelessly Using Another iPhone"

explaininjs — Sun, 22 Sep 2024 22:26:29 +0000

Curious what you want from a jailbreak at this point? It seems all of the old things that were actually helpful have found them into first party software, or at least in the sanctioned third party. (internet tethering, emulators, side loaded apps, etc.)

New comment by explaininjs in "What's functional programming all about? (2017)"

explaininjs — Fri, 06 Sep 2024 19:17:28 +0000

I should not need to explain to you that the problem is when b itself is internally an (m b’). Or when it is a sum of many types, of varying m-nests.

I can assure you that JS libraries work with Promises just fine.

New comment by explaininjs in "What's functional programming all about? (2017)"

explaininjs — Fri, 06 Sep 2024 15:55:05 +0000

This is all besides the root topic though, which is that CPS and Monads are isomorphic. Which is true. Promises are a different thing.

New comment by explaininjs in "What's functional programming all about? (2017)"

explaininjs — Fri, 06 Sep 2024 15:33:32 +0000

We might consider promises “applied monads” or “engineered monads”. Monodic in inspiration and they solve the same core problem, but they aren’t straightjacketed into the ivory tower “laws” in absolutely every edge case (they do satisfy them in the vast majority of cases). Which is good, because it means we never need to write things like “await await await await await foo()”

New comment by explaininjs in "What's functional programming all about? (2017)"

explaininjs — Fri, 06 Sep 2024 02:55:36 +0000

There is one particular edge case in which they do not satisfy the laws. That happens to make them much more practical in day to day coding than a strict interpretation would be.

New comment by explaininjs in "Ruby methods are colorless"

explaininjs — Thu, 25 Jul 2024 20:15:20 +0000

If you’re fine with manually checking a standard interface to see if you should abort, JS’s answer is the AbortController. This is supported by features like the “fetch” function for making cancellable http requests.

https://developer.mozilla.org/en-US/docs/Web/API/AbortContro...

New comment by explaininjs in "Ruby methods are colorless"

explaininjs — Thu, 25 Jul 2024 14:32:42 +0000

Show me a JS library that allows you to swap a non-async call for an async one in a non-async context^ and I’ll eat my hat.

^Without any non-local changes, obviously.

New comment by explaininjs in "Ruby methods are colorless"

explaininjs — Thu, 25 Jul 2024 00:34:25 +0000

No… I fear you’ve missed the entire point of the matter, which is that async/await requires that you must go all the way up the call stack explicitly “await”ing things when you have introduced an “async” call (or similar wide spread changes to that effect). There’s no special magic utility function you can call you hide it away. That’s the whole point – and a very good thing, this thread argues.

New comment by explaininjs in "Ruby methods are colorless"

explaininjs — Tue, 23 Jul 2024 21:42:29 +0000

No… that’s the whole point. If you change them to be async, the language forces you to go and rethink what implications that has for the callers. This is a good thing, dumbly sequenced operations are terrible UX. And UX is far more important than whatever it is they call “DX”.

New comment by explaininjs in "Ruby methods are colorless"

explaininjs — Tue, 23 Jul 2024 17:37:01 +0000

That sounds a lot like async/await. Any errors thrown in an async context bubble to the callsite awaiting it.

New comment by explaininjs in "Ruby methods are colorless"

explaininjs — Tue, 23 Jul 2024 17:36:03 +0000

Indeed. And breakpoints and stepping across concurrent context actually works in JS, which is nice.

New comment by explaininjs in "Ruby methods are colorless"

explaininjs — Tue, 23 Jul 2024 17:34:51 +0000

Yes. That blog has probably done more to negatively impact the industry than any other written work I know.

New comment by explaininjs in "Ruby methods are colorless"

explaininjs — Tue, 23 Jul 2024 14:33:47 +0000

F# first actually. Then C#. Then Haskell. Then Python. Then TypeScript. Parent just has an axe to grind.

New comment by explaininjs in "Ruby methods are colorless"

explaininjs — Tue, 23 Jul 2024 14:30:10 +0000

Coming from a heavy TS background into a go-forward company, I’d say the main thing you get with async is it makes it incredibly obvious when computation can be performed non-sequentially (async…). For example, It’s very common to see the below in go code:

   a := &blah{}
   rA, err := engine.doSomethingWithA()
   b := &bloop{}
   rB, err := engine.doSomethingWithB()

This might have started out with both the doSomethings being very quick painless procedures. But over time they’ve grown into behemoth network requests and very thing is slow and crappy. No, it’s not exactly hard to spin up a go routine to handle the work concurrently, but it’s not trivial either - and importantly, it’s not immediately obvious that this would be a good idea.

Contrast to TS:

   let a = {blah}
   let [rA, err] = engine.doSomethingWithA()
   let b = {bloop}
   let [rB, err] engine.doSomethingWithB()

Now, time passes, you perform that behemoth slowing down of the doSomethings. You are forced by the type system to change this:

   let a = {blah}
   let [rA, err] = await engine.doSomethingWithA()
   let b = {bloop}
   let [rB, err] await engine.doSomethingWithB()

It’s now immediately obvious that you might want to run these two procedures concurrently. Obviously you will need to check the engine code, but any programmer worth their salt should at least seek to investigate concurrency when making that change.

I wouldn’t be bringing this up if I hadn’t made 10x+ performance improvements to critical services within a month of starting at a new company in a new language on a service where the handful of experienced go programmers on the team had no idea why their code was taking so long.

New comment by explaininjs in "The Delusion of the Polygraph"

explaininjs — Thu, 18 Jul 2024 21:40:02 +0000

> You basically have to give up on the idea of ever having any real evidence for one thing over another

Exactly. We agree.

> best explanations we could find

We have no tested explanation of abiogenesis, chiefly. Among many other questions. Lots of theories that say “and throw your hands up and wave them around and wait 8 million years and tada, probably, idk”

God intervening in the universe is a potential source of sudden changes in the laws of physics. For instance changes that allow a man to walk on water or split a sea. Those changes are stepwise, they do not impact space time gradually. Thus non-differentiable. If the change was gradual, evolutionists would come up with a formula for it and say it magically is that way, for “reasons”. They might look at how their laws of gravity work and see that they aren’t right for galaxies, and say the reasons are “dark matter”, for example. I might say they’re God working exerting a differentiable influence, but those two are interchangeable, at least on the surface. It’s only the stepwise that is Godly.

New comment by explaininjs in "The Delusion of the Polygraph"

explaininjs — Thu, 18 Jul 2024 17:20:15 +0000

That is the belief that leads to evolutionism, not the exact definition of evolutionism. A necessary precondition.

I don’t have time to explain basic mathematics. Suffice to say, the concepts of changing over time and differentiating are very related. If you didn’t know that… that explains a lot I suppose.

I still don’t know what your point is, by the way. Maybe we should settle that.