The argument is nothing to do with machine chugging time, and is entirely towards developer time. The problem with expressive languages like Lisp, Ruby, Python, etc. is that the language ends up varying from person to person - the more expressive the language, the more variance there is. This is a feature when you're a small team because the abstractions you build let you move quickly, but it is a bug when you're a large team maintaining a piece of software over years, where developers have come and gone. The ramp-up time to learn and understand the various abstractions that people have built over the years ends up accumulating and cancelling out the gains that those abstractions gave earlier on.

Blub languages on the other hand tend to be more uniform, so it's easier for someone who isn't very familiar with the code to dive in and understand what is going on.

Not really actually, there are still loads of C devs (or C++ at least) and a lot more jobs in C and C++ than for Go.

Having made engineering decisions between C++ and Go, my key reasons for picking Go over C++ are:

* Simplicity when multi-threading

* It's much easier for someone who knows neither language to become productive in a professional environment in Go than in C/C++

* Fast compile times - no more typing "make" and then going off to get a coffee

* Lots of modern niceties that are more fragmented in the C world: third-party vendoring, unit testing, style guides, etc.

This is in the US, not sure if it's the same in other countries.

One of the points that the article makes is that this statement is changing, that computers are increasingly creating their own rules. The literal next sentence:

"New artificial-intelligence programs are also writing their own investing rules, in ways their human masters only partly understand."

You're right though, that the responsibility still falls on the humans. Anybody running algos that they don't understand should ensure that they are covered from a legal/ethical perspective.

https://www.youtube.com/watch?v=TQs3gVobcfg

This paper is pretty simple, it's just a straight-forward before-and-after test. They are holding a lot of factors constant and not doing an observational study, so 77 is actually a fine sample size for something like this.

Yep, this does happen. The point though, is to let shareholders rather than managers decide if this is a good choice. If managers are sacrificing the long-term health of the company, shareholders can vote them out or choose to sell their stake.

This is one of the downsides of the rise of passive investing and ETFs based on market cap - less votes are going into the system and holding people accountable.

> In this study, we tested 77 undergraduates who were randomly assigned to play either a popular video game (Portal 2) or a popular brain training game (Lumosity) for 8 h.

This is exactly the reason why Typescript took off and none of the other compile-to-JS languages did (other than a brief flash by CoffeeScript). Dart had a very similar problem as Reason - it wasn't Javascript. The interop between Dart and JS libraries was just too much of a pain to deal with, where in Typescript everything just worked.

Since building your own ecosystem that rivals the JS ecosystem for libraries is an extremely difficult task, any candidate to replace JS must have good interop with its libraries to be successful.

One of the competitive advantages of the US has been its ability to draw top talent from all over the world and not just its own citizens. Chinese citizens leaving the US is not a good thing, but it is just one nationality. If China manages to draw talent from everywhere, then the US has a real problem ahead of it.

For example, my team in the US only has a few US citizens on it, most of us are foreigners who moved here for the opportunities. While a few are Chinese, the majority are from countries other than China and the US.