4 ms·
All reasonable points, and potentially insurmountable challenges. Also whatever it is, needs to have incremental utility, otherwise there's no road from the pre
by jasonwatkinspdx 4y ago
All reasonable points, and potentially insurmountable challenges. Also whatever it is, needs to have incremental utility, otherwise there's no road from the present to the future for it.
Also to repeat a minor rant of mine, anyone designing a would be successor to Etherium should think very deeply about programming language theory and consult/engage with experts in that community. Much pain could be avoided by finding types and semantics appropriate to automated contracts.
- landemva 4y agoYou can build whatever language features you want, though it still should deploy into the EVM. Vyper is an existing alternative to Solidity. I would like to see more alternatives, so stop ranting and start building. https://www.quicknode.com/guides/smart-contract-development/solidity-vs-vyper https://www.quicknode.com/guides/smart-contract-development/...
- jasonwatkinspdx 4y agoObserving that you can implement any semantics atop a turing complete mechanism isn't interesting. You're also ignoring the very interesting possibility of using a total language. I am perfectly fine expressing a criticism without trying to become the next ETH developer. That's a pointless and rude behavior. If you find my criticism uninteresting you are free to simply scroll on.
- landemva 4y agoI pointed out that Vyper is an alternative to Solidity which already is available, and that any language can be created to run in the EVM. I would even like to see a subset of COBOL ported to the EVM with an eye toward simple security constructs. Am curious what specific shortcomings you found in Vyper.