It's interesting to see how the first virtualmachine specification for the first financial smart contract platform has overlooked all the pitfalls of the language-design industry and it doesn't look that a redesign is going to be addressed very soon because of the difficulty of the redeployment (as naturally backwards compatibility must be the first concern).
> Its hard to read the "I told you so replies", when the price of ETH has remained relatively stable during the news
Haha, so if the price is stable, this means that Solidity is not embarrassing? I'm sorry but this just means that people only care about security when their funds are the ones affected. Not about "potential" security problems or "design flaws" which sound too technical to them.
By the way, I went and looked at the offending contract. The pull request that introduced the line with the bug added 2228 new lines of code while removing 918 lines. In fact, the diff is so large that GitHub doesn't even show parts of it by default (including the part with the bug). The pull request was reviewed by a single other person, and committed on the same day it was submitted.
I don't think I'm comfortable with the barrier being that low, at all.
Not at all. Deconstruction of PL design is a popular pastime here.
> A common criticism is the way for loops and arrays are implemented are broken? Well actually they should rarely be used in contracts
If they cannot be used safely, they shouldn't be in a language.
If they can be used safely, but it requires caution and is to be rarely done, then the syntax should reflect that by not making it so easy to use them.
> Once again the type system doesn't need to be perfect, if your code on the blockchain is broken you pay a transaction fee and the contract doesn't execute it.
The type system enforces invariants that go beyond code being broken in a sense that it doesn't run. Sometimes broken code does run, with catastrophic consequences - remember Mars lander crash? That was one example of an error that could be prevented by a sufficiently advanced type system - in F#, for example, types can reflect units of measurement, and the language will plainly not allow you to do nonsensical things like add together feet and meters, without explicitly converting one way or the other.
By its very nature, smart contracts on a blockchain that deals with money have a huge potential for this sort of thing - a contract that doesn't trigger an error, but which silently behaves differently from what was intended by the author. The consequences, as we can see here, can be staggering, as in millions of dollars in damages.
It follows that the language that is used to write them should use every known mechanism to discover such errors early. This includes strong typing, immutability, explicitness, design by contract etc.
> For a language that was made less than 3 years ago
The language was not made in a vacuum 3 years ago. Other languages preceded it, and provided valuable lessons in PL design. Why these lessons weren't heeded is a reasonable question to ask.
A great motivation: it's always better to write half-assed implementations of rarely used features because they are rarely used.
> You do not need a complete language like F# and C++ to write contracts
Agreed. You need a small verifiable DSL, not an entire new language.
> Once again the type system doesn't need to be perfect
That's the spirit when designing a language!
> it amazing to see the progression
Well... yeah, if you started with the goal of executing without crashing it can only improve over time.
A common criticism is the way for loops and arrays are implemented are broken? Well actually they should rarely be used in contracts, its not like you can send ether/btc to an array recipients or in a for loop.
You do not need a complete language like F# and C++ to write contracts, The hacked contract should have had a simple modifier describing only the owner can run this command.
Once again the type system doesn't need to be perfect, if your code on the blockchain is broken you pay a transaction fee and the contract doesn't execute it.
For a language that was made less than 3 years ago, it amazing to see the progression. It will be a language that people hire for in the near future (already happening). Companies are notorious looking for 5 years experience.
Its hard to read the "I told you so replies", when the price of ETH has remained relatively stable during the news