> especially since no one had much experience with the implications of the memory/storage/execution model of Ethereum at the time work started on Solidity, let alone the kinds of vulnerabilities these contracts would be exposed to.
Perhaps the Ethereum devs didn't have this experience, but this experience and knowledge was out there. The E programming language has been a vehicle for smart contract and security research for over 20 years. How many Ethereum and/or Solidity devs read the E research, learned the E language and played around with it?
There is also decades of research on formalized smart contract languages. Nick Szabo is well known in this space, and he wrote a draft paper on a great contract language back in 2002:
I mentioned that no one had much experience with the implications of Ethereum's model and you point me to a bunch of articles but I fail to see how they apply to the case of Solidity.
What are the big ideas from E that Solidity is missing?
Also, the article by Nick Szabo has some interesting ideas, but as far as I understand, it does not describe a language for programming arbitrary smart contracts, just some notation for common financial contracts.
Perhaps the Ethereum devs didn't have this experience, but this experience and knowledge was out there. The E programming language has been a vehicle for smart contract and security research for over 20 years. How many Ethereum and/or Solidity devs read the E research, learned the E language and played around with it?
There is also decades of research on formalized smart contract languages. Nick Szabo is well known in this space, and he wrote a draft paper on a great contract language back in 2002:
http://nakamotoinstitute.org/contract-language/
How many of the devs have read this paper?