Comment by colechristensen | Hacker News Reader

Comment by colechristensen | Hacker News Reader

Parent Full thread

colechristensen

Scientific programming is just different. Much of the culture of scientific programming is different and with good reasons not easy to understand.

Its something like how baking cookies at home and running a cookie factory are very different. To a person doing each, the behaviors and priorities of the other seem strange and it’s easy to for one to think “we are both just making cookies, why don’t they do what i do which is obviously superior “

Scientific programmers are solving problems first, not writing programs. They are solving problems in a way that is useful only to them or peers who know a whole lot about the problem being solved. The problem-first tools look strange because they deemphasize the programming niceness in favor of problem niceness.

You find the same sort of confusion when programmers are facing business types and excel usage.

There are certainly times when a piece of code starts needing the programming touch, but the right tool for the job depends on the job.

As someone currently writing scientific programs for scientists, much of the culture of scientific programming is bad and they are having rings run around them by kids who build websites for a living and it's embarassing.

You think web developers are just writing programs for the hell of it? They have operational constraints around their work as well, it's just that there's a rad open online culture of continuous process improvement that's leveling up the tooling and practices that makes what was once hard look easy.

Things scientists using computers can learn from people working in the software industry:

- use a version control oriented workflow

- write extensive tests

- data management, automated data processing/cleaning pipelines, backups

- build generic frameworks

- use continuous integration

- logging and error reporting for long running tasks

- use modern tooling for automating infrastructure and big jobs, rather than manually submitting Slurm jobs via SSH

#notallscientists but the average level of competence is not good and I think the idea that writing software for scientific research is somehow special is backwards and counterproductive.

None of those get you closer to tenure I guess... There used to be research engineers in 'good' labs, friend of mine was. They'd take your software weekly, clean and slice it, help you write tests, connect you with other colleagues or orgs, show you how you could achieve 30x perf when needed, would help you make your shit distributed, would get budget for CI and stuff. That was a dream job for me, for some time, since I'd been mentored by a demi-god of non-destructive-control (radiography, ultrasound...) and radioprotection research that was also a C++-expert sw engineer who had the most beautiful and clean/clear/modular/malleable codebase I've ever seen, and I saw the yuge potential of somewhat even passable sw engineering, especially when I understood his software was used in so many different operational contexts and also advanced research projects without his input, and his colleagues' sw were just toys, toys and more toys.

I don't see that many job posts doing this anymore. And even then it's just not valued that much.

I think the problem is that these academics literally do not understand or appreciate the benefits of having, say, a robust test suite with CI. Software development and DevOps is an alien culture and to be fair a good proportion of software developers themselves don't really get it. It's like a professional lumberjack who regularly sharpens their saw vs a forestry researcher who doesn't realise how slowly they're chopping down trees for samples because their saw is always blunt.

Are you really building generic frameworks and writing extensive tests every time you do some data exploration and analysis in R Studio?

No. You'd be using pre-existing high-level tools for this purpose (in Python land this would be pandas, matplotlib, jupyter etc).

Not all software development should involve writing your own framework, and it's a bit of a trope that junior SWEs try to write DSLs and frameworks where they should just write some throwaway code. That said, if there's a common modelling or simulation method in your field and there's no great open source generic framework for it, then you should take a hard look at what you are all spending your time on (endlessly reimplementing the wheel).

> use modern tooling for automating infrastructure and big jobs, rather than manually submitting Slurm jobs via SSH

Is that going to be robust to whatever new cluster comes along five years down the line, or will it all have to be re-written?

Yes. Rewriting this stuff is much easier when you've already automated it the first time, vs scratching together instututional folklore on how to run a job.

There's no good reason for something being difficult to understand. Especially a product that's been designed to be general purpose.

You give good reasons for why a certain situation exists in scientific communities, but I see no reason why it has to be that way.

Being "difficult to understand" is a perspective of an individual observer, not some fundamental property of the thing itself. Japanese is "difficult to understand" if you only know English, but not if you grew up speaking Japanese.

The various conventions around "accepted" programming paradigms like OO, inheritance, scoping, etc are natural if you use them every day for years, but if you're more interested in optimizing some finances or solving a physics problem, something "primitive" or "messy" like a spreadsheet formula or fortran might actually be more understandable.

I couldn't agree with more OP. I got my graduate degree in Statistics and, after working for several years in such a role, made a similar vow to Never Again™ touch R (or SAS). This effectively forced a career change. (I'm now "officially" a software developer and couldn't be happier.) My distaste for Statistics stems directly from the commonly used tools.

I appreciate your point. In most contexts, such as your comparison between Japanese and English, I agree with it. However, paradigms like OO, inheritance, scoping, etc. are hard-won, intellectual accomplishments; they're not arbitrary. They're purposefully designed to solve specific problems. My experience with R showed it to be rife with problems that have been avoidable for decades. AFAICT, it boils down to the tragic view of "I'm a (statistician|engineer|mathematician) not a coder so I don't need to care". The unfortunate truth is that despite such a view, doing analysis with R makes the analyst a programmer by definition. And so the language, ecosystem, and, consequently, users suffer from half-baked, poorly designed workarounds to problems which have long been solved (and abundantly documented in the software literature). To reduce it to a matter of perspective feels to me like a tautology: it's easy once you get it.

Clearly, I'm triggered by this. I hope I've expressed myself respectfully. My point is, I don't feel it's arbitrary. The design and complexity of R has real consequences in terms of cost and reproducibility.

I use R regularly. I love it. Doing the maths is very easy and general. The programming makes me think differently. I like how it's high level, reasonably fast, rarely involves loops or inline functions directly, and, above all, is the Swiss army chainsaw of statistical analysis. The fact that the journal of statistical software exists is a good thing!

