Solidity, Vyper, and other smart contract languages are Turing complete generic programming languages. They are not optimized for any specific application scenario. It is difficult to write or use application libraries in those languages. The “world computer” is good for no particular application.
The VM mixes consensus and non-consensus executions. Query/view functions, which account for 90% of the usage, must adhere to the strict limitations required by the small number of transactional functions. The smart contract is constrained by the lowest common denominator of consensus (e.g., no random number, very limited string function, no JSON).
Generic programming language not optimized for any use case
Solution Domain-Specific Language (DSL) extensions to Solidity. A good example is the Lity Rules Language for Solidity. Smart contracts are rules-based programs. Incorporating formal and verifiable rules inside smart contracts is an important domain specific use case. See our video demo at Devcon5.
The lowest common denominator Non-consensus functions are needlessly constrained
LLVM is the most widely used and optimized compiler toolchain for almost all modern computer languages. Second State is leading the initiative to bring the LLVM into the Ethereum community. Read our collaboration statement with Ethereuem Classic on LLVM-based tool chain for EVM. At Devcon5, we demonstrated the world's first Solidty LLVM compiler that can run ERC20 contracts on Ethereum Foundation's Ewasm testnet. See the demo video here.
WebAssembly (WASM) is a highly optimized virtual machine. The Ethereum flavored WebAssembly (Ewasm) is the smart contract execution environment for Ethereum 2.0 and beyond. Together with the LLVM, it could potentially support all popular programming languages, including DSLs, on the frontend, and support many libraries for non-censensus code. The Second State SOLL compiler can already generate smart contracts for Ewasm.