3 ms·

> 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 acce

> 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.

BoorishBears 4y ago
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.
- pshirshov 4y ago
  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.

BoorishBears 4y ago

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.

pshirshov 4y ago
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.