Bioinformatics Twitter is having...a moment. What began as one man's exasperated rant against poorly documented and distributed code has bloomed into a protracted debate about what constitutes "good" bioinformatics software and which kind(s) of interfaces developers should be expected to provide if they "really" want people to use their software. For those that have been around long enough, this dialogue has a familiar tenor. I don't remember ever seeing a big controversy specifically about GUIs versus CLIs, but the dynamics on either side of the debate seem to play out again and again. Barring significant structural changes, we should expect to repeat variations of this argument with each new academic generation.
Since before the term "bioinformatics" was in common use, developers of bioinformatics software have become accustomed to having their contributions trivialized ("they're just glorified techs; we at the bench are the real scientists") and their expertise exoticized ("they're geniuses, wizards, masters of the arcane; I could never learn that"). These attitudes are frankly insulting, both to bioinformaticians and to bench scientists.
It is true---to an extent, when requirements are well understood and clearly articulated---that implementing bioinformatics software can be primarily a technical exercise (although the tendency to use "technical" as the opposite of "intellectual" is also mildly insulting). But the same can be said of bench work: when protocols are well established and the study system well understood, lab work is "just technical." The important intellectual component of bench work comes in the design and interpretation of experiments. The parallel in bioinformatics is the development of models and the design of software components and notation to guide implementation and build intuition, and the structuring and formatting of outputs to facilitate interpretation. Of course, when studying any sufficiently interesting or novel question, software requirements will be poorly understood at the onset and elastic throughout development. Crafting accurate and stable software under such conditions requires considerable training, experience, agility, and creativity. Insinuating that if bioinformaticians really cared they would provide a "simple" GUI is a fallacy that perpetuates a dismissive attitude toward the work that goes into bioinformatics software engineering.
It's almost more uncomfortable when a biologist with a bench background introduces me to their friends as "a bioinformatician" with raised eyebrows and knowing glances, as if I'm an acolyte of some forbidden mystic art. Bench biologists routinely bring extensive domain expertise and technical competence to bear in the laboratory, interfacing with complex instrumentation and equipment to perform tasks of no small complexity. No bench scientist expects that they should be able to proficiently perform a sophisticated multi-stage lab procedure and interpret the outcome without a fair amount of time spent in reading, preparation, and trial & error. So it's a wonder that anyone regards bench scientists as incapable of using bioinformatics software for which menus, tabs, buttons, and drop-downs have not been provided. Nobody should pretend that this isn't condescending.
Both sides of the ongoing debate can probably agree on the sad state of bioinformatics software, too much of which is poorly documented, not very portable, difficult to install, and unreliable. The disagreement lies, at least partially, in the role that GUIs can or should play in addressing this issue, and how the attitudes described above are reflected, implicitly and unwittingly, in the debate. With all that as context, I want to respond to a handful of common myths and fallacies about bioinformatics software, GUIs, CLIs, and related topics that have featured in the ongoing debate. (And just in case any reader is unfamiliar, a GUI is a graphical user interface, and a CLI is a purely textual command line interface.)