Quote from: gmaxwell on June 20, 2016, 07:55:40 AM

Quote from: go1111111 on April 29, 2016, 07:27:27 AM

but I'm not seeing why exactly this means they shouldn't be written in a declarative language

How about now?

Though your example is making a distinction without a difference, something like that could easily be converted to something more Bitcoin script like... but the real differences I'm highlighting are things like avoiding mutable state,

Just seeing your comment now. Yes, the DAO stuff is evidence against having such an expressive scripting language. However I see the mutable state vs script-like language are fairly orthogonal. Assuming that Bitcoin's more constrained system of state is better, what I wonder is whether a more declarative way to write Bitcoin-script-equivalent stuff would still be preferable. As mentioned above, I think the declarative style puts less mental load on developers and is more 'natural'.

The gist of an earlier comment of yours seemed to be: "writing smart contracts is inherently hard and unnatural, so it's fine if the scripting language is hard to understand." I just don't see how one aspect of writing contracts being hard (getting the logic right) implies that it would be better for other aspects to be harder than they need to be.

If a declarative version of Bitcoin script made mistakes less likely, what is the downside? Are you worried about newbs who just learned a bit of javascript thinking they can write secure smart contracts just because Bitcoin script v2 might look a bit more like javascript? So the fact that current script looks intimidating is actually good? If so would it have been even better if Satoshi made all op codes of the form OP_XYZ where X, Y, and Z were digits? And maybe disallowed spaces when not including them would still be unambiguous? That would certainly reinforce in people's mind that writing Bitcoin script is tricky.