7 ms·

Why would an unmarked function get the broadest possible scope in a language designed for contracts? I'm always surprised by the decisions made around Ethereum,

by dvcc 9y ago

Why would an unmarked function get the broadest possible scope in a language designed for contracts? I'm always surprised by the decisions made around Ethereum, and just how much value people have poured into it.

TylerE 9y ago
Because the cryptocurrency space attracts only the brightest minds.
- wheelerwj 9y ago
  i know that you're not really serious when you generalize against all of us crypto simpletons, but anytime theres a stupid amount of money on the table people are bound to rush to pick it up. and that means mistakes. the work being done on public blockchains is unlike anything else done before. You don't have he luxury of keeping your db behind a vpn running on a vm platform secured and maintained by the worlds largest companies. These engineers put themselves out there, waaaaaaaay out there to try and make shit happen. And they mostly do good work. But if banks and major retailers who have huge budgets can get hacked, of course we can too.
  - kbenson 9y ago
    I think a big part of the complaint is about the implicit assumption that because people are smart, and have experience with cryptography, they necessarily have the experience to design a sane and safe programming language given their goals. They did put themselves way out there, and that takes ambition, but also hubris. I wish they were able to figure out which one was driving them at certain points a bit better, as while some of these problems are because they are doing new and interesting things, some are old as dirt for computing, and there's little defense. If some company tried to tout a new language with all the pitfalls of C, but none of the benefits of being really inter-operable and known the same way, I'd like to think we could recognize that as having some very bad design choices given what we've learned from C, and at little benefit other than being different. Ignoring decades of research and experience on the topic through ignorance is not laudable, even if you've put yourself out there. I can't help but feel we have a similar scenario going on here.
    - davidgerard 9y ago
      Actually, I think Solidity being designed to turn bad node.js coders into bad smart contract coders was key to Ethereum's success. I've written a book on this (hit upload five minutes ago! release Monday!) which hammers on this point (and all the stuff surrounding this issue). I think Solidity is actually designed with worse is better in mind, because Ethereum is the first smart contract platform that anyone actually used. Some tried doing them in Bitcoin, but Ethereum's the first that gets lots of action. And so many other blockchains lift the smart contract functionality straight from Ethereum.
      - kbenson 9y ago
        That may be, but if so, it might be worse. What's worse, not getting a lot of uptake for this idea that's been hard going for others, or getting the uptake because of trade-offs you made that make it a ticking time-bomb that may damage the reputation of the idea for years to come and set it back?
        dahdum 9y ago
        Solidity is like PHP in the 90's, easy to learn and easy to screw up. Though Solidity just compiles to the EVM, and there is no reason new, safer languages can't be built on top. As far as I can remember, the EVM has never failed, just programmers.
        kbenson 9y ago
        That comparison may be apt. PHP at that time was a mix of some good ideas (ease of deployment) with some horrible ones (register globals on by default is unexcusable), and some poor planning. We all lived with the fallout of that for a very long time. The register globals issue could have been avoided at very little cost, if any cost at all, to the popularity and spread of the language and many millions of dollars and much personal information would have been saved.
        shp0ngle 9y ago
        I disagree, Solidity is really not easy to learn. It is easy to screw up, though.
  - eropple 9y ago
    One of the more important skills in this craft is the combination of intuition and knowledge to know when you don't know something well enough to achieve the goal. The difference between "ambition" and "hubris" is small but critical.
    - wheelerwj 9y ago
      That's a valid point. But its hard to be humble when you work on something that was designed to topple national banks.
      - eropple 9y ago
        Then you shouldn't be working on it. If you can't be humble, you should not be working on things that can hurt people because you're creating risk for them that they can't actually measure. (It's why I consciously avoid such projects; knowing one's propensity to arrogance makes it unethical not to.) If it's important, you need to be good. If it's very important, you need to be good and sure.
        wheelerwj 9y ago
        I don't disagree, it's just easier said than done.
  - moeop 9y ago
    These mistakes are predictable and inexcusable. The Ethereum developers sold a vision of smart contracts, where the code is the contract. However, their hubris lead to them attempting to implement a complex language, instead of starting the endeavor with a small, simple, verifiable language. Similarly, their belief in their own infallibility lead them to write code that is not tested, and to create capabilities that are literally untestable. This was bound to result in multiple massive failures. The dao was one. This is another. There will be more, because it's an overly complex implementation. It doesn't matter, though. Only dumb-fuck crypto futurist suckers have ether exposure, so it won't matter that they get zero'd out once a competent team enters the space. That said, the space attracts incompetence like lights attract moths, so it'll take a while to find a team that is technically competent and also has the marketing chops to get traction.
    - wheelerwj 9y ago
      you don't think 200m ico's counts as marketing traction? This space doesn't atract incompetence, it atracts everyone. When you have tech thats so transparent and accessible, degrees and diplomas don't get to decide who can or cannot work on it. Plus, the world most experience blockchain developer has at most, 9 years of experience. That's not a lot of time to work out the kinks.
    - youdontknowtho 9y ago
      I like your point about language complexity. Can you point to a language that would fit the simple and verified criteria? I don't really follow the subject, so it would be interesting reading.
      - munin 9y ago
        You could take inspiration from a system like Dafny or F-* and write your contracts with the assistance of a type system and compiler that generated proofs that your contracts satisfied some postcondition given a precondition. People have already written moderately complicated applications like operating systems in these languages, so there's some evidence they could be applied to contracts on the blockchain.
  - geofft 9y ago
    > But if banks and major retailers who have huge budgets can get hacked, of course we can too. Here's the thing: banks and major retailers can't get hacked. At least, not in the sense you're using "hacked". When Target's credit card systems were compromised, resulting in the CEO resigning and and about $300M in costs to the company to deal with the breach, not one customer lost a penny. When $171M from Union Bank of India was fraudulently wired via NYC to two Cambodian banks and one Thai one, they got all the money wired back within a day. The traditional banking system is designed to be unhackable, because the numbers on computers are not authoritative. They're a cache, and they're periodically reconciled, but humans (and other computers!) will look at the cache during reconciliation for obvious attacks like these. A bank can call up another bank, or a retailer can call up a credit card company, or whatever, and say, "Hey, these transactions were fraudulent, please reverse them," and it'll happen. Target did that. Union Bank did that. A hacker can get to some bank's MySQL database? Sure, whatever, it's not what matters. Definitely it's a greater headache than if they got to the bank's website, but at the end of the day it's exactly as fixable as hackers getting to the website. There are a lot of bright people trying very hard and putting honest work into a problem that simply doesn't need to be solved and shouldn't be solved: making the computers authoritative. When you do that, you're suddenly hackable. When you do that, of course $16M gets actually stolen irrevocably from time to time, no matter how bright you are or how honest your work is.
    - nipponese 9y ago
      From this and your previous comments, I am trying to figure out your basic point. Would you summarize it as, "I have a low tolerance for financial risk and others should think as I do"?
      - geofft 9y ago
        I don't think that's a good way to summarize my point - I have expressed no opinion about financial risk, either my own or others. (Did you mean to address someone else?) However, whatever financial risk you would like to tolerate, you should make sure you're pursuing goals that do in fact match that financial risk, and that you're not concluding that something more or less risky than it is because you are uninformed. Also, if you are tolerating increased risk, you should do so because there is a purpose for it (e.g, better potential upside), not because high financial risk seems inherently cool. It isn't, and I will certainly defend that point, but it's just a lemma on the way to my actual point. Arguing that it's okay that cryptocurrencies are hackable because the traditional financial system is hackable is simply factually incorrect: it's a misunderstanding of why the existing financial system looks the way it does, and why its risk tolerances are built the way it is (not a lot done to secure transactions, but a lot done to be able to reverse transactions if needed). If you really want a simple point out of me, I think G. K. Chesterton made it in 1929: > In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it." If you do not understand the existing financial system, you cannot honestly claim that your new one is better. First figure out how it works and why, and get that right, then you can describe how your changes are improvements.
  - shp0ngle 9y ago
    The thing is, cryprocurrency people usually think of themselves as smarter and better programmers than the rest of us. They even co-opted the term "crypto" to mean their toy currencies instead of actual real life, useful cryptography. But yeah I admit, cryprocurrencies are good toy projects on which to learn real crypto, that's true. But then it's time to move on. And not to pour millions of dollars into that
