Clojure's built in PersistentVector does not support O(log(n)) inserts/removes from the middle/front, but there is another implementation that shares a lot of it's implementation with some extensions that does: https://github.com/clojure/core.rrb-vector/
Overflow protection is fail-fast behaviour, similar to array bounds checking. It allows you to more quickly find the source of errors. I believe everybody agrees it's a good thing, at least in the array bounds checking case.
> Optimization flags in general should not change visible program behavior, except for performance.
The only behavior you would be able to observe before, that you wouldn't after disabling overflow behaviour, is a crash, and you would have fixed that anyway as soon as you observed it.
Of course, if there is $370 Million on the line, maybe just disable it and hope for the best :-)
Be careful, in the country I live in (Austria) it is illegal to import prescription drugs. Customs made me pay a fine of about 60$ for trying to import Melatonin (and I didn't get the Melatonin either).
My colleagues and I learnt that lesson the hard way. We are working on a WYSIWYG editor (Aloha-Editor) and the first version did depend on jQuery (and jQuery UI for that matter). That caused a lot of trouble for people integrating the editor in their websites, especially if they were already using jQuery. For our particular case we really didn't need it, as it's just as easy to say .getAttribute() instead of .attr(), and we didn't use selectors much, if at all. Effort is underway to get rid of the dependency from the core library in the next major release.
> Actually, most of the people working in those organizations are children of party officers or executives of wealthy foreign currency-earning organizations.
I expect he had connections and/or was able to bribe his way towards becoming a tour guide. Tourism, after all, is a foreign currency earning industry.
Clojure's standard persistent vectors don't allow insertion in the middle without copying the entire vector, they only allow fast insertion at the end. There is an alternative implementation here [1] which does allow insertion (anywhere) without copying the entire vector.
I'm working on something similar: https://wikidocs.com. Although our's closed source at the moment (can't say whether or not it will remain closed), we will provide a downloadable package you can run yourself.
We provide wysiwyg editor integration (Aloha-Editor) with presence and remote cursor. We are working on a hosted/downloadable service with low-level data-sync api and high level wiki features: https://wikidocs.com
Although more on the motivational than in the technical side, I learned a lot from his talks. To me, the feeling after one of his talks is more akin to "it's is so obvious to me now, I should have been thinking like this all along".
http://en.wikipedia.org/wiki/Egg_of_Columbus
We are building a real time HTML synchronization engine at wikidocs.com (using a custom OT engine). It's still work in progress, but you can already try it out - if you fire up the inspector and manipulate the DOM, your changes will be synchronized automatically.
Following quote comes to mind (Dijkstra)
"...we have to keep it crisp, disentangled, and simple if we refuse
to be crushed by the complexities of our own making..."
I found his use of the word "crisp" very interesting. I believe it means to keep your code short and to the point, without any extra embellishment.
Correct me if I'm wrong, but does this not merely allow an attacker to cause the browser to make requests with custom headers? That is, it does not allow the attacker to gain the CSRF token, and if the CSRF token is not known to the attacker, he would still not be able to make API requests.