Hacker Newsnew | comments | show | ask | jobs | submit | login

If you're not familiar with the author, Dan Davies, he's been a contributor at Crooked Timber (http://crookedtimber.org). A great intro would be his choose-your-own-adventure intro to the Greek financial crisis from 2012 (http://crookedtimber.org/2012/02/16/so-what-would-your-plan-...).

Paul Krugman called this post from 2004 one of the great blog posts of our era: https://dsquareddigest.wordpress.com/2004/05/27/108573518762...


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...


[Live Demo](http://jsbin.com/roheqo/1/)

You can edit that on JsBin and easily increase the columns to 5-10,000. You may want to look at [editableCell](https://github.com/gnab/editableCell) for some of the keyboard shortcuts.


That's really nice work John - thanks!


Yea that is very nice!


So you've just sterilized the Einsteins...

The whole premise is that "like produces like", which of course is nonsense. Dumb people have brilliant kids, ugly people produce beautiful children, and so on and so forth.


1. The Einsteins were a fairly intelligent family - so it's a bad example: http://en.wikipedia.org/wiki/Einstein_family

2. You are wrong vis-a-vis heritability of intelligence. It is largely determined by genes: http://en.wikipedia.org/wiki/Heritability_of_IQ

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.


I think your comment is a good example of why talking about intelligence is hard.

Note that nobody here advocated forced sterilizations (or killing off ugly babies).

All we said is that it's pretty much settled that intelligence is inheritable.

PS I will contend one point - and that is whether Jews were marked for mass sterilization. That is false.

Jews were marked by Nazis for extermination. However - people who advocated eugenics in other countries (like US or the UK) had no issues with Jews (http://en.wikipedia.org/wiki/Eugenics_in_the_United_States).

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)


Awesome! Gonna spend a weekend on this.

And an easy way to share my personal all-time favorite title sequence, Delicatessen:



I have to link to North by Northwest. Just incredible when you consider it was done in 1959.



Have you thought about a Vagrant + Docker tutorial next? I got a few different Docker images running vNext on my Mac; it's great, but not really a development-first solution.


Anyone else wonder why a self-driving car needs side-view mirrors?


to get out safely avoiding incoming traffic once parked.


Joe Duffy has a really interesting retrospective on his team's attempt to build a STM for .NET:



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.


Well sure but compare that workflow with almost any other package manager. NuGet, for instance:

install-package jQuery --version 2.0

We haven't had major problems with DT, but I see that over time this is crying out for a fix


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.


I'm DT org member: I posted a big reply about DT further in the thread: https://news.ycombinator.com/item?id=7498775


I've worked on a large typescript project for the past 6 months with 5 developers, and this type of superficial analysis doesn't track at all with our experience. Yes, TypeScript is a superset of Javascript - aimed at making large projects more maintainable. If, as this seems to saying, you're starting with the assumption that JavaScript is a terribly flawed language, TypeScript probably isn't going to make things magically better. But then, perhaps you should consider working in a different area of your application (or the industry), because JavaScript is what we've got to work with.


It's not a prejudicial "assumption" adopted ahead of experience that JavaScript is a terribly flawed language. It is something one sees by experience with JavaScript. Actually, the existence of all these transpilers makes no sense if JavaScript is already so wonderful as it is.

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."

And I think that's a valid point. TypeScript is an answer to the problem of developing and maintaining a large body of JavaScript code. JavaScript alone is pretty good for small scripting tasks and TypeScript is similarly too much overhead for small tasks.

But TypeScript does nothing to fix the "JavaScript minefield" which is what the author thinks needs to be solved.


Nice... Anybody using cli tools like this in conjunction with a git client-side post-commit hook?



Applications are open for YC Summer 2015

Guidelines | FAQ | Support | API | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact