3 ms·

Note that Solidity is not JavaScript, it's just superficially similar in some ways. The comparison with JavaScript is for marketing pretty much. In particular,

by mbrock 10y ago

Note that Solidity is not JavaScript, it's just superficially similar in some ways. The comparison with JavaScript is for marketing pretty much. In particular, Solidity is statically typed. I would say that smart contracts are a lot like event processors that update bits of contract-local state and enforce preconditions. They are run in a single "thread" in blockchain order, but they can also invoke each other reentrantly (and that's the major source of confusion so far, so it should be limited and made very explicit). Some contracts perform more complex calculations, e.g. I know of one that calculates compound interest using fixed point math. There might be room for several different simpler languages for different purposes... It would make sense to use the most restricted language that can express the contract you want.

rwallace 10y ago
From what I've seen of the discussion on this, you're right about uncontrolled reentrancy being a big source of problems. One thing that occurs to me: would the command-query distinction be a useful notion here? I have no truck with it in the general context in which it was coined, but in this context maybe it would be useful to draw a hard line distinction between 'I call you to ask for information' and 'I call you to ask for money'.
- mbrock 10y ago
  Solidity contracts can define "const" functions which aren't allowed to change state. For some uses you can also look at the events that a contract emits, which are indexed and searchable off-chain... so client apps can read them, but not contracts themselves.
  - rwallace 10y ago
    Okay, so const was available as a feature - but not used because it wasn't the default? Some of the discussion on this seems to be saying Solidity supports exceptions and transactions, which should provide a lot of safety here (on error, an exception should be thrown and everything the script just did should be rewound) but the documentation was still exhorting programmers to check return values all over the place. Is this at least in part a matter of bad defaults? I'd be quite prepared to believe so; bad defaults are a much bigger problem than they are sometimes thought to be.

by mbrock 10y ago

rwallace 10y ago

From what I've seen of the discussion on this, you're right about uncontrolled reentrancy being a big source of problems. One thing that occurs to me: would the command-query distinction be a useful notion here? I have no truck with it in the general context in which it was coined, but in this context maybe it would be useful to draw a hard line distinction between 'I call you to ask for information' and 'I call you to ask for money'.

mbrock 10y ago
Solidity contracts can define "const" functions which aren't allowed to change state. For some uses you can also look at the events that a contract emits, which are indexed and searchable off-chain... so client apps can read them, but not contracts themselves.
- rwallace 10y ago
  Okay, so const was available as a feature - but not used because it wasn't the default? Some of the discussion on this seems to be saying Solidity supports exceptions and transactions, which should provide a lot of safety here (on error, an exception should be thrown and everything the script just did should be rewound) but the documentation was still exhorting programmers to check return values all over the place. Is this at least in part a matter of bad defaults? I'd be quite prepared to believe so; bad defaults are a much bigger problem than they are sometimes thought to be.