Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Too much of the research process is now shrouded by the opaque use of computers

theconversation.com

Post reply on HN
Print view View original

41–50 of 55 posts

Re: Too much of the research process is now shrouded by the opaque use of computers

#41

Post by rspeer »

guard-of-terra wrote: post #11
amelius wrote: post #7

Earlier quoted context omitted.

But if somebody would read the publication in, say, 20 years, then the whole platform on which the computation has to run might have become obsolete. Suddenly, you have to look for emulators. Or even for emulators running emulators.

With some effort you could make it work, perhaps make a pull request. Programming languages will likely still be around. Using open formats and tools would likely help.

You won't succeed at making a "pull request" in 2035 against a piece of code written in 2015.

The person who wrote the code has another job now. The programming language it's written in is unsupported and unsafe to run. The site it's hosted on was sold to a holding company and then taken down. The entire concept of a "pull request" has been replaced by some new idea that's as foreign to us as a pull request would be to developers in 1995.

Re: Too much of the research process is now shrouded by the opaque use of computers

#43

Post by tejtm »

If this issue is interesting to you from either the researcher or software engineering side please consider working with, taking classes from, or just supporting Greg Wilson's Software Carpentry http://software-carpentry.org or the spin off Data Carpentry.

Full disclosure: I am not affiliated in any way shape or form. Just a fan of the intent.

Re: Too much of the research process is now shrouded by the opaque use of computers

#44

Post by Fomite »

gilleain wrote: post #18
grhmc wrote: post #5

In my experience, scientists are like extremely junior developers with PhDs. They name functions "wstok" instead of "whitespace_tokenizer" because it uses fewer keystrokes. They can't be bothered to commit code. And when you do manage to get them to commit code, it is isn't the same code. It is close to the same code, but different. They think "close enough" is close enough, even though they recognize that without th…

A little harsh, but yes in general scientists don't write great code or use the right tooling. The reason is simple : the purpose of science is not to write code but to write papers . That's not _at all_ to say this state of affairs is a good thing, but the practical reality is that scientists are judeged by academic papers, not code. So, time taken learning how to code is time taken away from learning to write paper…

There's also very little incentive to write code that's ultra-transportable. For the most part, I'm using it, for this one specific thing, and that thing alone.

I once refactored some code of mine to make it way more accessible and automated. It was, to be blunt, a complete waste of time.

Re: Too much of the research process is now shrouded by the opaque use of computers

#45

Post by Fomite »

cema wrote: post #21
cryoshon wrote: post #16

Earlier quoted context omitted.

This is accurate. I am a good example of this phenomenon. Scientists don't know how to code in a way that is intelligible to someone else, and in academic shops, there's probably only going to be one person who writes/understands a program in the first place. This one person probably views coding purely as an icky means to an end, and his adviser thinks it's a waste of time if it even reaches his knowledge whatsoever…

I think the core of the problem is that coding and documentation are not considered part of the "science". Contrast it with writing papers, which is understood as communication with scientific peers, the community, and therefore is "science" -- and, of course, is one of the measures of scientific progress. Writing code is not. Anecdotally, writing papers about code is (on occasion), so maybe there is a way to convinc…

I think a more fundamental problem is that coding and documentation aren't actually taught in a formalized way to many scientists, so you pick up the habits that worked for you at the time, and just carry those forward.

Re: Too much of the research process is now shrouded by the opaque use of computers

#46

Post by kjdal2001 »

p4wnc6 wrote: post #36
kjdal2001 wrote: post #23

Earlier quoted context omitted.

I have had a similar experience working with financial engineers and traders turned programmers (I am a programmer). They don't seem to value software the same way as programmers. They seem to view their ideas as the most important aspect of their work, and writing software is only a way of expressing their ideas. The problem with this is that if you don't feel that their are non purely functional requirements worthy…

