Just skimming through the Solidity docs, I see a lot of unwise decisions there aside from the weird visibility defaults. All state is mutable by default (this includes struct fields, array elements, and locals). Functions can mutate state by default. Both are overridable by explicit specifiers, much like C++ "const", but you have to remember to do so. Even then, the current implementation doesn't enforce this for fun…
It is interesting to see but I think Solidity is the first software language/framework that people with no experience writing it or running it, comment and write about it on hackernews as if they did. 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 n…
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.