![]() After a few projects, the person who wrote that first prototype already left the department, but there are people who depend on it to get results. But the next project is building a new prototype, not improving the previous one. In my experience, what happens is that some prototype works quite well and gets used in the next project. There are a few remarkable counterexamples, but most research software does not usually finish taking the form a product. But things like tests, API documentation, dependency management only apply to steps 2 and/or 3. Most tutorial about "good coding practices" do not make distinctions between these three stages.įor Python, there are practices that work at any level: auto-formatting code and sorting imports, gradual typing. Product: code, often open source, that is shared with the community. ![]() Prototype: code that serves as a foundation to the above, or is reused frequently, but is otherwise not shared outside a research group. Internal use by a single researcher usually. Playground: throw-away scripts for data analysis, fast moving code where any rigidity slows the process. I was thinking of dividing academic code in 3 "Ps": Do you have resources in mind on that topic? You raise an excellent point, the software development life cycle is quite different in academia. I'm currently teaching modern scientific Python programming, if that's a thing. > The culture and dynamics around scientific and academic programming is different from both FOSS and commercial software. The culture and dynamics around scientific and academic programming is different from both FOSS and commercial software. It's the same thing with long living FORTRAN code. If I want to modernize with C++14 or add new parts with C++14, these parts will probably look so different that it'll look like two different languages glued together with black magic. ![]() My research was coded with C++11 in the beginning. The code pushed down solidifies, knowledge fades, and documentation get lost unless it's bundled with the code repository.Īs a result, legacy code becomes something of a monster, where developers don't want to see, touch, or work with. Inevitable shims get coded (sometimes implicitly), and thing get complicated, even with best documented designs and developers with well intentions. So you're bolting modern designs over "vintage" designs. Hardware change, capabilities change, requirements change, designs and languages change. Moreover, technology changes with every generation. Support for required patterns and new technology is added to languages, and designs are made in confines of language capabilities. First of all, programming languages and software design has a symbiotic relationship. Inertia is not a bad thing, but a long living code evolves in strange ways, because of us, humans. HPC administrator, researcher and scientific software developer here.
0 Comments
Leave a Reply. |