3,710 karma · joined January 2, 2011
States in the US vary in nominal GSP per capita by only 2x — from Mississippi at $35K to Delaware at $70K. In the EU, it ranges from Bulgaria at €6K to Ireland at €55K. (This excludes DC and Luxembourg, which are outliers in many ways.)
In fact, even Mississippi, the poorest US state, is wealthier than the EU average (€28K, about $31K)! Only the wealthiest EU countries are wealthier than Mississippi: Luxembourg, Ireland, Denmark, Sweden, Netherlands, United Kingdom, Austria, Finland, German, Belgium, France. And of those, only Luxembourg and Ireland have a higher GDP per capita than the US average.
So the EU member states vary economically far more than the states in the US do, and the US is more easily characterized as a uniformly "high income" region than the EU is.
Mississippi's GDP per capita being similar to that of France, Italy or Spain is really hard to reconcile with the fact that many of us would love to live in the latter countries and couldn't be paid to move to Mississippi.
Rapidly-growing tech behemoths like Google can afford to acquihire hundred of engineers and, eventually, assign them to other work.
I've also found QuantStart's guide[0] to be a particularly good resource, but bear in mind that is oriented toward learning quantitative finance (in which I have no particular interest per se).
[0] https://www.quantstart.com/articles/How-to-Learn-Advanced-Ma...
The article asserts that most modern professional jobs requires only "Excel" and 8th grade programming. In my experience, over-reliance on software like Excel rather than a basic competency in numerical programming is a hindrance to economic growth. Spreadsheet-based numerical programming is opaque and ill-suited to interoperation. This leads to subtle errors, duplication of work, difficulty of replication and silo-ing of meaningful results in the private sector, the public sector and academia.
I take the second point that the transferability of critical thinking skills developed by learning mathematics is unproven. Nonetheless, history is flush with anecdotal evidence of this hypothesis, and in the absence of empirical evidence, it seems unwise to reject that hypothesis out of hand.
EDIT: removed an assertion that the article was poorly argued.
For example, with respect to the character f, the derivative
of the language for which [[L]] = {foo, frak, bar} is
Df (L) = {oo, rak}. Because foo and frak start with the
character f and bar does not, we keep only foo and frak
and then remove their initial characters, leaving oo and rak.
We repeat this process with each character in the input
until it is exhausted. If, after every derivative has been performed,
the resulting set of words contains the empty word,
then there is some word in the original language consisting
of exactly the input characters, and the language accepts
the input. All f this processing takes place at parse time, so
there is no parser-generation phase.
The specific algorithm they build off (Might 2011) has extended this to memoize repeated derivations of the same arguments and to allow for lazy evaluation in the case of recursion.But this algorithm was implemented in a mind-bendingly-slow way:
For example, they report
that a 31-line Python file took three minutes to parse!
They prove that the worst case is actually cubic time and provide a concise cubic-time implementation in Racket: https://bitbucket.org/ucombinator/derp-3Their implementation is orders of magnitude faster of prior PWD implementations, but still orders of magnitude slower than a Bison parser of the same grammar, which they attribute to language choice (C vs Racket).
Please correct me if I'm wrong about any of this! Summarizing research like this helps me understand it, but that doesn't mean I actually understand it.
[1] https://www.seventy.org/publications/2012/01/04/councilmanic... [2] http://www.phillymag.com/citified/2016/05/09/kenyatta-johnso...
25 comments and good discussion there.
It's worth noting that for most of us, most of the time, this kind of JS performance is less important than user-perceptible optimizations, like batching DOM reads and writes and decreasing asset size