301–310 of 333 posts
Earlier quoted context omitted.
Depends. If gaming is what you do, the better the performance, the bigger the market. As then more people can play your game.
HN is funny. I've been told on a previous discussion that AAA publishers don't optimize for potatos. Now you tell me it's a business requirement.
Earlier quoted context omitted.
The programmer's naming approach has the virtue of being self-explanatory, and thus more maintainable. Scientists don't care about maintainability. Their bar is reproducibility, and even for that they don't expect it to be as painless as an automated test.
even the variable names used by programmers are abbreviations for a longer description. longer than one letter, but still shorter than a sentence
Earlier quoted context omitted.
There's a happy middle path here I think. Long functions are hard to grok. Spreading the logic across 20 files also increases cognitive load. There's a balance to strike.
Long functions are not hard to grok, if they have a logical flow and stay reasonably close to a common level of abstraction (which can be high or low, doesn't matter). You just read top to bottom and follow the story. 20 files with 20 functions each does not cause high cognitive load, if the scope of each file and each function makes sense. You easily find the file+function you need, whenever you need to look somethi…
Earlier quoted context omitted.
Maybe it boils down to how well you are able to navigate a code base. With a full-featured language specific IDE, it is very easy to navigate through even complicated spaghetti. It makes debugging call traces simple, with a GUI. However, many other file viewers and editors make this much more complicated, and it can be frustrating to follow code that is making heavy use of modularization. If you are grepping your way…
>> With a full-featured language specific IDE, it is very easy to navigate through even complicated spaghetti. If you need a fancy IDE to navigate around code in order to understand it, that might be crappy or poorly organized code. Not a dig at nice IDEs, just code that requires one to navigate and understand.
> Not a dig at nice IDEs, just code that requires one to navigate and understand
A nice IDE helps you reason about code, no matter what the underlying architecture is. That is why there is a market for them.
This is partly because, in my opinion, some "best practices" are superstitions. Some practice was best because of some issue with 80s era computing, but is now completely obsolete; problem has been solved in better ways or has completely disappeared thanks e.g. to better tooling or better, well, practices. e.g. Hungarian notation. Yet it is still passed down as a best practice and followed blindly because that's what…
Such as what? I don't really know of any such superstitions that are based on nothing. I see a lot of opinion/taste presented as something more, but I really can't think of superstitions.
Earlier quoted context omitted.
I'm a software engineer working with scientist-turned-programmers, and what I've experienced is also exactly the opposite of the author. The code written by the physicists, geoscientists and data scientists I work with often suffers from the following issues: * "Big ball of mud" design [0]: No thought given to how the software should be architected or what the entities that comprise the design space of the problem ar…
> The mindset … might be fine in a research setting A vast amount of software is written for research papers that would be useful to people other than the paper’s authors. A lot of software that is in common use by commercial teams started off in academia. One of the major issues I see is the lack of maintenance of this software, especially given all the problems written in your post and the one above. If the softwar…
Two more to the scientists' tab: 1. No tests of any kind. "I know what the output should look like." Over time people who know what it should look like leave, and then it's untouchable. 2. No regard to the physical limits of hardware. "We can always get more RAM on everyone's laptops, right?". (You wouldn't need to if you just processed the JSONs one at a time, instead of first loading all of them to the memory and t…
Agree with those two problems on the scientist side. I would also add that they often don't use version control. I think a single semester of learning the basics of software development best practices would save a lot of time and effort in the long term if it was included in physics/maths university courses.
Working for corporate R&D, I once received a repo on a flash drive. The team would merge changes manually by copy-pasting.
I should've just turned around and left.
Earlier quoted context omitted.
> It's the scientist's job to solve a specific problem at a specific time. Who cares if the metaphorical wood rots next winter, the paper's been published. Sounds a little like cargo-culting than proper reproducible research. But this is a pest in academia definitely. Many papers do not provide all required data, all required model parameters etc. to get to the exact same result. Admittedly, they might nowadays need…
Cargo-culting is about focusing on the process without fully understanding its purpose. Such as bureaucratic requirements for providing all data, software, parameters etc so that someone can reproduce exactly the same numbers with minimal effort. Proper reproducible research is not like that. It's about providing sufficient details that other people in the field can extrapolate the rest. That they can use similar met…
Earlier quoted context omitted.
The point is, it's not prioritized since it's not rewarded. Grad students are incentivized to get their publications in and move on, not generate long-term stable engineering platforms for future generations.
An experimental research system does not have to be a complete practical system, it can focus on a few things to prove a point, support a scientific claim.
Anyone who spends lots of time trying to make research-relevant code projects with solid architecture / a well designed API / tests / good documentation / etc. is doing it as a labor of love, with the extra work as volunteer effort. Very occasionally a particularly enlightened research group will devote grant money to directly funding this kind of work, but unfortunately academia by and large hasn't found a well organized way to support these (extremely valuable) contributions, and lots of these projects languish, or are never started, due to lack of support.