3 ms·
My impression from all of this is simply that the tools (and perhaps the etherium op codes themselves) for writing smart contracts still need work. When progra
by codys 10y ago
My impression from all of this is simply that the tools (and perhaps the etherium op codes themselves) for writing smart contracts still need work.
When programming for hardware began, it was very easy to shoot yourself in the foot with languages of the time, but over time new languages which made it harder (or eliminated certain foot-guns entirely) appeared.
For Etherium, I'd look at whether the ISA (set of opcodes) is complete enough to allow one to create a contract specification language with enough flexibility to do something while allowing a degree a safety.
Have there been attempts at alternates to Etherium's Solidity which generate smart contracts?
- drcode 10y agoThere have been many other languages before solidity (LLL, Serpent, others) Solidity is actually pretty well engineered, it is problematic mainly because it put beginner-friendliness before security as a design goal. I think the future the ethereum smart contract options will consist of (1) Solidity with many static analysis tests added to generate warnings about dangerous code use and (2) an ML-style language that is less novice-friendly but allows for deep type-level constraints to mitigate potential attack scenarios.