3 ms·
You are right, they solved the particular problem I highlighted with Modifiers. But the main question remains: Why don't they utilize the progess we made in de
by hexhex 9y ago
You are right, they solved the particular problem I highlighted with Modifiers.
But the main question remains: Why don't they utilize the progess we made in decades of research for better programming languages?
The argument that Solidity should be useable by the average programmer doesn't hold, in fact, typing makes programming easier since it clarifies data structures that are implicit in languages like JS.
- ym705 9y agoI agree about typing but unfortunately I'm not a core dev. The compiler does a good job at warnings thought...
- cdetrio 9y agoPL people often direct their "it should be functional and use strong typing" critique at the EVM rather than Solidity. Solidity is just one HLL (higher level language) that compiles to EVM bytecode. A lot of the limitations of Solidity are due to constraints of the EVM, but the EVM is evolving. For instance, the next planned hard fork will enable the EVM to pass dynamically sized data (e.g. solidity arrays or strings) between call stacks. Previously arrays had to be fixed-size, so you'd have to define a fixed maximum size, then always return data of that size (usually a lot of empty elements). This feature, like many others, is somewhat challenging to design because every execution step of the EVM must be metered by a "gas fee"; the first version of the EVM kept it simple by only allowing return data to be a fixed size. See these issues for background https://github.com/ethereum/solidity/issues/164 https://github.com/ethereum/solidity/issues/164 https://github.com/ethereum/EIPs/pull/211 https://github.com/ethereum/EIPs/pull/211 Also, the longer-term proposal is to adopt WebAssembly for EVM 2.0: https://github.com/ewasm/design https://github.com/ewasm/design. Then users can write contract code using any language with an llvm compiler (rust, ocaml, etc.).