4 ms·

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 writ

by ojr 9y ago

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 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

knocte 9y ago
> 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. 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.
- ojr 9y ago
  The language was not made from "scratch" but a progression from bitcoin scripts, Ethereum is the like to blockchain dev like Unity is to gamedev, it lowers the barrier to entry, it has a lot of the similar apis and functions as bitcoin, I don't really consider this a bad thing
  - int_19h 9y ago
    Do we really want to lower barrier to entry for writing code that can misdirect $30 million dollars just like that? 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.
    - peternicky 9y ago
      Can you please link to this pull request?
      - int_19h 9y ago
        https://github.com/paritytech/parity/blame/4c32177ef3f4521c663113749400f5a8b6f0e0d4/js/src/contracts/snippets/enhanced-wallet.sol#L216 https://github.com/paritytech/parity/blame/4c32177ef3f4521c6...
    - ojr 9y ago
      it was missing one keyword that was the parity bug not in the 2228 lines, and the DAO hack had a line that was place 3 lines too early, a monetary system created 3 years ago and is highly demanded might have some growing pains
rnhmjoj 9y ago
> for loops and arrays are implemented are broken? Well actually they should rarely be used 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.
int_19h 9y ago
> 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. 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.

by ojr 9y ago

knocte 9y ago

> 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. 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.

ojr 9y ago
The language was not made from "scratch" but a progression from bitcoin scripts, Ethereum is the like to blockchain dev like Unity is to gamedev, it lowers the barrier to entry, it has a lot of the similar apis and functions as bitcoin, I don't really consider this a bad thing
- int_19h 9y ago
  Do we really want to lower barrier to entry for writing code that can misdirect $30 million dollars just like that? 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.
  - peternicky 9y ago
    Can you please link to this pull request?
    - int_19h 9y ago
      https://github.com/paritytech/parity/blame/4c32177ef3f4521c663113749400f5a8b6f0e0d4/js/src/contracts/snippets/enhanced-wallet.sol#L216 https://github.com/paritytech/parity/blame/4c32177ef3f4521c6...
  - ojr 9y ago
    it was missing one keyword that was the parity bug not in the 2228 lines, and the DAO hack had a line that was place 3 lines too early, a monetary system created 3 years ago and is highly demanded might have some growing pains

rnhmjoj 9y ago

> for loops and arrays are implemented are broken? Well actually they should rarely be used 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.

int_19h 9y ago

> 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. 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.