- PhasmaFelis 9y ago
  My favorite smack-talk so far is "Dunning-Krugerrands".
  - i_am_nomad 9y ago
    That is certified brilliant.
  - kcanini 9y ago
    That pun is golden.
    - posterboy 9y ago
      would've missed it, thx
- dang 9y ago
  Would you please stop posting snarky and/or uncivil and/or unsubstantive comments? especially on divisive topics? You've done this repeatedly, it lowers the quality of discussion, and we're hoping for better than that here. If you have a substantive point to make, make it thoughtfully; otherwise please don't comment until you do.
- honestoHeminway 9y ago
  If you have such a bright mind, you often need a dark hat, to avoid blinding the others.
elviejo 9y ago
For the same reason every variable in JavaScript is global by default... I.e. I don't have a clue how that could seem like a good idea.
- koolba 9y ago
  That's not how JavaScript works. Variable declarations are hoisted to the start of the enclosing function scope and only undeclared variables are global by default. But yes it seems pretty asinine to use global by default for (not so) smart contracts.
  - Klathmon 9y ago
    And even that undeclared-are-global thing is gone in modern js. It's explicitly an error in strict mode.
  - saurik 9y ago
    Another way of describing that is that variables are global (scoped to the lobby, to borrow a term from the languages which came before JavaScript) unless explicitly marked with the "var" keyword, which has semantics that some languages might have chosen to give the name "local". Like: your entire premise that a variable is only the declared variables makes no sense to me as someone who teaches college-level classes in programming languages. In Python variables default to local unless marked "global". In JavaScript, variables default to captured via scope unless marked "var".
  - oelmekki 9y ago
    Well, if they are global when they are undeclared, that pretty much means they are global by default. Maybe a better way of putting it would be "js variables are declared global by default, when unspecified and not using strict mode". Anyway, I think parent's point was to say this behavior already has been seen in javascript. Actually, it may even be inherited from javascript. When I first looked at solidity last year, I was under the impression it was a modified version of javascript, like unity3d's one. Nowadays, solidity landing page reads "high-level language whose syntax is similar to that of JavaScript", so not sure if it still is (or has ever been, for the matter) derived from something like v8 or rhino. The reason for that choice seems not far fetched : it's not uncommon, when wanting to add scripting to something, to go with javascript, since it's arguably the most known language, developers knowing "<their main language> and javascript", especially webdevs (a blockchain app project, lisk, even made html/css/js the defacto mean to build apps). Of course, fintech is an industry where the usual values from webdev (release early, release often) have disastrous results.
