"even after taking into account other factors such as smoking, high blood pressure, diabetes and age"
But not IQ and social status,bilingual people are more likely to score higher on both and this could be an aspect of healthier cognitive functions rather than how many languages you know.
Came here to say the same. Correlation is not indicative of causation. Bilingual people are more likely to be more upwardly mobile, and therefore likely have access to better care. Neurology probably has nothing to do with it.
Too little too late and not good enough,very little offered for splitting the user base.
Python in the long run is badly positioned as
1. Moores law partytime is over. Performance matters again and the language has significant upper limits on speed.PyPy is not fast enough and further splits the user base.
2.As performance matters again concurrency matters more,concurrency in python in horribly implemented.
3.AsyncIo, What the hell am I even looking at? Gevent is vastly simpler than this.
It is a pity as it is one of the cleanest languages around and a joy to code in.
But programmer productivity is more important than speed you say? We in many cases that is true but languages like go and Julia can offer both so why program in a slow language which you may have to replace later when its almost as easy to take another option and have everything?
I really don't see how PyPy is "splitting the user base" when you have to make close to no changes to your code to gain an appreciable speedup in 90% of the cases.
I see many people compare Python to Go and frankly? Go isn't nearly as nice to work with as Python (no exceptions? one among many small but noticeable annoyances). It's much nicer than C or C++ in cases where you require the raw performance but it isn't a replacement for Python.
There are also many areas where performance is literally of zero consideration (small scripts to automate stuff) and those areas are where Python is hard to beat.
I think the problem with Go coming from Python is that the paradigm shift is a lot more substantial than it appears at first blush. My experience was quite the opposite: Go is pleasant to write in, exceptionally simple, and once you fully grok (and appreciate) slices and channels, the expressiveness of the language starts to take a life of its own. I never missed exceptions much (again, because you have to completely accept Go for what it is) and the fact the language specification is so short makes it easy to understand and relatively fast to pick up. Plus it's fast.
My problem with Go has nothing to do with the language per se. Instead, my reservations fall mostly on the ecosystem. It's immature and compared to more established languages like Python, it isn't nearly as rich (after all, it isn't as old). I gather from reading the mailing list archives off and on that there's been some inertial resistance toward certain frameworks (I can't really fault anyone for this--Martini and Revel have too much "magic," for example), and in some cases, prospective users are advised to "roll your own" if it's not something in the standard library. But when it comes to certain odds and ends, it's just downright difficult at times to find something that works as well as its Python counterpart out of the box and is relatively API stable (blackfriday, the Markdown parser, comes to mind--but then I guess offloading that to the client using JS might be better these days?).
Also, the abuse of the word "idiomatic" grates on me a little. There was someone on HN a number of months back who joked (paraphrasing) "Great, we're going to see 'idiomatic' abused as much as 'pythonic' and 'pivot.'"
But, that's why I do agree with you: Sometimes performance doesn't matter quite as much as the ability to avoid "not invented here." And Python has libraries for almost everything--SQLAlchemy is probably one of Python's "killer apps." (I expect Go will progress there, one day, but for some use cases it's not quite at that point in my experience--so the answer is probably to contribute to those Go libraries/projects you find of use.)
Pypy3 + STM is coming, which should resolve your first two points. Pypy is fast enough for most, and is gradually getting faster. I don't see at all how it splits the user base.
With regards to asyncio, a lot of people would disagree with you.
Too little too late? Maybe...that's for you to decide. Yes, there are new competitors that didn't exist when the decision was made to pursue the Python 3 strategy. But Julia has nothing close to the standard library + ecosystem that Python does, and probably won't for a long time if it ever does; and while Go is coming along in that regard, there are some aspects that make it less preferable to Python, especially JITed Python with software transactional memory (i.e. no GIL). I, for one, would never want to code without exceptions if I had the choice.
> PyPy is not fast enough and further splits the user base.
There is no split?
> Gevent is vastly simpler than this.
I prefer asyncio's explicitness to gevent's monkey-patch-and-pray-it-doesn't-block semantics. Also, the asyncio approach makes it very clear when you have released the "lock" on your state--it happens every time you yield from your coroutine. The gevent approach is to hide these synchronization points, which I think is a bad policy. For what it's worth this latter objection is one of the main reasons asyncio is the way it is--GvR had been bitten before by implicit yields.
If you're needing to think carefully on what code you call might cause a switch and what won't, you're already doing it wrong. Instead of treating gevent like coroutines with less predictable ordering, treat it like threads with more predictable ordering. You know that basic operations (eg. checking if something is a certain value, or assigning a variable) won't cause a switch. So you can do two of those in a row, without thinking about race conditions. Anything beyond that...use a lock (or a queue, or any of the other provided concurrency primitives).
Well, thanks to operator overloading, comparisons or assigning a variable (to a property of an object) can cause a switch. If you really need to get a mental model of what your code is doing, or could do under sufficiently unusual circumstances, gevent doesn't really provide any guarantees beyond raw threading.
gevent simply has the nicer API. I've never once had an issue where the monkey patching failed, or conflicted with another library. Yes, monkey patching is a dastardly and gross thing, but in practice gevent works amazingly well for 99% of use cases.
Not to mention the performance is very good, especially in the most recent version.
A VC may win by maximising profit but a VC employee has to protect his reputation."We made a mistake but so did everyone else" is an unfortunately successful defence.
“Worldly wisdom teaches that it is better for reputation to fail conventionally than to succeed unconventionally.”
Keynes
For those of us outside California Quora seems little more than a silicon valley circle jerk.A better branded version of the old experts exchange,though its not hard to brand yourself better than the company with the second worst url in internet history(I wonder how mole station nursery is doing these days?). The very the people who have benefited from the internet revolution move to limit access to publicly provided information,information they themselves did not even create.Nice job kicking out the ladders from under you.
If I ever get hit on the head and want to live life as some someone else's virtual pet ill be sure to check out foursquare as well(oh you went to the pub,who's a good boy?Have a virtual cookie).
Stack Overflow does a lot wrong,half of my favourite answers are marked as closed for some arbitrary reason but at least it can provide open and accurate answers to questions in specific problem domains.
In the land of the blind the one eyed man is truly king.
The best way I found to do this for python is by using Tornado,you have an excellent websocket implementation baked in and a scheduler within the webserver itself so its simple to poll for changes and update only when necessary,or interleave with a call back if you want "true" real time. Plug in a front end with angular/knockout etc,pass around json objects and you are good.
As far as meteor/node goes,having the same language on the server client is great. Having javascript as that language is not so great. Web apps are generally a front end to something bigger and I never want to do any serious data wrangling in javascript if I can avoid it.
