Turing completeness is not an implication of poor anything. All it does is remove certain kinds of generality from your proofs. You can still prove things, you just have to be careful stating what the assumptions are.
So you mean to tell me that taking away the ability to write generic programs to validate contracts is good design? See Rice's Theorem (https://en.wikipedia.org/wiki/Rice%27s_theorem). Once you have turing completeness verifying any non-trivial program property starts requiring grad school experience and real proficiency with writing and verifying proofs. Most people, including programmers, do not have the training nor the discipline to actually do what you suggested.
In practice the assumptions you mention turn out to be assumptions about totality and termination of certain building blocks and so you are back to a restricted subset of the language which should have been the original language to begin with but instead of automatic verification you have turned the problem into manual labor. Thinking about this more I agree with the naysayers. Etherium was a good experiment to show people what they should not put into a smart contract system.
.and that PhD computer scientist will have a contract that he/she cannot be held responsible for anything bad that happens with the code he/she writes. Written by a juris doctor lawyer. :)
I think this is the core flaw in the mindset of Ethereum adherents: the very idea that it is even possible to have "Laws" which are completely objective to the point of mathematical logic and that these could/should be enforced, literally, by a computer running a program.
We are thankfully very very far from a system of Laws which are anything like that. Such a system might be great in certain "sandbox" environments for manipulating resources that have carefully controlled interactions with the outside. But to have arbitrarily complex "smart contracts" running in the affairs of the real world? no thanks!
So, just write your contract in a non-turing complete subset of it. Just because the power is there doesn't mean you have to use it if you don't want to.
According to the article, you need to write interfaces that accept a function and call it somewhere down the line. At this point you already cannot guarantee the lack of recursion, simply because the supplied function can call your function again. It is simply not possible to write a code that always halts, unless you never even call the supplied function.
There's a difference between general recursion and bounded recursion, and you can very easily constrain recursive functions to terminate, especially if you're in control of the data they must pass around.
You just made my point. The Ethereum designers have offloaded all the hard work onto others. What value do I get out of this platform if I'm doing all the hard work?
