4 ms·

The programming classic "Mythical Man Month" had a chapter for the "second system effect". Its where developers put lots of complicated features in to the secon

The programming classic "Mythical Man Month" had a chapter for the "second system effect". Its where developers put lots of complicated features in to the second system in a series. Its a pattern for failure. In this case, Ethereum developers built a much more complicated cryptocurrency by making it Turing complete - to the extent of writing their own new computer language and virtual machine to run it. They skipped over the halfway step of declaring parameters in the payment transactions, that open source enterprise library code, e.g. Java, could execute for for required behavior. No. They made the new code itself a user-contributed and immutable! part of the system.

viraptor 10y ago
That's actually a pretty good decision in my opinion. At least in this case. Think what would happen if they went for alternative solutions: 1. If it wasn't immutable, you'd never be sure when a contract changes. That's the basic assumption about contract - once you sign it, whether in real world, or by doing some action in Ethereum, you don't expect it to change how it works. That's why immutable is good. 2. User-contributed is just how it's supposed to work. It's decentralised. Everyone's a user. The content has to be user-contributed. Having some central publisher/gatekeeper is contrary to the whole idea. 3. Own VM is debatable. Sure, they could go with JVM, but the scope would have to include much more complexity (classes, namespaces, etc.) than just function/instruction execution. Maybe the limits of javacard would be enough, maybe not. I really don't think the second system effect applies here. It's not a rewrite of something that existed and had issues.
- yawaramin 10y ago
  Solidity contracts are already modules which contain functions. They're equivalent to Java classes with static methods or Scala objects. As for namespacing, I don't know how in this day and age programmers can say that's not worth it.
  - viraptor 10y ago
    Solidity contracts do contain functions and some state. But that's at a fairly different level than Java's classes. Internals are not exported. The contract's structs belong to contracts. There's no need for namespaces within code because addresses provides namespacing already - all your code is normally visible to you already and you'll not get unexpected names shadowing anything in your code. I'm not saying namespacing is bad, just that namespacing as defined in Java is likely not necessary in ethereum world, as I understand it. It would likely just confuse what's immutable vs what's referenced by name.
dasil003 10y ago
Is it a case of Second System Effect, or Build One to Throw Away? I don't have an opinion either way, but just pointing out that the very same pattern is also known as a successful one in some cases.
- sp332 10y ago
  Build one to throw away means you're building the same "system" again, but with more specific requirements based on what you learned. Second system effect is building a bigger system will broader and vaguer requirements. (Also, Brooks later said: "This I now perceived to be wrong, not because it is too radical, but because it is too simplistic. The biggest mistake in the 'Build one to throw away' concept is that it implicitly assumes the classical sequential or waterfall model of software construction." He wrote a later book, The Design of Design, encouraging iterative development.)
maxander 10y ago
Turing-completeness was the entire conceit of Ethereum, as I understand it- without that you would have Bitcoin with a few bells and whistles, and no one would bother. And once you're committed to that, a new language and environment are essential- something this entire fiasco shows is that a language for contract programming has very different requirements than what software engineers are currently used to, in order to be safe in ways that don't apply to ordinary software. In all likelihood, a working and reliable Ethereum simply requires computer science theories we don't have yet. A working Solidity would probably look something like Ada, but with types and invariants the likes of which we've never seen. Its potentially a very interesting research subject! But for now, yes, investing in Ethereum is like climbing aboard in a rocket aimed at Mars- exciting and futuristic, but unlikely to get you where you hope to go.
- dvdkhlng 10y ago
  I think we have a lot of theory about turing-complete computation. I really wonder why somebody would be willing to sign a turing-complete contract? The problem of understanding properties of the contract may be NP-hard [1] i.e. practicallly uncomputable. It may even be undecidable by involving instances of the halting problem [2]. [1] https://en.wikipedia.org/wiki/NP-hardness https://en.wikipedia.org/wiki/NP-hardness [2] https://en.wikipedia.org/wiki/Halting_problem https://en.wikipedia.org/wiki/Halting_problem
  - danbruc 10y ago
    It is undecidable in the general case as shown by Rice's theorem [1]. [...] Rice's Theorem may essentially be generalized from Turing machines to most computer programming languages: there exists no automatic method that decides with generality non-trivial questions on the behavior of computer programs. [1] https://en.wikipedia.org/wiki/Rice%27s_theorem https://en.wikipedia.org/wiki/Rice%27s_theorem
    - mbrock 10y ago
      Of course, that doesn't mean you can't prove anything. It just means you can't prove things generally and automatically. For example, you can't solve the halting problem in general, but you can most definitely prove that a specific program terminates, or that large classes of programs all terminate. The proof of Rice's theorem boils down to the impossibility of the halting problem. The parent comment asks why someone would agree to a "Turing complete contract". But it's not necessary for an Ethereum contract to be "Turing complete" any more than Quicksort is "Turing complete". If the contract's code does something simple, we can verify and prove that it behaves as expected. It wouldn't be impossible to create a "safe" DAO-like contract.

