4 ms·

Is it too late now? It seems to me that it should be possible to implement a better language on top of the existing system, there are plenty of languages that c

Is it too late now? It seems to me that it should be possible to implement a better language on top of the existing system, there are plenty of languages that compile to JavaScript after all, so it's still worth discussing what a better language might look like. You say Coq is expressive; okay, but in what sense, for what purposes? A language which isn't Turing complete - or even one which is - isn't going to be expressive for all purposes. As I understand it, Coq is designed to be expressive for the kind of things people doing research in type theory want to write, in the same way SQL is designed to be expressive for database queries. What sort of things do smart contracts typically want to say? Are they more similar to type theory research, database queries or something else? One possible answer is that it's too early to say yet, in which case perhaps extensibility is an important attribute. For example, suppose Racket were used as a language for writing smart contracts, with a backend to generate Ethereum byte code. Being a dialect of Lisp, Racket is highly extensible. It also has an optional type system. Do smart contracts tend to be prone to the kind of errors that are caught by a type system? If so, it would be worth using one.

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.

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.