Smart Contract Sidechain based Upon Wren?

[bytemaster]

[TheDarkLightX]

Implemented as a side chain, why not? As long as it's not the only smart contract sidechain option, this way developers get to choose better languages in the future. WREN has good specs in terms of speed, but speed may not be an issue depending on what kind of smart contract you want to write.

[theoreticalbts]

Remember the software development aphorism: "Plan to throw one away; you will anyway."

For the first sidechain(s), we'll probably have lots of issues and need to be able to iterate quickly. Then we'll end up with an ugly, un-extensible mess because we changed our minds four times about how it should be designed. Then we'll decide to rewrite it cleanly, using a sane, coherent architecture, now that we fully understand all the issues involved.

This means that, for the initial pass, developer productivity will be much more important than runtime performance, since it will be rewritten from scratch anyway. So instead of some new unfamiliar language, we should use Python (first choice), C++ (second choice) or JS (third choice).

I think I would go so far as to say that we don't even have a good enough idea of the requirements of a blockchain scripting language to be able to state with any certainty whether Wren is an appropriate choice.

Also, I question this performance benchmark -- it seems this only includes CPython. Pypy will be much much faster.

Finally, Wren is not widely used -- I certainly haven't heard of it. That means we may have to deal with:

• Library deficiencies (we need X, but no implementation is readily available)
• Support deficiencies (any Python problem can usually be solved with a Stack Overflow search, but this is much less likely for obscure languages)
• Network effect deficiencies (anyone looking to build a sidechain will first have to learn a new scripting language, increases barrier to entry)

[liondani]

https://steemit.com/steem/@dana-edwards/formal-verification-of-smart-contracts-and-wren

[talerecursion]

This means that, for the initial pass, developer productivity will be much more important than runtime performance, since it will be rewritten from scratch anyway. So instead of some new unfamiliar language, we should use Python (first choice), C++ (second choice) or JS (third choice).

Or we could simply integrate the EVM and be done with it in no time. Many advantages in addition to shorter time to market: a lot of reuse from existing Ethereum smart contracts, many developers familiar with the architecture, attractive to Ethereum community users so likely to make converts, compatible with ETH, ETC, Rootstock, Counterparty and other future projects using the EVM, compatible with Ethereum oracles, many tools available and actively developed...

By the time the EVM is live, developers will have more experience with developing side chains, so next attempt can be more ambitious.

[talerecursion]

Something that would make Steem + Smart contracts rather unique would be to allow Steem posts to communicate with smart contracts in the same way as client side webpages communicate with server side scripts in Php, Ruby etc. This would allow to have sever-less dynamic blog posts.