deleted 9y ago
[deleted]
lomnakkus 9y ago
It's a good indicator that these people may be experts in one area, but not necessarily in others. Language design is actually notoriously difficult in general[1], but if you're doing language design for a security-critical language[2]... well, that requires actual mechanized proof, IMO. Not just proof of "design", but proof of the implementation. Anything else is a huge gamble. (And I'm sure there are some 'investors'/gamblers who made off very well.) [1] Beyond surface-level, obviously. [2] We're talking about 0.0001% of the general population here.
- Claire88 9y ago
  my stepmother recently got a nice twelve month old Nissan Rogue SUV only from working part time off a macbook air. visit this page>>>>>>>>http://www.joinmate2.com http://www.joinmate2.com chek it site.
- buckie 9y ago
  > Not just proof of "design", but proof of the implementation. Absolutely, few people really get this. Even those that do get it generally don't know what it looks like in practice because it's so rare. In case you're curious about what it looks like in practice (at least one way), we presented direct user code compilation and verification[1] in Jan for our smart contract language Pact[2]. The idea that you can write a doc test that triggers a formal verification about some aspect of your code is, for lack of a better term, strange and yet the power to weight ratio is just off the charts. For the first few days that the system started working (I built the FV portion, Stuart the language + H-M type system) I thought it was broken... turned out we just had a bug in our demo code that we never noticed. Usually, tests check the things you know to check so when they find something it's not a surprise what they find. Sometimes you can fuzz and randomly find something, which is cool but doesn't guarantee that there isn't a problem somewhere else. However, FV just feels uncanny (as a dev) because the test either finds a problem in the code -- and tells you how to replicate the bug -- OR proves that a problem cannot exist. [1]: https://youtu.be/Nw1glriQYP8?t=1071 https://youtu.be/Nw1glriQYP8?t=1071 [2]: kadena.io/pact
  - lomnakkus 9y ago
firebones 9y ago
Read the Solidity documentation on visibility [1]. Public, private, internal, external, that really seem to mix overlapping concerns. In the visibility documentation, it explains that the default is public. Then, in another section of the documentation, when talking about function types [2], not specifying internal or external defaults visibility to internal. It doesn't seem like the simplest or most consistent way to express these concepts, and certainly not the safest way. [1] http://solidity.readthedocs.io/en/develop/contracts.html#visibility-and-getters http://solidity.readthedocs.io/en/develop/contracts.html#vis... [2] http://solidity.readthedocs.io/en/develop/types.html#function-types http://solidity.readthedocs.io/en/develop/types.html#functio...
imron 9y ago
Imagine the court case: Your honour, in my defence, the contract clearly specified that anyone could reset the wallet, and if that's not what they wanted, they shouldn't have agreed to it.
- blunte 9y ago
  I cannot imagine the court case. The courts are utterly incapable of understanding enough of the technical aspects of far simpler software cases. So like most court cases, it will simply be a matter of human influence winning the case.
  - macmac 9y ago
    If you are interested in a really good counter example to your assertion you should look at Judge Alsup https://www.techdirt.com/articles/20170325/23492137003/judge-alsup-wants-uber-waymo-to-teach-him-how-to-lidar-prior-to-self-driving-car-case.shtml https://www.techdirt.com/articles/20170325/23492137003/judge...

by dvcc 9y ago

TylerE 9y ago

Because the cryptocurrency space attracts only the brightest minds.

wheelerwj 9y ago
i know that you're not really serious when you generalize against all of us crypto simpletons, but anytime theres a stupid amount of money on the table people are bound to rush to pick it up. and that means mistakes. the work being done on public blockchains is unlike anything else done before. You don't have he luxury of keeping your db behind a vpn running on a vm platform secured and maintained by the worlds largest companies. These engineers put themselves out there, waaaaaaaay out there to try and make shit happen. And they mostly do good work. But if banks and major retailers who have huge budgets can get hacked, of course we can too.
- kbenson 9y ago
  I think a big part of the complaint is about the implicit assumption that because people are smart, and have experience with cryptography, they necessarily have the experience to design a sane and safe programming language given their goals. They did put themselves way out there, and that takes ambition, but also hubris. I wish they were able to figure out which one was driving them at certain points a bit better, as while some of these problems are because they are doing new and interesting things, some are old as dirt for computing, and there's little defense. If some company tried to tout a new language with all the pitfalls of C, but none of the benefits of being really inter-operable and known the same way, I'd like to think we could recognize that as having some very bad design choices given what we've learned from C, and at little benefit other than being different. Ignoring decades of research and experience on the topic through ignorance is not laudable, even if you've put yourself out there. I can't help but feel we have a similar scenario going on here.
  - davidgerard 9y ago
    Actually, I think Solidity being designed to turn bad node.js coders into bad smart contract coders was key to Ethereum's success. I've written a book on this (hit upload five minutes ago! release Monday!) which hammers on this point (and all the stuff surrounding this issue). I think Solidity is actually designed with worse is better in mind, because Ethereum is the first smart contract platform that anyone actually used. Some tried doing them in Bitcoin, but Ethereum's the first that gets lots of action. And so many other blockchains lift the smart contract functionality straight from Ethereum.
    - kbenson 9y ago
      That may be, but if so, it might be worse. What's worse, not getting a lot of uptake for this idea that's been hard going for others, or getting the uptake because of trade-offs you made that make it a ticking time-bomb that may damage the reputation of the idea for years to come and set it back?
      - dahdum 9y ago
        Solidity is like PHP in the 90's, easy to learn and easy to screw up. Though Solidity just compiles to the EVM, and there is no reason new, safer languages can't be built on top. As far as I can remember, the EVM has never failed, just programmers.
        kbenson 9y ago
        That comparison may be apt. PHP at that time was a mix of some good ideas (ease of deployment) with some horrible ones (register globals on by default is unexcusable), and some poor planning. We all lived with the fallout of that for a very long time. The register globals issue could have been avoided at very little cost, if any cost at all, to the popularity and spread of the language and many millions of dollars and much personal information would have been saved.
        shp0ngle 9y ago
        I disagree, Solidity is really not easy to learn. It is easy to screw up, though.
- eropple 9y ago
  One of the more important skills in this craft is the combination of intuition and knowledge to know when you don't know something well enough to achieve the goal. The difference between "ambition" and "hubris" is small but critical.
  - wheelerwj 9y ago
    That's a valid point. But its hard to be humble when you work on something that was designed to topple national banks.
    - eropple 9y ago
      Then you shouldn't be working on it. If you can't be humble, you should not be working on things that can hurt people because you're creating risk for them that they can't actually measure. (It's why I consciously avoid such projects; knowing one's propensity to arrogance makes it unethical not to.) If it's important, you need to be good. If it's very important, you need to be good and sure.
      - wheelerwj 9y ago
        I don't disagree, it's just easier said than done.
- moeop 9y ago
  These mistakes are predictable and inexcusable. The Ethereum developers sold a vision of smart contracts, where the code is the contract. However, their hubris lead to them attempting to implement a complex language, instead of starting the endeavor with a small, simple, verifiable language. Similarly, their belief in their own infallibility lead them to write code that is not tested, and to create capabilities that are literally untestable. This was bound to result in multiple massive failures. The dao was one. This is another. There will be more, because it's an overly complex implementation. It doesn't matter, though. Only dumb-fuck crypto futurist suckers have ether exposure, so it won't matter that they get zero'd out once a competent team enters the space. That said, the space attracts incompetence like lights attract moths, so it'll take a while to find a team that is technically competent and also has the marketing chops to get traction.
  - wheelerwj 9y ago
    you don't think 200m ico's counts as marketing traction? This space doesn't atract incompetence, it atracts everyone. When you have tech thats so transparent and accessible, degrees and diplomas don't get to decide who can or cannot work on it. Plus, the world most experience blockchain developer has at most, 9 years of experience. That's not a lot of time to work out the kinks.
  - youdontknowtho 9y ago
    I like your point about language complexity. Can you point to a language that would fit the simple and verified criteria? I don't really follow the subject, so it would be interesting reading.
    - munin 9y ago
      You could take inspiration from a system like Dafny or F-* and write your contracts with the assistance of a type system and compiler that generated proofs that your contracts satisfied some postcondition given a precondition. People have already written moderately complicated applications like operating systems in these languages, so there's some evidence they could be applied to contracts on the blockchain.
- geofft 9y ago
  > But if banks and major retailers who have huge budgets can get hacked, of course we can too. Here's the thing: banks and major retailers can't get hacked. At least, not in the sense you're using "hacked". When Target's credit card systems were compromised, resulting in the CEO resigning and and about $300M in costs to the company to deal with the breach, not one customer lost a penny. When $171M from Union Bank of India was fraudulently wired via NYC to two Cambodian banks and one Thai one, they got all the money wired back within a day. The traditional banking system is designed to be unhackable, because the numbers on computers are not authoritative. They're a cache, and they're periodically reconciled, but humans (and other computers!) will look at the cache during reconciliation for obvious attacks like these. A bank can call up another bank, or a retailer can call up a credit card company, or whatever, and say, "Hey, these transactions were fraudulent, please reverse them," and it'll happen. Target did that. Union Bank did that. A hacker can get to some bank's MySQL database? Sure, whatever, it's not what matters. Definitely it's a greater headache than if they got to the bank's website, but at the end of the day it's exactly as fixable as hackers getting to the website. There are a lot of bright people trying very hard and putting honest work into a problem that simply doesn't need to be solved and shouldn't be solved: making the computers authoritative. When you do that, you're suddenly hackable. When you do that, of course $16M gets actually stolen irrevocably from time to time, no matter how bright you are or how honest your work is.
  - nipponese 9y ago
    From this and your previous comments, I am trying to figure out your basic point. Would you summarize it as, "I have a low tolerance for financial risk and others should think as I do"?
    - geofft 9y ago
      I don't think that's a good way to summarize my point - I have expressed no opinion about financial risk, either my own or others. (Did you mean to address someone else?) However, whatever financial risk you would like to tolerate, you should make sure you're pursuing goals that do in fact match that financial risk, and that you're not concluding that something more or less risky than it is because you are uninformed. Also, if you are tolerating increased risk, you should do so because there is a purpose for it (e.g, better potential upside), not because high financial risk seems inherently cool. It isn't, and I will certainly defend that point, but it's just a lemma on the way to my actual point. Arguing that it's okay that cryptocurrencies are hackable because the traditional financial system is hackable is simply factually incorrect: it's a misunderstanding of why the existing financial system looks the way it does, and why its risk tolerances are built the way it is (not a lot done to secure transactions, but a lot done to be able to reverse transactions if needed). If you really want a simple point out of me, I think G. K. Chesterton made it in 1929: > In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it." If you do not understand the existing financial system, you cannot honestly claim that your new one is better. First figure out how it works and why, and get that right, then you can describe how your changes are improvements.
- shp0ngle 9y ago
  The thing is, cryprocurrency people usually think of themselves as smarter and better programmers than the rest of us. They even co-opted the term "crypto" to mean their toy currencies instead of actual real life, useful cryptography. But yeah I admit, cryprocurrencies are good toy projects on which to learn real crypto, that's true. But then it's time to move on. And not to pour millions of dollars into that
PhasmaFelis 9y ago
My favorite smack-talk so far is "Dunning-Krugerrands".
- i_am_nomad 9y ago
  That is certified brilliant.
- kcanini 9y ago
  That pun is golden.
  - posterboy 9y ago
    would've missed it, thx
dang 9y ago
Would you please stop posting snarky and/or uncivil and/or unsubstantive comments? especially on divisive topics? You've done this repeatedly, it lowers the quality of discussion, and we're hoping for better than that here. If you have a substantive point to make, make it thoughtfully; otherwise please don't comment until you do.
honestoHeminway 9y ago
If you have such a bright mind, you often need a dark hat, to avoid blinding the others.

elviejo 9y ago

For the same reason every variable in JavaScript is global by default... I.e. I don't have a clue how that could seem like a good idea.

koolba 9y ago
That's not how JavaScript works. Variable declarations are hoisted to the start of the enclosing function scope and only undeclared variables are global by default. But yes it seems pretty asinine to use global by default for (not so) smart contracts.
- Klathmon 9y ago
  And even that undeclared-are-global thing is gone in modern js. It's explicitly an error in strict mode.
- saurik 9y ago
  Another way of describing that is that variables are global (scoped to the lobby, to borrow a term from the languages which came before JavaScript) unless explicitly marked with the "var" keyword, which has semantics that some languages might have chosen to give the name "local". Like: your entire premise that a variable is only the declared variables makes no sense to me as someone who teaches college-level classes in programming languages. In Python variables default to local unless marked "global". In JavaScript, variables default to captured via scope unless marked "var".
- oelmekki 9y ago
  Well, if they are global when they are undeclared, that pretty much means they are global by default. Maybe a better way of putting it would be "js variables are declared global by default, when unspecified and not using strict mode". Anyway, I think parent's point was to say this behavior already has been seen in javascript. Actually, it may even be inherited from javascript. When I first looked at solidity last year, I was under the impression it was a modified version of javascript, like unity3d's one. Nowadays, solidity landing page reads "high-level language whose syntax is similar to that of JavaScript", so not sure if it still is (or has ever been, for the matter) derived from something like v8 or rhino. The reason for that choice seems not far fetched : it's not uncommon, when wanting to add scripting to something, to go with javascript, since it's arguably the most known language, developers knowing "<their main language> and javascript", especially webdevs (a blockchain app project, lisk, even made html/css/js the defacto mean to build apps). Of course, fintech is an industry where the usual values from webdev (release early, release often) have disastrous results.

deleted 9y ago

[deleted]

lomnakkus 9y ago

It's a good indicator that these people may be experts in one area, but not necessarily in others. Language design is actually notoriously difficult in general[1], but if you're doing language design for a security-critical language[2]... well, that requires actual mechanized proof, IMO. Not just proof of "design", but proof of the implementation. Anything else is a huge gamble. (And I'm sure there are some 'investors'/gamblers who made off very well.) [1] Beyond surface-level, obviously. [2] We're talking about 0.0001% of the general population here.

Claire88 9y ago
my stepmother recently got a nice twelve month old Nissan Rogue SUV only from working part time off a macbook air. visit this page>>>>>>>>http://www.joinmate2.com http://www.joinmate2.com chek it site.
buckie 9y ago
> Not just proof of "design", but proof of the implementation. Absolutely, few people really get this. Even those that do get it generally don't know what it looks like in practice because it's so rare. In case you're curious about what it looks like in practice (at least one way), we presented direct user code compilation and verification[1] in Jan for our smart contract language Pact[2]. The idea that you can write a doc test that triggers a formal verification about some aspect of your code is, for lack of a better term, strange and yet the power to weight ratio is just off the charts. For the first few days that the system started working (I built the FV portion, Stuart the language + H-M type system) I thought it was broken... turned out we just had a bug in our demo code that we never noticed. Usually, tests check the things you know to check so when they find something it's not a surprise what they find. Sometimes you can fuzz and randomly find something, which is cool but doesn't guarantee that there isn't a problem somewhere else. However, FV just feels uncanny (as a dev) because the test either finds a problem in the code -- and tells you how to replicate the bug -- OR proves that a problem cannot exist. [1]: https://youtu.be/Nw1glriQYP8?t=1071 https://youtu.be/Nw1glriQYP8?t=1071 [2]: kadena.io/pact
- lomnakkus 9y ago

firebones 9y ago

Read the Solidity documentation on visibility [1]. Public, private, internal, external, that really seem to mix overlapping concerns. In the visibility documentation, it explains that the default is public. Then, in another section of the documentation, when talking about function types [2], not specifying internal or external defaults visibility to internal. It doesn't seem like the simplest or most consistent way to express these concepts, and certainly not the safest way. [1] http://solidity.readthedocs.io/en/develop/contracts.html#visibility-and-getters http://solidity.readthedocs.io/en/develop/contracts.html#vis... [2] http://solidity.readthedocs.io/en/develop/types.html#function-types http://solidity.readthedocs.io/en/develop/types.html#functio...

imron 9y ago

Imagine the court case: Your honour, in my defence, the contract clearly specified that anyone could reset the wallet, and if that's not what they wanted, they shouldn't have agreed to it.

blunte 9y ago
I cannot imagine the court case. The courts are utterly incapable of understanding enough of the technical aspects of far simpler software cases. So like most court cases, it will simply be a matter of human influence winning the case.
- macmac 9y ago
  If you are interested in a really good counter example to your assertion you should look at Judge Alsup https://www.techdirt.com/articles/20170325/23492137003/judge-alsup-wants-uber-waymo-to-teach-him-how-to-lidar-prior-to-self-driving-car-case.shtml https://www.techdirt.com/articles/20170325/23492137003/judge...