The other problem with it is that they don't appreciate that probably more than 90% of all code (including the code that touches their ideas) is for unsexy reporting purposes only. The domain expertise accounts for probably 1% to 5% of any business's code, and generally it's the easiest code to design, test, and change later on because it follows very tightly with well-worn practices in scientific computing. You migh…

Im not sure its a 90-10% split between the importance of infrastructure to business logic code in our case, but I don't think you necessarily need to make the distinction.

Something that I've run into a few times is when an FE will come up with a proof of concept that needs to be built out into something more robust, and it takes longer to build it out than to come up with the concept in the first place. This is often because the original POC is more or less a direct translation from pure math, while the real application needs to be worked into a multithreaded program for performance reasons. That often comes with significant changes to the way the business logic gets executed.

Software isn't merely a concrete implementation of pure mathematics. It is a logical system that bears some resemblance to math, but has a number of details (hierarchal memory model, network latency, etc...) that make it act quite differently. I think you can iterate on an idea faster and with fewer bugs if you treat it as a software problem from the get go rather than working on the idea and the software separately.

For example, I once had a frustrating argument with an FE about why a program he was working on wasn't working correctly. He thought I didn't understand the normal distribution and how the tails never quite reach zero. What he didn't understand is that the computer doesn't care what a normal distribution is supposed to be, if you try to deal with numbers on the order of 1e-100 in a float in c++, it might as well be zero.

Re: Too much of the research process is now shrouded by the opaque use of computers

#47

Post by ubasu »

chrisseaton wrote: post #40
ubasu wrote: post #39

I don't disagree that badly-written scientific code exists (both in academia and in the industry), but I want to point out a couple of things for people who have only a software engineering background. 1. Keep in mind that most scientific code for numerical analysis, being based in mathematics, follows the convention for using algebraic symbols, e.g. even in physics, we write F=m*a instead of the wordy version, which…

Why isn't your compiler unrolling your loops for you?

Modern compilers should, but there is a lot of legacy code.

Re: Too much of the research process is now shrouded by the opaque use of computers

#48

Post by swiley »

maliker wrote: post #14

Amen! I work in electric utility research. Pretty much every paper gives some simulation results. Getting the source? The only option is emailing and hoping the researchers respond, want to share, and have code that runs on something other than laptop of the student that built it. I haven't ever succeeded in getting working source code. There are many simple improvements that could be done. Just a github repo for eac…

I'd imagine one of the problems with that is most researchers must sell the rights to their research to journal publishers.

Re: Too much of the research process is now shrouded by the opaque use of computers

#49

Post by sopooneo »

rspeer wrote: post #41
guard-of-terra wrote: post #11

Earlier quoted context omitted.

With some effort you could make it work, perhaps make a pull request. Programming languages will likely still be around. Using open formats and tools would likely help.

You won't succeed at making a "pull request" in 2035 against a piece of code written in 2015. The person who wrote the code has another job now. The programming language it's written in is unsupported and unsafe to run. The site it's hosted on was sold to a holding company and then taken down. The entire concept of a "pull request" has been replaced by some new idea that's as foreign to us as a pull request would be…

Right. I look down the road when the drive isn't to migrate to Python 3, but from it, to PyGo 1.4. And damn-it, what is this PoGo thing? We had PIP! PIP worked! Why are this tri-ennials continually reinventing stuff we had completing worked out by the early 20's?!

Re: Too much of the research process is now shrouded by the opaque use of computers

#50

Post by ambiate »

ubasu wrote: post #39

I don't disagree that badly-written scientific code exists (both in academia and in the industry), but I want to point out a couple of things for people who have only a software engineering background. 1. Keep in mind that most scientific code for numerical analysis, being based in mathematics, follows the convention for using algebraic symbols, e.g. even in physics, we write F=m*a instead of the wordy version, which…

I don't know why this is getting down voted.

I've come across near duplicates of this code and its always "that's how we did it after punch cards."

Post reply on HN