1. 5

    Title is bit clickbaity, but the actual content is super interesting, too. :)

    1. 9

      Yeah, the title is total clickbait. He didn’t compile the Typescript. He took the parser out of the compiler, ran it inside BigQuery, and was able to get a million ASTs in 40 seconds. While impressive, it’s nowhere near a full compile.

    1. 3

      irreversibility, an essential design feature of cryptocurrency blockchains, is the fatal flaw of cryptocurrency that is responsible for most cryptocurrency and smart contract disasters

      If people wanted repudiation, they would use PayPal.

      Repudiation is one of the worst parts of the existing financial system, because it encourages horrendous failure-prone system design (since we can just roll it back no problem!). On a practical level, repudiation is fundamentally incompatible with the goals of a trustworthy, mechanized, objective finance system.

      (Although arguably it makes sense for ethereum since they’ve already given up on all three of those things by manually reversing the DAO “hack” even though it was a perfectly valid contract. So much for “code is law”.)

      On a philosophical level, Bitcoin is all about giving you more control at the expense of no one holding your hand. That’s the way it was designed, and that’s the way we want it. Repudiation fundamentally means loss of trust or loss of control. If anyone can reverse their own transactions, we lose trust. If there’s some centralized party that can choose to reverse transactions, we lose control.

      1. 5

        as long as human will build computer system, you will have to have way to recover against human errors. The only systems that don’t support this recovery system is human endangering systems which are gambled to be error free.

        1. 6

          Yes, I’m saying that’s unworkable for anyone who just wants to move value around in a money-like manner and isn’t ideologically committed to dealing with the brittleness of the resulting system.

          1. 0

            Is cash unworkable? It has basically the same non-repudiation properties as Bitcoin, and yet people seemed to do OK with it for a long time (and before that, same deal with specie, and before that with commodities, etc.).

            The existence of repudiation is a consequence of the emergence of unreliable credit systems, not something people sought out.

            1. 13

              Actually no, repudiation in the sense of contracts existed long before unreliable credit systems. Courts would “rollback” a contractual transaction for various different reasons. Among them failure on one party to understand what the other party meant in the wording of a contract. This could be due to one or both parties interpreting the language of the contract differently. This is a feature and not a bug of contract law.

              As the bugs in smart contracts indicate it’s frequently possible for both the author of the contract and the counterparties to not fully understand what the contract actually says. This is for most people a bug and not a feature. Only idealists and thiefs would look at it as a feature. The idealist is willing to sacrifice assets for the ideal of an unbiased contract enforcer. The other likes the idea that they can take money from people who didn’t think it was possible with no consequences.

              Thiefs were exploiting the legal system long before this of course but since smart contracts are obviously capable of quite serious bugs. You’ve just traded one group of exploiters for another which certainly hasn’t moved us in a direction of progress, and may in fact have moved us a few steps backwards since the smart contract by definition doesn’t allow for any kind of remediation of the exploit.

              1. 0

                Contract invalidation risk is related to, but not the same as, counterparty and settlement risk in trading.

                Modern credit systems didn’t exist until the late 1600s. Credit existed long before this, but its scope was strictly limited. Fungible obligations, short selling, futures, and all the other staples of modern trading are for the most part less than 500 years old.

                As the bugs in smart contracts indicate it’s frequently possible for both the author of the contract and the counterparties to not fully understand what the contract actually says

                You can’t blame human failures on the system they’re failing with. It’s not a “bug”, it’s the entire point.

                1. 10

                  You can’t blame human failures on the system they’re failing with. It’s not a “bug”, it’s the entire point.

                  The entire point of systems engineering is to understand how system design leads to human failures.

                  1. 9

                    Fungible obligations, short selling, futures, and all the other staples of modern trading are for the most part less than 500 years old.

                    That’s not true. The ancient Babylonians had grains futures markets. Credit instruments, in many cases, predate cash.

                    1. 8

                      You can’t blame human failures on the system they’re failing with.

                      You can when literally Gavin Wood can’t write a contract that won’t lose him literally tens of millions of dollars. This strongly suggests the ideological imperative in question fails when it hits reality. “[ideology] cannot fail, it can only be failed” is the stuff of cults.

                      1. 0

                        You can when literally Gavin Wood can’t write a contract that won’t lose him literally tens of millions of dollars.

                        Sounds like Gavin Wood is one of the original developers of ethereum, which is exactly the sort of person I would expect to lose tens of millions of dollars due to lack of rigor.

                        “[ideology] cannot fail, it can only be failed” is the stuff of cults.

                        Are mathematics and formal logic cults?

                        That’s what this comes down to; I agree ethereum in particular is unsuitable as a financial system, but all that means is that we have to increase our expectations of formality in financial system design.

                        1. 5

                          Are mathematics and formal logic cults?

                          No, but the idea of wiring them into a financial system in a way that quite efficiently separates less-rigorous people from their investments sure is. People have a hard time dealing with formalized logic systems, and get tremendous value from a squishy financial system with chargebacks and courts and mutable rules.

                          1. 4

                            Also, we’re really bad at doing math good :(

                            1. 0

                              Good thing grandma doesn’t need to write a proof every time she sends Bitcoin; only expert imementers need to care about this stuff.

                              1. 6

                                This is categorically not true. Because when Grandma wants to send money via a smart contract on a blockchain she must either trust that the writer of the contract was a benevolent expert or be an expert herself. This continued insistence that math will protect less math savvy people from more math savvy people is why every conversation with the idealist breaks down.

                                Grandma isn’t an idealist. She just wants to be one of the parties in a smart contract. But grandma can’t safely do it. Period.

                                1. 4

                                  A good example is the EtherDelta hack. Approximately 0 crypto users can audit their software, let alone do audit it; they trust that someone else has done the security legwork to decompile and inspect a smart contract or a huge pile of minified JavaScript.

                                  One could then answer “well they deserve what happens to them, doing that in cryptocurrency” - but then you’re back to the problem that this is substantially only a problem if you insist on using cryptocurrency for things that are currently done without it. The primary use case is ideological, ‘cos it sure isn’t practical.

                        2. 4

                          A bug is code that doesn’t work they way you meant it to. Blame lies with the Humans absolutely. But that’s the whole problem. Humans have to write the contracts. Humans also have to trust the contracts. Since Humans have to write them Humans also can’t trust them.

                          This make smart contracts considerably more risky. That is the entire point of their critics.

                          1. 0

                            Humans have to write the contracts. Humans also have to trust the contracts. Since Humans have to write them Humans also can’t trust them.

                            This would all be true in the absence of formal methods, which people whom I actually trust to build a working financial system are currently trying to fix.

                            I agree that existing “smart” contract systems suck, but the fundamental idea is perfectly sound.

                            1. 4

                              We probably would need to agree to disagree. I suspect the above would still be true even if you had formal methods.

                              1. 2

                                I think so too. The issue here seems to have been a combination of the following:

                                1. code sharing (“external library”) to reduce deployment cost in the form of gas
                                2. not knowing or realizing the library was actually a multi-sig wallet contract and thus vulnerable to the previously fixed vulnerability
                                3. not considering the ill effects of calling a “kill function” on such a wallet
                              2. 3

                                formal methods only prove what you specified. usually the way to hack formal proven programs is to play on unspecified things.

                        3. 4

                          Is cash unworkable? It has basically the same non-repudiation properties as Bitcoin, and yet people seemed to do OK with it for a long time

                          The widespread use of cash is actually a pretty recent invention. “Cash” as we currently conceive of it (paper money, gold coins, silver bars, etc) has not historically been the primary financial instrument in people’s lives. The primary financial instrument has been credit. Historically, people would ring up a tab, and then pay it off. Even as late as the 1600s, it was possible for English kings to recall all of the coins in circulation and have it reminted with their likeness.

                          This was workable because people lived in close-knit communities, and social and legal remedies could be effectively used against people who failed to pay off their debts. Cash was used when trading with people who could not be trusted, usually because they were merchants who were from outside the community.

                          It’s only as we move to a more atomized, anonymous society that cash becomes more widely used. But even in a highly cash-oriented society, if you actually looked at the transactions, most “large” transactions were conducted in a repudiable medium, like cheques or bank transfers.

                          1. 3

                            I’d rather trade some repudiation potentially happening to having to lug around gold coins when I want to buy something. I find the arguments against repudiation a bit overblown. There was no lack of fraud, insolvency or straight-up moral hazard in the “good old days” of the gold standard.

                            1. 0

                              I’d rather trade some repudiation potentially happening to having to lug around gold coins when I want to buy something.

                              Bitcoin allows you to keep both. It’s easy to transport and non-repudiable. That’s the point.

                            2. 4

                              Two problems with the cash analogy:

                              1. Someone can’t pick your pocket from the other side of the world.
                              2. Bitcoin acts much more like a balance in an electronically-accessible bank account. Except with no customer service and a terrible user experience. And ridiculously high fees. And long transaction delays.

                              It combines the worst of both worlds.

                              The existence of repudiation is a consequence of the emergence of unreliable credit systems, not something people sought out.

                              This is completely historically false, as zaphar points out below.

                              1. 3

                                Actually, bitcoins have lot of less problems than ethereum. It has an only point of failure which is to keep the private key secret. (There is several variation on how this secret key can be stolen, but it is far smaller problem than the way bug can be introduced in smart contract)

                                1. 2

                                  Someone can’t pick your pocket from the other side of the world.

                                  Someone also can’t steal your cryptocurrencies from the other side of the world unless you’re acting stupid and trust a third-party wallet service.

                                  Bitcoin acts much more like a balance in an electronically-accessible bank account.

                                  “Cash acts much more like a balance in a physically-accessible bank account.” What are you trying to communicate with this statement?

                                  Except with no customer service

                                  You don’t need one; anything that’s possible you can do on your own. Sure, if you’re totally clueless it might be harder for you, but it’s a massive improvement for people who know what they’re doing.

                                  and a terrible user experience.

                                  Right, because banks score so highly for customer satisfaction. The reason I tried bitcoin was because banks kept fucking me over in ridiculous ways. The state comptroller stole thousands of dollars from my Wells Fargo account because of a paperwork error (not possible with bitcoin), and after I got it fixed and had the money refunded, Wells Fargo charged me hundreds in “legal fees” for the pleasure of helping the government steal my money.

                                  And ridiculously high fees.

                                  Compared to what? Even with the current insane transaction volume, it’s still cheaper than PayPal or credit cards, for any purchase over, say, $50. It’s only going to get cheaper as we find ways to take the pressure off (a la lightning network).

                                  And long transaction delays.

                                  I thought you were the one who liked repudiation? A transaction “going through” just means it’s no longer repudiable. Bitcoin transactions clear to the level of a credit card transaction instantly, and to the level that credit card transactions do after ~6 months on an average of ten minutes.

                                  This is completely historically false,

                                  No, it’s really not. For some historical context look up Hawala (early credit system) and then read about the emergence of modern financial instruments in the Netherlands in the late 1600s, including modern notions of settlement.

                                  1. 5

                                    Someone also can’t steal your cryptocurrencies from the other side of the world unless you’re acting stupid and trust a third-party wallet service.

                                    Except the article in question is exactly that with no one acting stupid. A contract had an unintended effect that allowed someone playing around to accidentally revoke access to assets guarded by that contract. That is demonstrably the entire thing that a smart contract is for. Are you suggesting that your money is safe as long as you don’t use a smart contract and don’t be stupid? I would agree but the context of this conversation isn’t crypto-currency. It’s smart contracts.

                                    1. 6

                                      Someone also can’t steal your cryptocurrencies from the other side of the world unless you’re acting stupid and trust a third-party wallet service.

                                      see, you say this, but it turns out that “be your own bank” also means “be your own financial institution chief security officer”, and that turns out in repeated practice to be really hard, hence the repeated tales on /r/bitcoin of people losing their holding to user error or computer mishaps.

                                      Here’s the Bitcoin Wiki guide to being your own bank: https://en.bitcoin.it/wiki/Securing_your_wallet Give that to your favourite nontechnical relative and see how they do.

                                      it’s still cheaper than PayPal or credit cards, for any purchase over, say, $50.

                                      This is entirely false in the UK.

                                      The rest of your post is a Gish gallop of non sequiturs.

                                      1. -1

                                        hence the repeated tales on /r/bitcoin of people losing their holding to user error or computer mishaps

                                        Yes, you expect some level of failure in a population of millions.

                                        Give that to your favourite nontechnical relative and see how they do.

                                        Any idiot can use a phone app like Mycelium and be sufficiently secure. Give them a Trezor if you’re really worried.

                                        This is entirely false in the UK.

                                        Are you claiming that credit cards don’t charge fees in the UK?

                                        The rest of your post is a Gish gallop of non sequiturs.

                                        Everything I said was a direct response to one of your points, so I think you mean “I don’t know how to refute what you said so I’m going to dismiss it instead”.

                            1. [Comment from banned user removed]

                              1. 12

                                There’s absolutely nothing respectable about firing people. If you have to fire an employee then you failed miserably at your job. It’s almost never the employees fault when they get fired. It’s almost always the fault of HR for hiring the wrong people for the role, or management for not knowing how to lead, inspire and motivate their teams properly.

                                I think that goes way too far in the opposite direction. There are genuinely toxic people out there. Sometimes those people can hide their toxicity well enough to pass through your interview process. At that point, once you’ve realized that this person is hurting your team, you should fire them. Claiming that there’s nothing respectable about firing people is equivalent to asking people to have perfect clairvoyance about the future behavior of someone they’ve met for at most a handful of hours.

                                Of course, I do agree that after you fire a developer, you and your management should sit down and look at the process and ask yourselves, “Is there anything we could have done better here?” But sometimes the answer is, no, we couldn’t have done better here because to reduce the type-1 error of hiring a toxic person when we shouldn’t have, we’d have to raise type-2 errors significantly by rejecting anyone whom we didn’t think would fit perfectly with the team as it stands, even if they would have been a good contributor.

                                Sometimes the cost of hiring diverse talent who’re adaptable and a have a wide range of skills is letting the occasional abrasive personality slip through. The key is to determine early on whether someone is affecting the team negatively, and then figuring out why and what to do about it an kind and humane manner.

                                1. [Comment from banned user removed]

                                  1. 1

                                    I agree that “abrasive” was poor phrasing. However, I wanted to find a more neutral phrasing that would convey the same meaning as “toxic” without the negative moral connotations. I agree that developers have personality quirks, and I would go farther. Sometimes the new-hire’s personality will clash with the collective personality of the team in a way that could not be forecast ahead of time, and, moreover, this is no one’s fault. In such cases, the kindest thing to do is to admit that things aren’t working out to let the new hire go (with a generous severance package).

                              1. 6

                                I get that moves between languages can be uncomfortable, and are harder for some than others. The real danger is tying yourself down. Saying “I will only code in X” is a great way to end up obsolete. Saying “we only hire experts in X” is a great way to have no candidates.

                                1. 3

                                  I somewhat disagree. There are still people who write COBOL for a living and they get paid bank. If you love a technology then feel free to pursue using it to your heart’s content.

                                  I think there is value in learning other languages. I’ve dabbled with BASIC, C, Python, Matlab, Octave, LabVIEW, JavaScript, and obviously Ruby. I’m not saying that you should be a language monogamist and never expand your horizons. Every new language I learn teaches me something regardless of how “similar” they are to a lang I already know. I’ve still not come across another language that feels better than Ruby does to me.

                                  Would I ever work in another language? Sure. But while I’ve got options that include my preferred lang, the reasons need to be more compelling that “is a job”.

                                  I do think companies need to write better requirements for jobs. Most of the “we need an expert” really means they would like an expert but will take someone with a pulse who has completed a “hello world”. Sometimes you really do need someone with a lot of experience for senior level positions. Most of the time the company has no clue.

                                  1. 5

                                    I would say that you’re actually misinterpreting the lesson of the COBOL programmers. The COBOL programmers you see today are making bank, but you have to keep in mind that they’re the survivors of multiple rounds of layoffs that resulted in mass unemployment at the beginning of the ‘90s. In essence you’re looking at the top 1% or 0.5% of COBOL programmers, those that are good enough to get called out retirement at multiples of their original salary to repair legacy systems. You’re not seeing the ones who went on to different kinds of programming or left the industry altogether.

                                    In addition, the problem with sticking to a single language for work is that if there’s another big secular shift in the industry (like the one away from COBOL), it can leave you unhireable. I’ve seen this initially with COBOL, and later with Perl. When Perl faded as a language for web development and was replaced with PHP, Python and Ruby, there were quite a few Perl hackers who had a really hard time finding work, simply because the only thing they had on their resume (in a professional capacity) was Perl. Meanwhile those who had Perl + Java, or Perl + Python, or Perl + C# had a much easier time getting work because they were able to lean on the non-Perl parts of their work experience to make a case that they would be productive in a non-Perl environment.

                                    That said, I wholly agree that companies are terrible at writing requirements. The vast majority of developer positions do not require deep knowledge of the internals of frameworks or language runtimes. Usually, basic knowledge of algorithms, data structures, combined with surface level familiarity with language syntax is more than sufficient to ensure that a developer can become productive in a reasonable period of time.

                                    However, the world we live in is a world in which employers filter resumes by keyword. In such a world, it makes sense to have professional accomplishments in as diverse a set of programming environments as possible in order to ensure that you’re not caught flat footed by secular shifts in the industry.

                                1. 9

                                  The title supplied for this isn’t in line with what the linked article articulates as a point. It’s commentary on the article. I’d personally perfer a title that is in line with the content of the article and then commentary from the submitter as a comment here.

                                  To summarize the article:

                                  • I love clojure
                                  • I never consider lines of code to be a valid metric so I didn’t worry about “verbosity” of Java code
                                  • Event happened and I am now rethinking my previous position, perhaps it does matter in some regards
                                  1. 6

                                    I clicked on the article thinking it was an article that would “defend” the verbosity of Java, but it’s not the case at all. I agree that the title does not clearly reflect what the article is about.

                                    1. 1

                                      I think a better title would be, “Why we should care about the verbosity of Java”. Actually, it would be even better to say, “Why we should care about verbosity in programming languages,” because, while the article was specifically comparing Java and Clojure, there’s nothing in that article that’s specific to either Java or Clojure. One could have made similar comparisons with Java and Scala, or Java and Kotlin.

                                    1. 3

                                      I don’t think it needs to block on the site transition. As I understand it, the transition isn’t going to involve any significant code changes. It’ll be moving the existing code and data to new hosting infrastructure, under new management. Any patches made before the transition should be equally valid after.