viraptor 10y ago

That's actually a pretty good decision in my opinion. At least in this case. Think what would happen if they went for alternative solutions: 1. If it wasn't immutable, you'd never be sure when a contract changes. That's the basic assumption about contract - once you sign it, whether in real world, or by doing some action in Ethereum, you don't expect it to change how it works. That's why immutable is good. 2. User-contributed is just how it's supposed to work. It's decentralised. Everyone's a user. The content has to be user-contributed. Having some central publisher/gatekeeper is contrary to the whole idea. 3. Own VM is debatable. Sure, they could go with JVM, but the scope would have to include much more complexity (classes, namespaces, etc.) than just function/instruction execution. Maybe the limits of javacard would be enough, maybe not. I really don't think the second system effect applies here. It's not a rewrite of something that existed and had issues.

yawaramin 10y ago
Solidity contracts are already modules which contain functions. They're equivalent to Java classes with static methods or Scala objects. As for namespacing, I don't know how in this day and age programmers can say that's not worth it.
- viraptor 10y ago
  Solidity contracts do contain functions and some state. But that's at a fairly different level than Java's classes. Internals are not exported. The contract's structs belong to contracts. There's no need for namespaces within code because addresses provides namespacing already - all your code is normally visible to you already and you'll not get unexpected names shadowing anything in your code. I'm not saying namespacing is bad, just that namespacing as defined in Java is likely not necessary in ethereum world, as I understand it. It would likely just confuse what's immutable vs what's referenced by name.

dasil003 10y ago

Is it a case of Second System Effect, or Build One to Throw Away? I don't have an opinion either way, but just pointing out that the very same pattern is also known as a successful one in some cases.

sp332 10y ago
Build one to throw away means you're building the same "system" again, but with more specific requirements based on what you learned. Second system effect is building a bigger system will broader and vaguer requirements. (Also, Brooks later said: "This I now perceived to be wrong, not because it is too radical, but because it is too simplistic. The biggest mistake in the 'Build one to throw away' concept is that it implicitly assumes the classical sequential or waterfall model of software construction." He wrote a later book, The Design of Design, encouraging iterative development.)

maxander 10y ago

Turing-completeness was the entire conceit of Ethereum, as I understand it- without that you would have Bitcoin with a few bells and whistles, and no one would bother. And once you're committed to that, a new language and environment are essential- something this entire fiasco shows is that a language for contract programming has very different requirements than what software engineers are currently used to, in order to be safe in ways that don't apply to ordinary software. In all likelihood, a working and reliable Ethereum simply requires computer science theories we don't have yet. A working Solidity would probably look something like Ada, but with types and invariants the likes of which we've never seen. Its potentially a very interesting research subject! But for now, yes, investing in Ethereum is like climbing aboard in a rocket aimed at Mars- exciting and futuristic, but unlikely to get you where you hope to go.

dvdkhlng 10y ago
I think we have a lot of theory about turing-complete computation. I really wonder why somebody would be willing to sign a turing-complete contract? The problem of understanding properties of the contract may be NP-hard [1] i.e. practicallly uncomputable. It may even be undecidable by involving instances of the halting problem [2]. [1] https://en.wikipedia.org/wiki/NP-hardness https://en.wikipedia.org/wiki/NP-hardness [2] https://en.wikipedia.org/wiki/Halting_problem https://en.wikipedia.org/wiki/Halting_problem
- danbruc 10y ago
  It is undecidable in the general case as shown by Rice's theorem [1]. [...] Rice's Theorem may essentially be generalized from Turing machines to most computer programming languages: there exists no automatic method that decides with generality non-trivial questions on the behavior of computer programs. [1] https://en.wikipedia.org/wiki/Rice%27s_theorem https://en.wikipedia.org/wiki/Rice%27s_theorem
  - mbrock 10y ago
    Of course, that doesn't mean you can't prove anything. It just means you can't prove things generally and automatically. For example, you can't solve the halting problem in general, but you can most definitely prove that a specific program terminates, or that large classes of programs all terminate. The proof of Rice's theorem boils down to the impossibility of the halting problem. The parent comment asks why someone would agree to a "Turing complete contract". But it's not necessary for an Ethereum contract to be "Turing complete" any more than Quicksort is "Turing complete". If the contract's code does something simple, we can verify and prove that it behaves as expected. It wouldn't be impossible to create a "safe" DAO-like contract.