Inheritance was invented for performance reasons [1]. It was not conceived for pure code organization, so in way it is arbitrary as any other solution that could have brought performance gains for the original garbage collector. Inheritance is an "intellectual accomplishment" as other accomplishments, that will incur into issues if applied blindly, so not having it is not an issue per se. On the contrary, today's widely accepted view of inheritance is to rather use composition instead of it [2].

R does have inheritance by the way, not as you will see frequently on "general purpose" programming languages, thing R is not.

[1] http://catern.com/inheritance.html [2] https://books.google.pt/books?id=ka2VUBqHiWkC&pg=PA81&lpg=PA...

I would say that "inheritance" was much developed in Smalltalk, and there it was not really a tool for improving performance. Rather it is a conceptual tool.

"Inheritance" is really the expression of Abstraction in code. Superclass is more general, and thus the abstraction of its subclasses.

Although Smalltalk did not have a specific keyword for "Abstract Class" it used the convention of calling "subclassResponsibility" on methods defined in abstract subperclasses which had to be implemented in subclasses.

Abstraction, generalization, these are conceptual tools. I'm not sure how "composition" models abstraction if at all. Only OOP does.

And one could think that abstraction is a tool valued by scientists. No?

I don’t know why you are saying inheritance was invented for performance reasons? Is there any evidence behind that?

Everything I was taught when OOP became mainstream in the late 80s, was that it was a performance trade off to afford code organization insight, while preserving encapsulation.

This statement about “performance reasons” is quite baffling.

> Being "difficult to understand" is a perspective of an individual observer, not some fundamental property of the thing itself.

I disagree. There are inherent qualities associated with systems that happen to be easier to understand. If you or I were designing such a system, and wanted to ensure this system imbued similar qualities — I believe it would be possible to do so.

> Japanese is "difficult to understand" if you only know English, but not if you grew up speaking Japanese.

Needing a priori knowledge to be able to understand something, is different.

> I disagree. There are inherent qualities associated with systems that happen to be easier to understand. If you or I were designing such a system, and wanted to ensure this system imbued similar qualities — I believe it would be possible to do so.

Can you formalize these inherent qualities? Until you can, it's hard to prove that a quality is or is not essential.

> Can you formalize these inherent qualities? Until you can, it's hard to prove that a quality is or is not essential.

There is an obvious one, though it's tricky to fully formalize and quantify: locality (also known as "coupling"). You ask yourself a question, "if I were to make a small change to a single piece of this program, how much of the program would I have to change/retest/keep in mind?". If the answer is, "typically, just the area around the change", it's a high locality (loosely coupled) program, a good design. If the answer is, "usually, most/all of it", then it's low locality (tight coupling), a bad design.

The reason is, of course, that human mental capacity is limited and in general, number of interactions grows superlinearly with the amount of interacting components. So this here is an objective measure of "easy/hard to understand": the more code you have to keep track of when investigating a random piece of the program, the more mental effort you have to exert - the more difficult to understand it is.

Of course difficult and easy exist. It’s hard to run a marathon it’s easy to eat popcorn. It’s hard to learn Japanese it’s easy to watch tv

I'm wondering what your opinion is of this talk: https://www.youtube.com/watch?v=7jiPeIFXb6U

It has some comments about why good software engineering leads to good software, how good software engineering is hard right now because there's a lot of bad examples which cause people to make more bad code, and some suggestions on how things could be done.

Love this point

It's no more difficult to understand for researchers coming at a programming language for the first time, and they need to learn significantly less about the language to get up & running with analysis. Two lines of code will get me data loaded and run a regression analysis & plot the results.

Especially consider that much of the audience for R come from proprietary and extremely expensive languages like SAS or SPSS Syntax, neither of which are significantly less difficult to work with but significantly more limited.

Something more intuitive would be nice, but I'm not aware of another option that has the depth of libraries for practical every type of data analysis that can also begin getting a researcher meaningful results in few lines of code than they have fingers on their hands. (Assuming there was no catastrophic accident resulting the loss of fingers.)

R is easy to understand if you use it as intended.

Having worked a bit with candy making and baking from home sized to restaurant sized to a regional factory, I'll say this analogy doesn't make sense.

Almost all the progression in that industry is relatively straight forward and would make sense to the lay person.

I sometimes quip that the difference between cooking and process engineering is that unlike the former, the latter actually gives a shit about the quality of outcome.

The issue isn't just specialized knowledge - knowing the principles underlying the process, knowing that there are principles - but also access to tooling. I'm sure plenty of lay cooks would appreciate appliances that let them be more consistent, even without knowing any related formal theory - but these are not available. As it is, an oven that's not shit is a major capital investment. It only makes sense to get one if you're more likely to call your work output a "formulated product" than "cookies".

However, software development is a peculiar occupation - one in which the best tools are free. It's like being able to buy a production line for less than a consumer-grade stove. Access to quality tools is not a limiting factor. Knowledge and awareness is.

Of course, non-programmers that code have more interesting things to do than to study software engineering. Which is why it's doubly important to make sure tools that are being popularized aren't shit. On the contrary, tooling is the perfect place to encode good practices and principles, so that even most lay (programming-wise) users succeed by default.

> Scientific programmers are solving problems first, not writing programs.

And they don't value writing programs. Or Software Engineers.

That makes productizing some research interesting. That also makes trying to get the same result as something published by your own lab a year ago an uphill battle: "it worked on John's old laptop, the huge Alienware. Never worked on any of our machine".

Reply on news.ycombinator.com