yes, but communication could be possible. Especially using quantum entanglement for ftl communication.

If the batteries are part of the structure, they may be significantly lighter, which will give the car better performance and more range.

Carbon fiber doesn't really dent. I'm guessing you'd either have no damage or a crack, and not really any state in between. If it's just a body panel that doesn't have any structural purpose, small and medium cracks could probably be repaired with epoxy, which would most likely be cheaper than repairing a dent. The crack may cause a reduction in capacity, but I doubt it would know the whole thing off line.

HFT algos aren't making bets on equity price movements. They're usually using sophisticated methods of finding and exploiting arbitrage opportunities.

Whatever you think of HFT, this tech sounds awesome and may have other interesting applications.

The vast majority of people doing data-intensive code with Python are either running code that is distributed across many nodes, where shared memory threads aren't very useful, or don't really care about execution time. I doubt a GILless cPython will ever come out, because it would require a massive amount of work and would provide little value to most existing Python users. People who need threads are already using other technologies, and I doubt many would switch back to Python just for that feature alone.

They still aren't full lambdas, since you can't mutate closed variables inside of the inner function.

Use coffeescript instead?

The core areas where Python is popular are all areas where threading is not very useful, either because the code is executed in a distributed fashion across many nodes (scientific computing, big data, web), because there are better concurrency paradigms (asynchronous networking), or because it's used for small scripting tasks that execute within a couple of minutes (system admin, text parsing, web scraping). Not surprisingly, Python isn't very popular for the type of tasks where threading is advantageous (games, desktop apps). I don't think there is much motivation to remove the GIL because it would require an almost complete rewrite of cPython and provide very little benefit to existing users in Python's core competency areas.

Yeah, there is no way the legal department in the company I work for would allow us to use a software library with no license. Of course, we may be willing to pay you for a license, but I think it would still slow the adoption of your project significantly.

I've used JS for many large projects. JS is vastly different from Perl in the fact that it has well defined behavior (unlike Perl 6, Javascript is based on an actual spec that you can go read) and JS is a compile target of more expressive languages. I would say the future is probably going to be transpiling to JS. A big problem with JS is no built in namespaces/modularity, but that is somewhat easily fixed with libraries like require.js. I think the lack of a decent standard library is a greater problem, because every framework out there duplicates the same stuff. Common.js is trying to solve this, but hasn't been terribly successful so far. I think people who complain about asynchronous operations and prototype based inheritance are just stuck in their ways, because these methods offer a lot of advantages over more traditional class based oop languages.

immutable source code? The problem with this is that someone will inevitably add new calls to the old function (with it's broken behavior), even if it's marked as deprecated.

Or you could do the correct thing, which would be to add tests that verify the behavior of foo and baz are correct in the case of kwok, then you're covered regardless of implementation. If the comment describes a performance optimization, you should describe why the current version works, rather than why the old version doesn't. Either way, your name and date are automatically recorded by your vcs, so you should never need to include that info in a comment.

Only if I am allowed to punch you in the face every time I see a TODO in the code from 3 years ago with a terse description that doesn't even match the current code. If it's something that needs to be done now, then do it. Otherwise, track the task as a ticket/store/defect, whatever method you use for tracking and prioritizing work, but please, please don't put a useless comment in the code.

How does leaving commented code help avoid bugs? If a bug was introduced into the code base, first thing an investigating developer usually does is look at the vcs's change log to see what changed, where the deletion will be obvious. Leaving it in the code doesn't make it any more discoverable, and there is a pretty good chance someone will forget to delete it.