Comment by BoorishBears | Hacker News Reader

Comment by BoorishBears | Hacker News Reader

Parent Full thread

Maybe should learn what an RFC is, and check out this one before you keep trying to counter the document that formally minted the verbs in the first place: https://www.rfc-editor.org/rfc/rfc2616#section-9.1.2

See section 9.1.2: Idempotent Methods, where they succinctly address the point:

> Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.

-

It's funny, I wouldn't have thought the RFC needed to say this. I'd have thought it was a waste of words since it'd be obvious to absolutely anyone that you can't... what? magically force developers to not write a bit of code in a system you have literally no control over?

Yet here we are, proving the authors well-prepared all these years later.

> Naturally, it is not possible to ensure that the server does not generate side-effects

Of course it's possible, there are ways to guarantee that and to prove that. That's an area of ongoing research. E.g. https://link.springer.com/chapter/10.1007/978-3-642-36594-2_...

Though I've said just one thing - you can't expect that a GET query would be idempotent. You may only hope.

It is not possible to prove that calling the server will not produce side effects. The link you provided does not address side effects, but correctness, which is much weaker. A trivial example is that calling the server will consume electricity.

"Side effect" is a breakage of referential transparency.

Depending on your model it can be proven.

Electricity consumption won't be a side effect in any reasonable model.

What are you going on about? This feels like someone who's just read their first compsci book and now thinks they can build New Internet.

Surely this is a troll...

I'm saying that unenforceable contracts, like the "idempotence" of GET requests are no better than an annotation on a method in a conventional RPC IDL.

If fact the latter is better, because it may be somehow enforced by cogen if you code-generate into a language which may, for example, enforce purity or totality.

And the whole story about "REST not being an RPC" or "there is purity/idempotence/whatever in REST because RFC says that GETs are pure/idempotent/whatever" makes very little sense.

At the same time I'm saying that it's total bullshit when someone says that it's not possible to enforce lack of side effects (like in referential transparency) during a remote call.

SCC is so unrelated to anything even being remotely discussed, that it would be an insult to the term "orthogonal" to describe it as such.

It's such an off-the-wall connection I can hardly refute it: it's like we're talking about toasters and you dived into talking about CRISPR because I said the word "crispy". If anything it'd imply you're not familiar with CRISPR or toasters.

> Though I've said just one thing - you can't expect that a GET query would be idempotent. You may only hope.

I guess you should look up what it means to expect something. In the context of your sentence hope and expect are synonymous*, so maybe you meant you can't guarantee?

And even ignoring that mistake, it's not really useful to say "You can't be sure something doesn't follow guidance, you can only expect it" because that's tautological. Guidance in and of itself doesn't have any way to assert direct influence on an implementation, that's why it's literally called guide·ance.

*before you use that to dive into a grammatical diversion, that is not generally the case, only specifically in your use.

> SCC is so unrelated to anything even being remotely

Let's assume we make a remote call with a list of VM instructions for a virtual machine which has no access to any I/O. Now we only need to prove the correctness of the answer. Whatever you do on the remote side, you won't be able to make your computation impure. Yes, you still may write logs or sleep but it won't break referential transparency, there will be no way to return two different accepted results for the same inputs.

You may even have I/O in some very limited form.

You don't have to supply the code.

If you don't agree, show me side effects in EVM.

> In the context of your sentence hope and expect are synonymous

Only in your eyes.

Anyway, I've been saying that REST is too unformal and weak-typed.

When you're this far out of your depth, it may be best to stop floundering and see if you can float.

You implicitly revised your previous statements, and the revised point is even further off base (I mean, now you're showing you don't know the difference between REST and HTTP verbs?)

At some point just take it as a learning experience that non-sequitur about verifiable computing don't have any of the "shock and awe" on HN that they might on and your Facebook wall...

You should stick to things you understand if you insist on making authoritative statements.

-

By the way: language doesn't only work "in my eyes", words have meaning, learn those meanings before you use them.

I don't think I've revised anything. I said that it's possible to impose enforceable contracts on remote code execution. I'm not saying all the approaches are practically useful in the domain of RPC, but even there we can do more than just stick to informal promises.

> You should stick to things you understand

Ok. We don't need VC, for practical purposes we may do a lot of contract enforcement at the tooling level, like if we generate code from an IDL, we may restrict access to various APIs, enforce purity and totality.

> you don't know the difference between REST and HTTP verbs?

It doesn't matter if you talk about REST or HTTP, nothing guarantees "idempotence" of GET. Also the discussion was in the context of REST as something opposed to RPC.

> learn those meanings before you use them.

You command too much.

Reply on news.ycombinator.com