I've been working on a virtual table (not for React, but KnockoutJS) that's designed around needed to virtual scroll over a large number of columns (as well as rows). Really in-progress code at the moment, but getting there...
3. However - you are right in one respect. There is usually a 'pull to the mean'. That means that children of exceptional people tend to be closer to the average, thus they are not as gifted as the exceptional parent.
Would an individual have been chosen for sterilization if:
1) He was born with a markedly pointy head, which caused much consternation to his parents and relatives.
2) Was developmentally backward. Notably, he failed to acquire language skills for a significant period during his early childhood.
3) He was educationally subnormal, showing signs of what would now be diagnosed as ADHD,and drugged into a stupor.
4) Was bone lazy. I believe that 'schweinehunde' was the informal term used at the time for this condition.
5) Was disobedient and rebellious, or one of those 'malcontents' that perennially threaten to upset the applecart of society (the term 'hooligan' enjoyed a brief vogue for describing this condition).
6) Was Jewish. The eugenics movement designated Jews for mass sterilization, along with Blacks, Poles and the 'bloody Irish' (but then again, these were the same dolts who thought that sterilizing homosexuals would somehow serve to 'keep the race pure').
Albert Einstein was a prime candidate for this preemptive culling.
If anything, Jews (or more precisely Ashkenazi) are a poster child for eugenics - since really that's what they went through in the middle ages, which is used to explain their enormous achievement (see http://www.economist.com/node/4032638)
Sure, but that's a bit of a burden for library authors, don't you think? I appreciate all the freaking hard work the definitely typed guys do, but I hunk there's a few structural problems in the project:
* everything in a single repository on GitHub. Makes it hard, for instance, to reuse from other package managers, like Bower
* they don't have a good story around versioning different libraries. Last I checked, they had a typescript wrapper for jQuery, based on the latest version. Sticking with an older version? No accurate type definitions for you!
> they don't have a good story around versioning different libraries. Last I checked, they had a typescript wrapper for jQuery, based on the latest version. Sticking with an older version? No accurate type definitions for you!
Nobody forces you to stay up-to-date with the DefinitelyTyped repository. If you want definitions for version X, look at the definitions that were recent shortly after version X was released. Not completely effortless, but also not a structural, deal-breaking problem like you said.
It's not just about staying at a particular version. It is about being able to find the version that matches what you are using. I recently started an new project using bootstrap and had to downgrade to v3.0.3 due to some incompatibilities. I have no idea how I would go about finding the matching type definitions from definitely typed. Their version numbers don't match bootstrap's (http://www.nuget.org/packages/bootstrap.TypeScript.Definitel...).
Also, how will the Definitely Type project be able to handle a fix to the definitions of an old version that doesn't apply to the current version?
Like jstclair I appreciate their hard work, but I think they really need to change their approach soon to avoid a lot of pain down the road.
There is a project that converts Typescript to Closure type annotations. If you do this, and put Closure Compiler in your continuous build/test phase, it will can catch when there is a mismatch between the caller and the library, not in all cases, but it helps.
I wasn't talking about manually adding in the assertions into the library code. The idea is that you would take the type declarations that people are already writing and have the Typescript runtime add some sanity checks to verify that they are correct. TS doesnt do that because it insist on not including any extra runtime code so if there is a error in a type declaration that problem might go undetected or onyly cause an exception in a different part of the code.
I can see that library versioning would be annoying but I think its more of a ecossystem problem then a technical one.
It seems excessively defensive to tell people who express a
desire for better solutions to get out of the industry. If everybody accepts bad tools out of learned helplessness then there is no impetus to make things better.
I came here to make a similar point, the author states:
"TypeScript is not the answer. Or perhaps it’s more accurate to say it is the answer to a different problem."