In the previous post, I lamented the lack of a standard library in Fortran and briefly reviewed the contents of the standard libraries for both C and Python. While these languages serve different roles than Fortran, they are popular and mature and I felt they were worth investigating for inspiration. This post covers two topics: first, I present a brief summary of how a hypothetical Fortran Standard Library could be created and adopted (the “Big Picture“), and second I look at the standard libraries of Julia, R, and Ada.
The Big Picture approach I am taking is to:
- describe the problem (lack of a standard library),
- show how other languages address it,
- set high level policies and goals,
- define & implement an achievable initial library,
- have people use it and provide feedback, and,
- iterate over 4 through 6 until the library is stable, adjusting the policies and goals in 3 to ensure the library is implementable, stable, usable, and meets with community approval.
Following this model, we can define high-level capabilities we want in a standard Fortran library and then get into the details of what functions are necessary. In software engineering terms, that means setting requirements and creating design and functional specifications.
Developer Community Model
I believe a community-driven approach will produce working developer-friendly code relatively quickly. It’s easier and more effective to take risks and rapidly evolve code in public and later standardize on a (hopefully mature) working reference implementation. This is not a criticism of going through a standards body; I just don’t have any visibility into (say) WG5’s process or goals and I feel a better use of my time is to build a working community, consensus, and code and let standardization happen in due course.
Looking back the process model, 3 and 4 are fairly tricky since they involve building consensus among developers with different goals and opinions. It’s clear we need a fair and efficient process for evaluating changes and making decisions. With one or two developers, this isn’t usually a problem but to grow beyond that you need to find a way to break ties and make decisions that keeps everyone happy, or at least equally dissatisfied. Process is a burden but it’s necessary to reduce friction and preserve working relationships.
Unfortunately we’ve seen a number of communities where thought leaders don’t behave as professionals or treat others with dignity and respect. People disagree, not every decision needs a vote, not every opinion is a worthwhile one, but at the end of the day, there is zero evidence that insults, abuse, and worse lead to better code. But even if there was, abuse is wrong, full stop, end of discussion.
Aside: I hate writing that. I think the requirement to treat others with dignity and respect should be self-evident. However, the amount of special pleading I hear from a certain devolved segment of developers makes explicitly stating it necessary. We need to do better as a community and as a profession.
What’s needed is a clear, consistent, and fair approach to evaluating ideas and a community that its members trust to do good work and make volunteering worthwhile and satisfying. To that end, I’ll look into how other language communities make their decisions and manage their volunteer development. Here are a few examples:
- Contributing to Rust and Rust RFCs
- The Python Developer’s Guide and Python Enhancement Proposals (the PEP process)
- Notes for Julia Contributors
- The Go Programming Language Contribution Guide
I’ll come back to this topic later when it becomes more relevant.
Release and Distribution Model
Let me be a little heretical and suggest that public access to the library follow a release candidate/minor point version model rather than the forever-wet-paint git clone model of public distribution. I am deeply uncomfortable telling end users to use a random interim development build pulled straight from version control rather than an well-defined release candidate. First, as an end user it’s bad practice to rely on unversioned software releases because it plays havoc with reproducibility and configuration management. I have a background in nuclear safety and writing code to the ASME NQA-1 standard for safety-related quality assurance where strict configuration management is the norm. Having worked in both fast-paced startups and in the glacially-paced nuclear industry, I have to say I prefer the more thoughtful release model. I feel it’s a better fit for Fortran culture and it offers a more consistent, predictable, and reliable experience for end users.
Again, I have no fundamental problem with end users having access to interim builds; I just don’t want the working repository to be the sole or primary means of distributing the code. Developers should release with intent and make configuration management easier for end users who need it.
Summary
I may be getting ahead of myself focusing on how changes are accepted, codes of conduct, distribution and release, etc. for a (still mostly) hypothetical software project, but I think these issues need to be acknowledged sooner than later. They are important aspects of the software development process whether open source or proprietary, free or commercial. A lot of this comes down to providing trust. Volunteers need to trust there is a fair process for evaluating contributions and that they are working with people who will treat them like professionals – this is key to volunteer satisfaction and building a strong and effective community. End users need to trust that the software they rely on is reasonably stable and that the project’s release method supports their needs for configuration management and reproducibility.
In future installments, I want to explore more standard libraries (Julia, R, and Ada) and talk about some of my needs when revitalizing legacy Fortran or building new Fortran applications.