Solidity is ostensibly designed to let people write smart contracts for Ethereum.

More realistically, it is a marketing tool for enabling and onboarding people onto the Ethereum platform, which Ethereum benefits monetarily (enormously so) from. Security and design are secondary goals to the extent that they help prevent disasters which hurt adoption or churn developers away.

Through this lens it's not a mystery why the language is "hacky". Perhaps being a good language is not even the driving goal.

Curious question of a non-native speaker: What does this phrase mean? (in general, and in this context)

+1 : My feelings after going thru basics of ethereum.

If they were to be as safe as possible, there would be less news, and they would push the traversal of those dialectics further into the history, when more people are using Ethereum and these kinds of events can do more damage.

It's beta. Don't worry about it. Come back in 10 years when the Heroku of Ethereum is released. Buy a couple Ethers now so you'll be rich then.

The problem is that it's just not easy to get all those details right from day 1, and interest in Ethereum has grown way faster than its capacity to produce a reliable, mature set of tools around it.

This is different from the kinds of objects that you would instantiate in a language like Java, where best practices suggest defining as immutable unless you have a good reason not to.

For starters, not all functions on the contract are supposed to be mutating. Marking those that are as such would catch accidental mistakes when unnecessary mutations happen.

Then there's the issue with structs, collections etc all also being mutable by default, which is separate of contracts.

Finally, none of this actually requires any mutability at all. A contract could treated as a pure function that takes initial state as input, and returns the new state as output. Such a function can be written without any mutations at all, by constructing the new state piece by piece from the old one.

Sure, it would be a more verbose (although functional languages usually offer shortcuts like "give me a copy of this object, but with these fields set to different values", making it not so verbose after all). But on the other hand, it means that you have to explicitly consider the effect of every operation of the contract on every bit of state. "Don't repeat yourself" is not always a good thing - when it comes to security, you often do actually want to make people do redundant things, e.g.: http://www.atlasobscura.com/articles/pointing-and-calling-ja....

Unsurprisingly, Tezos is actually written by OCaml people who seem to value the correctness of the contract language.

But not the kind of people you want to focus on to get traction for your venture-backed startup if you want a relatively quick and profitable exit

It's also quite hard for programmers to reason about performance or complexity in most functional languages. In the EVM, all functions should either be O(1) or bounded O(n) and should strive to use the most economical bytecode available to perform each task.

Disclaimer: I am a regular contributor to Solidity.

This is why I criticized the VM design as well as the language.

Yes, much effort went into making "cycle counting" as simple and straight forward as possible.

But I don't see any comparable effort doing the same for safety and correctness. (Apart from providing crypto primitives by the VM, which is neat, but only the tip of the iceberg in terms of language design.)

> It's also quite hard for programmers to reason about performance or complexity in most functional languages

This is true for Haskell, but "most" other functional languages don't suffer this issue: SML, OCaml, F#, Rust, etc.

Also note that lots of effort already went into creating lambda calculus variants where performance is especially easy to reason about. However, dismissing functional langauges as a whole already demonstrates that none that the research played any role in the design of EVM and Solidity.

In case you are interested, here is a nice starting point about the state of the art of 2014: "Structure and Efficiency of Computer Programs" https://www.cs.cmu.edu/~rwh/papers/secp/secp.pdf

I don't have much experience with the ML family of languages, so I may have jumped to conclusions based on my previous experience with Haskell/Elm, but I did not intend it to sound as a dismissal of functional languages at all.

In fact, there is a growing community of researchers working on functional language design for the EVM, but I would wager that it's way more complex to build such a compiler than something a bit more "close to the metal", 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.

Hindsight is 20/20.

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?

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.

Yet another data point for 'why a TC language is a bad choice for smart contracts'.

That would be cool. Even cooler would be if they created a code style culture around small contracts such that a contract should print out a legal-looking document with its own source code, when echoed to a printer.