The Bering Sea's typically not involved in the Indonesia raft theory. The Kon-Tiki route was all south of the equator. And the Bering Strait was a land route beginning c. 21,000 BP, though access along the coast was blocked by ice until about 17,000 BP and the interior route didn't clear up until about 13,500 BP. There's a pretty good history of the sea level in the area here: http://theconversation.com/fir...

But like I said there's plenty of other evidence against the theory, at least as a significant driver of human migration.

The OP's bizarre, too (I ascribe that to the media losing something in translation, not necessarily the original research); Clovis-first has been out of favor for decades now, and the timing on when the Bering crossing was open doesn't agree with anything I've seen espoused in recent years. The inland route probably de-iced c. 13,500 BP, and the coastal route by 17,000 BP give or take. And most mDNA evidence has suggested that the coastal route was used, so the timing's not only fine for humans in Mexico by 13,000 BP, but even a few millenia earlier.

I'm guessing the research was phrased more as "here's additional evidence against Clovis-first and for an earlier date" and the reporters added some sloppy wording around it to sensationalize things.

Thor Heyerdahl is that you?

This was essentially the theory that drove his Kon-Tiki expedition, exteded past Polynesia into Indonesia. https://en.wikipedia.org/wiki/...

It's a really good theory, but DNA and linguistic evidence suggest there's not much basis for it (though of course they can't do much to rule out isolated instances as opposed to larger trends).

In Canada the earliest peoples are referred to as "First Nations." https://en.wikipedia.org/wiki/... [wikipedia.org]. I like that term. I wish we would use it here (i.e. in the USA) as well.

I'm not a huge fan; "First" is a Eurocentric label that's a little dismissive of pre-Columbian cultures in the Americas. It doesn't reflect the fact that there was a rich history of cultures rising and falling in North America prior to European contact. The natives at the time were really the latest in a series of different cultures in Canada (and the Americas), not the first. See https://en.wikipedia.org/wiki/... and https://en.wikipedia.org/wiki/... and https://en.wikipedia.org/wiki/... among many others.

Copy collection and other compacting approaches have some major advantages, especially decreasing memory fragmentation, but they also have major disadvantages including higher latency and loss of cache coherence. And greater overall memory use - the old "double your memory" problem is long since solved, but if you have very large objects there are still issues there. Compacting was super popular in the 1990s but many modern GCs have moved back toward more traditional mark-sweep with incremental /generational enhancements, especially in high performance NUMA environments.

Copy collect (and related mark-compact, etc approaches) is certainly still viable in many circumstances and there have been a lot of advances in minimizing the latency impact, but calling current mark-sweep based approaches outdated or not "real" GC is nonsense.

The Bohem collector "uses a mark-sweep algorithm". I.e. NOT a modern GC

I'm not a C++ fan at all, but in this context this doesn't make sense. The vast majority of Java implementations (including the Oracle JDK) also use mark-sweep GC algorithms too, and many of the most cutting edge GC algorithms are mark-sweep algorithms. Boehm-Weiser uses a pretty sophisticated mark-sweep policy that is both generational and incremental.

http://javarevisited.blogspot.... notes that:
"Concurrent Mark Sweep Garbage collector is most widely used garbage collector in java and it uses an algorithm to first mark object which needs to collect when garbage collection triggers."

http://www.oracle.com/webfolde... explains the current generational mark-sweep algorithm used by the Oracle JDK (standard Java).

Scripting languages are:
1. Interpreted

"Interpreted" is not a language feature, it's an implementation detail. There are C interpreters like EiC (and even assembly interpreters used in things like Bochs) and Python JIT compilers like PyPy.

2. Run directly from source

Even CPython compiles to bytecode, which is a tad more efficient that running directly from source.

Beyond that, Java has proper Garbage Collection rather than reference-counted garbage

Neither the Python nor Java language defines a GC algorithm, ref-counting or otherwise, and different implementations of each use different GC methods. PyPy, for instance (which is the Python JIT implementation that most people who care about performance use) has no ref counting but uses an incremental hybrid mark-sweep GC.

Even the CPython implementation, which does use ref-counting, combines it with a generational GC to detect cycles.

Java has real support for native threads running on different cores instead of whatever kind of wimpy simulation (green threads?) is offered on Python

Python has native support for OS-level threads and has since the bad old days when the 1.1 JVM only had green threads. Python also has superior support for multiprocessing (e.g. the ability to fork() without exec(), which Java historically has lacked) which means you're not stuck throwing out memory protection every time you want to have concurrency.

You're probably conflating OS-level thread support with the global interpreter lock, which is an actual Python pain point for concurrent programming in some circumstances.

Java has a standardized GUI library in Swing instead of what the heck are you supposed to use in Python?

Alternatively one might say that Python has a real cross-platform library in wxpython that actually uses the native widgets rather than attempting to emulate them badly a la Swing.

Python fails because it's bitch to import code from SomeUnknownD00d into yours, hoping SUD was kind enough to convert tabs to spaces. And to logical spaces. If my code has tabstops of 4, and SUD has tabstops of 2, all bets are off.

This is wrong. SomeUnknownD00d can use whatever tab stop and mix of spaces/tabs that he wants and you can import from your code no problem, even if your tab stop is different or you use all spaces or whatever. Spacing only has to be consistent within a single block, there's no inter-module dependency there.

Most thieves work as teams.
Robbery is one of the crimes most likely to have a group of perpetrators, but even so the majority of robberies (55-60%) are committed by solo individuals.

https://books.google.com/books...

That was a valid point 5 years ago. Things have changed, at least when it comes to PHP.

PHP 7 running on fpm or HHVM is very fast, almost as fast as nodejs. This is not your grandfather's internet.

Python on PyPy is significantly faster than PHP7 for compute-intensive workloads, and in some cases is competitive with Java. It's still about 50%-75% slower than C/C++/Rust, but it's pretty respectable.

https://blog.famzah.net/2016/0...

PHP5+ has been faster than any given version of Python.

This is very much not the case in my experience. PHP in recent versions has surpassed CPython in speed, but is still considerably slower than PyPy (which is the JIT-enabled Python version used by people who care about speed) at least on many workloads.

PyPy is actually must faster for the file accesses... but doesn't properly close files, leading to a crash when file handles run out.

PyPy closes file handles properly. The problem is that some programs make invalid assumptions about how file closing works in Python. The Python documentation explicitly says that ref-counting semantics are not guaranteed by the language: expecting file handles to be automatically closed immediately at the end of a scope is incorrect, though it happens to "work" in most versions of the CPython interpreter.

If the timing of when file handles are closed is important, you should use a with statement or otherwise ensure that close() is called at the proper time.

I do, however, find it funny (funny strange, not funny ha-ha) that the oddest bunch of employment fields remain union shops.

Baseball players, automakers, the entertainment industry; but not coal miners or their daughters.

Coal miners have unions, and have since the mid-1800s. https://en.wikipedia.org/wiki/...

Whether you keep your fingers on the rear or the sides of your phone, you definitely don't hold it with your fingers on the front. They'd block the screen. The rear may not be absolutely ideal for everyone, but it's at least a reasonable choice (from personal experience, the top placement like the old Motorola Atrix had was fine, as is the rear placement on the Nexus 5x; you adjust pretty quickly to either).

But the front screen is the one place that people--for good reason--actively avoid having their fingers rest when holding the phone, and thus the worst possible location for a fingerprint sensor.

I'm paying $65-$75 per month for two phones with plenty of data via Project Fi. So far the service is also excellent. You were saying something about all prices being the same?

I have Fi and love it, but it's not in the discussion for the level of data usage people are discussing here--your "plenty of data" is about 4GB/mo split between 2 phones ($20 for the first phone's voice/text, $10ish for the 2nd phone, leaving about $40 to reach your $70ish total).

The post you were responding to was talking about 100 GB plans to compete with the current 20 GB "unlimited" plans--even the latter would be $200/month on Fi, and 100GB at $10 each would be $1000/month at Fi's pricing.

Fi is awesome and cheap f you are usually on wifi at home/work and so don't really burn a ton of data on a regular basis, but it's not going to replace your wired network at home the way a cheap, fast 100GB/mo wireless plan could.