Let me first start by saying that I'm a big fan of soft consensus and my preferred term for it is embedded consensus. I even think that a better approach to SMT than trying to build a lot of complicated functional into the blockchain that will be very difficult to ever test and establish quality control with a high degree of confidence (compare the scope and complexity of SMT with the past two hard forks which have been a disaster on that score), and then will continue to be very difficult to upgrade, would be to embrace Steem-Engine (or its current developers aren't agreeable to fully open sourcing and decentralizing it, clone it instead) and develop it further with a clear, well-documented, well-supported, and fully fleshed-out decentralized embedded consensus model.
That being said, I'm also very put off by the constant anti-smart contract drumbeat that seems to come from Steemit. As noted by @blocktrades elsewhere in this thread, smart contracts are a way for the blockchain to support certain forms of computation without needing to hard code every single operation into the core consensus layer, require forks for each and every change and update, and possibly destabilize the core layer interrupting or damaging service for every single user.
Given the approach of RC it would be quite possible to support smart contracts for those application which really benefit while limiting (by cost) the ability of unconstrained smart contracts to weigh down the whole system and destroy decentralization via bloat. For a great many functions which do not need to be nor benefit from being executed and validated within the core layer, relative RC cost would encourage developers to use a soft-consensus approach instead. That may be a lot, but without an enormous amount of convincing (which we are poorly positioned to do as a small minority blockchain and project in a larger marketplace) and in some cases serious technical compromises, it isn't everything.
So yes, I'm all in favor of soft consensus aka embedded consensus, and I absolutely agree it can be made fully decentralized and be a very powerful side-chain-like approach, but I don't think we need to engage in a religious war against native smart contracts which are extremely popular with blockchain application developers and unquestionably useful (including as a bridge for making embedded consensus more powerful and useful). Such a war only serves to marginalize us and make Steem less useful to certain application developers (possibly a very large and wide subset). We should instead embrace both, which was always the original vision of Steem to begin with.
How and why did we get off this track?
I can't agree more on this
I couldn't agree more with this, "We should instead embrace both, which was always the original vision of Steem to begin with."
If the message from Steemit seems contrary to this, then we need to change the way we're communicating about it. Figuring out how to talk about Steem's hybrid approach to consensus is my real goal here. Maybe I'm asking the wrong question and the right question is, "How do we talk about Steem's unique approach which features both hard and soft/embedded consensus." But in a way that ordinary people can understand.
"Steem uses a novel hybrid approach to decentralized computing which features both hard and embedded consensus. This provides the security of smart contracts with the flexibility of traditional programming." Thoughts?
Somebody made a post explaining how Steem is an ASIC to Ethereum's FPGA. I like the analogy and hopefully developers are aware of this kind of hardware terminology as well. Steem can easily become the authentication layer to the decentralized internet of content or other similar marketing terms.
My view is that actual smart contracts are very useful and can play a role, often for bridge purposes in interacting with native functions of the chain such as access control, token movement, etc.
Almost every single blockchain including Bitcoin (almost the poster child for simplicity and stability over functionality) has at least some limited form of smart contracts. They're very useful for bridge purposes such as atomic swaps, token exchanges, adapters to lightning-network-like solutions, for security features such as time locks, two/multi-factor authentication without custody, etc. This does not mean that you build an entire application into the blockchain and expect consensus nodes to verify it for you for free, but there are portions of many applications that are useful for the core blockchain to support natively without the hard coding, risking the stability of the core chain, and hard forking the way we have been doing it.
I think we should stop hating on real smart contracts and should embrace them (with appropriate controls on resource use and bloat via RCs) in addition to soft consensus, not keep trying to pitch soft consensus as an alternative. For many applications it is, but for many others (at least not without great difficulty and enormous unforced marketing challenges) it is not.
We are marginalizing ourselves unnecessarily by trying to convince developers they don't need something they think they need. The better approach is to give them both and let them choose the tool they want to use.