I suspect it’s more about people doing nothing _outside_. In other cities and climates, there’s plenty of people doing nothing at home, in front of their TV or computer.
Do multiple competing unions happen in the same workplace happen in the US ? As far as I have seen, that seems fairly common in the countries where I have lived (Europe only). And are there some cross-category unions (where workers in different areas and jobs are members of the same overarching organization, which sometimes organizes nation-wide demonstrations or even strikes)?
There’s still Coursera courses with free quizzes and assignments. Among those I’m enrolled in right now, Corporate Finance Essentials from IESE Business School, Big Data Analysis with Scala and Spark and Principles of valuation: Time Value of Money all have free quizzes.
Have you encountered limitations in Elm that pushed you to resort to writing JavaScript (as opposed to using JavaScript libraries from Elm through ports)?
The delta between the type systems is small enough that people have tried to automatically convert TypeScript type definitions to Flow. One notable difference is that Flow supports declaring types as covariant/contravariant. I suspect that as far as most application code bases go (as opposed to libraries), you would almost see no difference.
I struggled with multiple blind spots in Flow in the past, but recently tried porting the same code to Flow and Typescript and I was surprised that Flow took less work than TypeScript. Flow 0.43.1 has become very fast and seems to need less type annotations compared to TypeScript with noImplicitAny enabled. I wonder whether Flow’s happily infers any without complaining or whether its program flow analysis remains more sophisticated.
Flow’s interesting, unfortunately it requires more invasive changes to your code than just prop types. For example, if I remember correctly, you need a declaration for a class component’s state.
I think the point is a bit moot. Since it’s just JavaScript, you can put pretty much any logic in a React component just like you could also put any kind of logic in an PHP template or inside a view in iOS.
For me, the gain is that you can track all interactions in a single spot. If stores trigger updates on each other, you end up with a web of dependencies that take a long time to trace through when making changes or debugging.
‘One-way data binding by default, with opt-in to mutable, two-way bindings’. It looks like React’s emphasis on unidirectional dataflow has made converts!
What subjects are you comparing with? I don't know whether the situation is that much better for physics, for instance. I think part of the problem is that mathematics books are in general either targeted at experts or at professors who need to assign a textbook. It looks like publishers believe the market for self-taught mathematicians is too small. In contrast, programmers are a pool of people who are willing to spend money on books to teach themselves, because they hope it will have a direct career benefit.
That said, mathematics curricula must vary a lot from country to country. I was taught the fundamental of calculus in my penultimate year of high school!
I find that testing has improved quite a bit since actions now return a Result object that you can inspect in your tests. It is true that you cannot inject a mock data repository, for example, but Controllers are meant to be simple HTTP response generators and you might want to make them call some domain object to perform anything complicated. You can then unit test you domain object to your heart’s content.
As someone marginally involved with the Play project, I would like to point out that, for better or for worse, Play 2.0 is a complete reimplementation of the original design, with a new API and a totally new codebase. Play 2.0 core is now written in Scala (but also exposes a Java API) and relies much less on bytecode manipulation.