Odd that they don't seem to count the Cold War. I understand that their measure of what they count as a war is subjective, but surely the Cold War impacted the average person's life at least as much as the War on Terror and had a significantly bigger economic impact.
I don't have so much a problem with the intent of the statement, but that it is misleading. Ordered execution is basically function composition, which is one of the most fundamental parts of math you'll learn. That function composition isn't commutative is nothing new, and it's something that mathematicians have to deal with every day (automorphism groups, linear algebra, functional analysis, the Collatz conjecture, whatever). Nor is it dangerous, and you aren't going to avoid function composition in a functional programming language, either.
The reason why it can become problematic is that the simple way of having mutable state is to model it as having a huge global ball of state that just gets threaded through every function as an argument. But you don't have to do it this way, and methods have been developed to do it better. See, e.g., schemas in Z (the specification language) and its refinement calculus. That very few languages (other than Eiffel and Ada/SPARK) have tried to actively go down that path is a different issue.
You can also have non-functional programming that only ever modifies a function's local state, which makes reasoning about mutability much easier. Object capability languages do this (for pretty much the obvious reasons) and ParaSail is an example of a language trying to exploit this property for concurrency. And, of course, you can do it voluntarily in any decent imperative programming language, too.
You can also relax functional programming's requirement for referential transparency a bit and get other interesting trade-offs. For example, if you have write once semantics rather than full immutability, you get a different concurrency model (what several concurrent logic programming languages have tried to exploit), which is in many ways more interesting than one based on immutability. And, of course, logic programming is also an attempt of "describing what is".
Sweden cannot extradite him to the US without the UK's consent. So-called "specialty" rules generally prohibit the further extradition of a person to another country without the extraditing country's consent.
From the ruling of Judge Howard Riddle in Assange v. Swedish Prosecution Authority:
> If Mr Assange is surrendered to Sweden and a request is made to Sweden for
his extradition to the United States of America, then article 28 of the framework decision applies. In such an event the consent of the Secretary of State in this country will be required, in accordance with section 58 of the Extradition Act 2003, before Sweden can order Mr Assange’s extradition to a third State. The Secretary of State is required to give notice to Mr Assange unless it is impracticable to do so. Mr Assange would have the protection of the courts in Sweden and, as the Secretary of State’s decision can be reviewed, he would have the protection of the English courts also.
> Sweden cannot extradite him to the US without the UK's consent.
That's not really true. Sweden _isn't supposed to_ extradite him without the UK's consent. But is the UK going to go to war over it? If not, then really Sweden can do whatever it pleases.
"The most important point is that as long as it is externally marked to show its status, the "bag" has diplomatic immunity from search or seizure, as codified in article 27 of the 1961 Vienna Convention on Diplomatic Relations." http://en.wikipedia.org/wiki/Diplomatic_bag
Now reconcile that information with this new seemingly contradictory information:
"Action required – Assange to be arrested under all circumstances," reads a handwritten briefing note photographed in the hands of one of the officers surrounding the Ecuadorian embassy. The note says Assange is to be arrested if he leaves the embassy in the company of another diplomat or if the Ecuadorians try and smuggle him out in the diplomatic bag."
And even better, they contradict themselves on this policy from the get-go:
"When it comes to its own diplomatic materials, however, the British government takes a harder line. It issued a strong protest when the sanctity of its own diplomatic bag was violated by Zimbabwean authorities in 2000."
People violate the Vienne Convention on Diplomatic Relations regularly it seems when it suits their purposes. The idea that Sweden is somehow prevented from doing something inside her own borders because of some toothless international "law" (what is the punishment for failing to abide by the agreement?) is laughable at best and incredibly disingenuous at worst.
It's a little difficult to reconcile the idea of fanatical Swedes doing everything within their power to get Assange into the US with the back-and-forth over whether to prosecute him and their failure to prevent him leaving the country after they'd decided to reopen the case.
Consider that it is perfectly possible for some Swedes to be "fanatical" and for some (or even most) to want to abide by the law. The question is whether there are some Swedes with sufficient reach willing to go far enough.
E.g. some years back, Swedish police black bagged two political asylum seekers from Egypt and illegally handed them over to the CIA, knowing the CIA would fly them to Egypt and hand them over to Mubarak. Sweden asked for a "promise" they'd not be tortured, which they promptly were of course. The entire operation violated by Swedish law and international law, was condemned by the UN and Sweden has been ordered to pay restitution over it.
Yet a few years later, Swedish military police uncovered that the CIA were still conducting illegal rendition flights via Sweden, with the cooperation of Swedish ground staff. We know about the latter only because Wikileaks years later reported on how the US ambassador to Sweden was called in to the Swedish foreign ministry over the matter. We don't know whether there have been further "issues" because it has never been investigated thoroughly by anyone that we know of, and certainly not publicly.
Clearly some Swedes - including police officers - were ok with blatantly ignoring Swedish law in the first matter, and some were willing to continue cooperating with the CIA illegally even after the massive uproar of the first revelations, and after it was clear political authorities at least in public opposed it, and at the same time as other parts of the Swedish government were prepared to take action against it.
I'm not saying that the Swedes are fanatical at all. Just that the idea that they CAN'T extradite (or let the US render) him to the US is delusional. A country can do whatever someone won't go to war over. That's the ultimate determining factor, "will someone invade/bomb/whatever us for this?" and if the answer is no, the country is free to do so!
Remember that there was little/no international support for the US starting wars in Afghanistan and Iraq, but the US did so anyhow and since nobody has invaded the US for doing so, it seems that the US has "gotten away with it" at least so far as international law is concerned.
Finally it doesn't have to be that the Swedes desperately want Assange to be extradited, but merely that someone from the US is pressuring them to keep reminding the world that "Assange isn't a good guy" from time to time.
I'm not saying Assange is innocent, either. I honestly don't know. But to think that the US has an interest in hindering him, well, that's not unreasonable at all.
Exactly. If they're willing to do this, why would an embassy provide protection ? As several recent incidents illustrated, it is in fact quite possible for armed men to walk into an embassy and do whatever the hell they want inside.
Would Ecuador go to war over such an act ? No way.
Sweden does not do kidnapping on foreign soil so it is way more likely that someone abuses the Swedish bureaucracy to illegally extradite someone. Sweden has done it before under the flag of the war on terror. Now I have no idea if this may happen to Assange but the his fear is not entirely unfounded.
Spying on other EU nations is not any better. There are strict rules that target selectors used for mass surveillance must obey. Any target selector must be related to the prevention of one of the following:
1. An attack against German territory (i.e. war).
2. International terrorist attacks related to Germany.
3. International arms trafficking.
4. Drug smuggling as part of organized crime.
5. Endangering the stability of the Euro through counterfeiting activities abroad.
6. International money laundering at a large scale.
7. Human trafficking.
Mass surveillance by the BND for purposes outside of these seven areas is not allowed, period; any personal data intercepted that is not related to these areas must be deleted. Most of the target selectors provided by the NSA to the BND did not fall into any of these areas.
I see this less as corruption at the top myself and more as a number of internal problems systemic to the BND and the Federal Office for the Protection of the Constitution (Germany's domestic intelligence service).
I am old enough to have seen a huge number of scandals coming out of the German intelligence services. I've seen Maihofer resign over the Traube affair and I've seen German intelligence snoop on privileged client-attorney communications and a lot of other bad stuff. The list of BND scandals is legion.
I would be happy to see resignations of any current and former Chief of the Chancellery involved in these schemes, pour décourager les autres. Let's be clear: the BND has pretty much intentionally broken several of the safeguards contained in the G10 Act, often with internal legal justifications that don't pass the giggle test (and would make only John Yoo proud). And the most recent revelations may mean they even committed crimes (conduction espionage for a foreign power, per §99 of the penal code, and economic espionage, per §17 of the law against unfair competition). This is plenty of reason for heads to roll. And sometimes, the tree of liberty has to be watered with the careers of intelligence service bureaucrats.
At the same time, even as an anti-fan of Angela Merkel's policies, I don't see what kicking her out of office would help (unless she had her fingers deeply in this particular pie). Intelligence services regular seem to aim at becoming a state within a state, and dismantling the power structures above them won't help; structuring safeguards so that they aren't as easily circumvented does. For example, in theory, the G10 commission (the watchdog appointed by the Bundestag) has broad control over what the intelligence services can do in terms of surveillance and can stop any and all surveillance measures at any time. In practice, however, that seems to have been circumvented by them not being told in the first place (or being deceived).
This is a simplified example derived from one that the author apparently got from an older discussion started by Peter Van Roy  that both of them were involved in (and which I happened to read back in the day).
The argument here is about modularity, namely encapsulating internal state within a module without exposing that state to the outside. (For example, so that one can introduce a module-internal auditing mechanism or a cache without altering the module's API.)
Peter Van Roy, of course, is one of the principal authors of Oz, so he may have some natural bias, but I've always found the argument persuasive.
For testing and validation purposes, one will obviously need to use appropriate techniques (e.g. specifying and validating state invariants).
I am not really happy with either Git's or Mercurial's solution.
Git's branches introduce too much fragility in the system for end user consumption (because branches are responsible for both naming and keeping commits alive) and do not allow you to describe sets of commits (nor is there an alternative feature for that), Mercurial's branches are too permanent in that they cannot even be renamed (well, there's an extension for that, but that's not without issues). Mercurial bookmarks still do not allow you to label sets of commits, but at least aren't responsible for the liveness of a commit.
In practice, I like both Fossil's and Bazaar's model better.
What do you mean by a "set of commits". Why not just have topic branches?
Branches isn't the only thing that keeps commits alive, you also got the reflog and tags. I have a hard time understanding why you would want to keep something alive that isn't reachable from the history.
Branches as sets of commits are useful for understanding history. I.e., which commits conceptually belong together and with a quick descriptor of what their purpose and/or who their primary author is (or whatever else your chosen policy for naming them is).
That branches are not the only refs that keep commits alive is irrelevant, because the other refs by themselves are not sufficient; not every commit is reachable from a tag and reflog entries expire. Branches remain a necessary ingredient.
Git needs this because it requires a named head for each commit because (1) it has a garbage collector and (2) it doesn't allow for multiple checkouts. In version control systems with multiple checkouts, a new branch will typically end up in a checkout of its own. Because there's no GC, it will not spontaneously disappear, and because each checkout keeps track of its own head, there's no need to name it. Git branches are an artifact of Git's odd architectural choices.
But my bigger point is not about wanting to keep something alive that isn't part of the history, but that branches may not always accurately reflect what's part of the history (because Git allows you to alter them, and that's often even part of the normal workflow, e.g. deleting a temporary branch once you don't need it anymore). This usually does reflect human error, but, well, a major point of using a VCS is to protect against the results of human error. If you messed up your branches, then you can lose data either because (1) it eventually gets garbage-collected  or (2) it doesn't get pushed anymore and some day your computer or hard drive breaks. This is what I meant by Git introducing fragility.
 Yes, once the grace period expires and it disappears from the reflog, but that only makes it less likely, not impossible, especially for stuff that sees only intermittent work.
Well, you can set the expiration period for the reflog. If I remember correctly you can set it to "never". You can also disable alteration and removal of branches on a remote git repo. It's really all about knowing your tools.
Then again, in my experience, if you manage to remove data or alter data which should not be removed or altered, and don't pick up on that before after the reflog expiration period, then you have bigger problems.
> Well, you can set the expiration period for the reflog
Much easier, you can turn off garbage collection (if you set the expiration time on the reflog, you have to make sure to set gc.reflogexpireunreachable, not just gc.reflogexpire). This is indeed what I do whenever I work with Git as the frontend (though not when I uses Git programmatically as basically a versioned DB backend). But that's not about me. I'm fully conversant in Git, up to and including having hacked Git repositories using dulwich. It's about users in general, all of whom have to deal with this.
Of course, this has its own problems, because lots of Git usage patterns have evolved around creating garbage and then throwing it away rather than having an explicit and safe delete operation that is rarely used (or at least to hide revisions rather than to delete them), and because it may not be possible on hosted repositories, such as on GitHub (Bitbucket allows you to prevent force pushes to master branches, GitHub doesn't ).
And even when you've made it safe, you still cannot have unnamed branches or multiple checkouts .
The more general problem is that Git's GC is not a user interface design decision. Git having a GC is ultimately a result of it being easier to hack together your own transactions without using an actual DB backend such as SQLite when you use (mostly) functional data structures with a GC. While this makes Git a fairly robust versioned database, these and other implementation decisions spilling over into user space is something that has plagued Git for a long time: for full proficiency with Git you need a fairly deep understanding of implementation details.
> Then again, in my experience, if you manage to remove data or alter data which should not be removed or altered, and don't pick up on that before after the reflog expiration period, then you have bigger problems.
This can easily happen on branches that see only intermittent changes or on personal repositories. Git was originally designed for being heavily distributed work, and it shows; it's relatively safe when commits are regularly mirrored to a network of contributors, not so much when they don't.
And, again, this is a problem that should not even exist. One of the primary tenets of source control management -- a major reason why we even have it -- is to protect developers against their mistakes. In particular, there are many cases where VCSs are being used by non-technical people (such as technical writers working on documentation) and they cannot be expected to have a deep technical understanding of the tools they are using. VCS tools must therefore be error-resistant.
 GitHub in many ways is still shockingly primitive, such as how it still doesn't support attaching files to issues. Referencing gists via URL is a sort-of workaround, but even that becomes painful with binary files. But that's another story.
 The reason for the latter is subtle, but basically boils down that the GC either needs to have global knowledge of all checkouts in order to trace checkout-local refs such as HEAD properly (which may be lost by a simple mv) or that multiple checkouts that use the same branch can get in a battle over who gets to point it to which commit (e.g., commit to master in two checkouts, and only one commit operation can "win", because master cannot point to two commits at once).
> ... lots of Git usage patterns have evolved around creating garbage and then throwing it away rather than having an explicit and safe delete operation that is rarely used
Any delete operation in Git is safe. At least compared to delete operations in other vcs's (hg strip comes to mind).
> may not be possible on hosted repositories
That isn't Git's fault though, but the hosted repository. You could say the same about Mercurial bookmarks.
> And even when you've made it safe, you still cannot have unnamed branches or multiple checkouts.
I don't understand why this would be nice to have. Mercurial had the former, which to me was completely useless. Should I ever want to go back to a previous unnamed branch, I would have to actively search for it, which on a large project would take forever. I always keep my branches named, after the issue number, for this particular reason.
I don't really understand what multiple checkouts are for (a quick google gave me nothing). I would assume it would be something like having multiple local repositories, but I assume that is not what you're getting at?
> a fairly deep understanding of implementation details
Which takes literally fifteen minutes to teach (at least the way I did it), and after that it becomes a lot easier to explain what the different commands actually do.
> it's relatively safe when commits are regularly mirrored to a network of contributors, not so much when they don't.
A network doesn't provide any more safety (except from a computer crash), as you don't push garbage.
> is to protect developers against their mistakes
To a point. To be completely safe we would have to auto-commit on fixed intervals, like a traditional backup system. Instead, the user is empowered with the decision to decide what gets stored. If the user wants to remove something entirely, or re-write history to make it more readable or whatever, he/she should have that power too. A default 30 days of full history is, IMHO, quite reasonable given what the user can do. If that doesn't meet your requirements, then there are other, better options out there.
> they cannot be expected to have a deep technical understanding of the tools they are using
They don't need one. Have someone teach them git add, commit, push, pull and merge. Then teach them to NEVER rebase. Done.
We could probably go back on forth on this a lot, as we're unlikely to change each other's position, I'll call it quits. Thanks for a fruitful discussion :)
> Any delete operation in Git is safe. At least compared to delete operations in other vcs's (hg strip comes to mind).
While I'm not a big fan of Mercurial's strip implementation (because the management of strip backups is cumbersome), in order to permanently lose data there you'd have to do hg strip and then also expressly delete the backup in a separate step. Git does the deletion on its own.
More importantly, you seem to be mistaking this for a Git vs. Mercurial argument. I am not making a Git vs. Mercurial argument; if anything, my position is that "Mercurial is less bad than Git, except in some areas where Git is less bad." And even that's not what I'm getting at, because I'm not interesting in comparing them against one or the other, but to point out that both are lacking.
In general, SCM development has stalled since the late aughts and content with a relatively subpar state of affairs. That too many people seem to think that Git and Mercurial are the only DVCSs ever invented and that centralized version control means either CVS or SVN doesn't help, either. My interest is in getting less primitive version control than the existing systems, not defending the antiquated status quo (antiquated to the point that there are even older, now forgotten systems that did some things better than the current crop).
> That isn't Git's fault though, but the hosted repository. You could say the same about Mercurial bookmarks.
Mercurial bookmarks, if misplaced, do not result in revisions on a server becoming inaccessible.
About unnamed branches:
> I don't understand why this would be nice to have. Mercurial had the former, which to me was completely useless.
They go hand-in-hand with having multiple checkouts. Create a temporary branch in a second checkout, and you don't need any label for it (because it's the tip of that checkout).
> I don't really understand what multiple checkouts are for (a quick google gave me nothing). I would assume it would be something like having multiple local repositories, but I assume that is not what you're getting at?
For example what (as I noted) git-new-workdir attempts to do (again, that's unsafe, use at your own risk). If you aren't familiar with this concept, you can't know very many VCSs, though. It's supported by all DVCSes other than Git in some form of another (though arguably a bit indirectly in Darcs, and Mercurial's version doesn't have good commandline support). It is also obviously supported by all centralized VCSs.
It simply means that you can have two or more checkouts (working trees, in Git parlance) of the same or different revisions, but only one shared repository. Multiple clones can only crudely approximate the behavior, since you can't directly diff or merge between branches in different clones, say. A simple example of the usefulness is to be able to compare the behavior of different versions side-by-side (particularly when you're dealing with slow builds). Another is to be able to create a separate checkout for an urgent bugfix without interrupting your current work, then easily integrating that bugfix into your work.
> A network doesn't provide any more safety (except from a computer crash), as you don't push garbage.
My point is that the likelihood is higher that accidentally deleted material has already been shared with other developers, so it's more likely to be recoverable if you misplace a branch.
> To a point. To be completely safe we would have to auto-commit on fixed intervals, like a traditional backup system. Instead, the user is empowered with the decision to decide what gets stored.
Agreed. But my point is that Git unnecessarily trades away security, based on an implementation decision (to achieve transactional properties by using functional data structures plus garbage collection). Nothing is ever going to be perfectly safe, but that was entirely avoidable.
> We could probably go back on forth on this a lot, as we're unlikely to change each other's position, I'll call it quits.
I don't ever expect to change anybody's opinion; I am merely explaining.
> I've somehow created a branch that couldn't be deleted.
The problem here is one of conflicting terminology. What Git calls a branch, no other version control system calls a branch. A branch in Git is really a moving pointer to the head of a branch as other VCSs would see it.
The confusion can go both ways, by the way. I.e. when a user who is used to another VCS expects a branch to be a persistent label for a set of commits and then discovers that it doesn't work like that for Git repositories and that your branches may "move" or "disappear" and don't even describe sets of commits but individual commits.
SVN tags and branches correspond quite closely to Git tags and branches, I think; "tag" is a naming of a commit, "branch" is an evolving repository that shares history (and perhaps future, if merged) with other such "branches".
Except Git tracks history of the named branch in the reflog, and SVN (and others, I would guess) track it inside the repository. This is a huge difference for archeologists, but quite minor in practice from my experience.
Git doesn't really have a technical difference between a tag and a branch either. They are both files containing a hash for some commit. Tags are just more cumbersome to move (branches are moved on new commits), and they can be signed cryptologically(is that a word?).
You get this problem when you have two identifiers (variables, functions, constants, etc.) that differ only in case and have the same type signature. Depending on whether you use one or the other form, you may get completely different behavior.
By default, the Rust compiler warns you when you use uppercase characters in variable and function identifiers. The community overwhelmingly adheres to this style. Rust is also extremely strongly-typed, so not only would you have to be willfully disabling the style warnings, you would have to have to manage to give them the same types, and furthermore given the nature of Rust code it's rather possible that you'll still get a compilation error due to using a variable in a way that it didn't expect. You also can't "accidentally" introduce new variables in Rust, as you can in Python via typos.
Yes, enforcing case strictly via style guidelines that prevent mixing of upper- and lowercase is another way of avoiding that problem (underscores can still trip you up in a similar fashion, of course, e.g. signon vs. sign_on). I'm still not sure how the discussion got sidetracked into discussing Rust, though.
I'm really not sure what the point of referencing Rust is. This was about programming languages in general, and the post I was referring to was about C#. Also, importing is an example, another example would be accidentally declaring a second variable in the same module (should not happen, but people make errors), or a number of other situations where two identifiers that are identical except for case end up in the same scope.