Hacker News Reader

Comment by vngzs | Hacker News Reader

You have the right idea, but an unhelpful perspective. Certainly not everyone who isn't a software developer is a "phony scientist!"

If you'd like to convince scientists to come around to your line of thinking, explain the problems with current research papers. Tell them about the problems with publishing papers only, how others struggle to reproduce their research, and how it leaves much bad research that would be invalidated far sooner except that the information to recreate their trial was absent.

Then explain how sharing the code and data with Git (or similar) can solve this problem. You'll find that you are much more persuasive.

View on HN

I agree with you that this isn't a persuasive approach. But I'm cutting to the chase.

If anyone is working on this—helping onboard academics and non-programmers to git—this is an idea I'm looking to support (as an investor, donor, or whatever).

Isn't git an implementation detail here? Git repos don't have to be publicly available. They also don't have to contain history or multiple versions at all.

I'm guessing what you really want is:

1) open formats for data

2) plain text instead of proprietary blobs

3) the ability to replicate calculations easily

4) the ability to see some sort of evolution or mistake-fixing in the project's history.

Git is an implementation detail in the way x86 in the 2000's was an implementation detail. Of course in theory what I'm talking about doesn't have to be git, it could be another extremely well engineered, capable, reliable, trustworthy, auditable, fast, ubiquitous version control system. But in practice that means Git and there is nothing on my forecasts that will come close to dethroning it in the next 10 years.

I have seen 50 startups that have pitched building a shittier version of git for academics because they can't be bothered to spend time reading the internals of git and have no idea how well done it is.

> I have seen 50 startups that have pitched building a shittier version of git for academics because they can't be bothered to spend time reading the internals of git and have no idea how well done it is.

I suspect git would make a fine back end for a more polished product for scientists. A github for scientists sounds very interesting.

> I suspect git would make a fine back end for a more polished product for scientists.

Agreed! That could be a winning idea.

> 4) the ability to see some sort of evolution or mistake-fixing in the project's history.

Rather than 'mistake fixing', what I want out of a project's history is evidence that the author hasn't done some form of p-hacking. But that purpose can be served just as well by preregistration. https://en.m.wikipedia.org/wiki/Preregistration_(science)

Reply on news.ycombinator.com