bioawk VS tiny_python_projects

Data wrangling is actually what awk excels at, and it's generally much more concise than R for that sort of thing. I'm aware that a lot of awk one liners look like gibberish to the uninitiated, but it actually makes a lot of sense when you understand the pattern-action structure of awk programs. It is also installed on any *nix system, there's no need to worry about installing dependencies or setting up virtual environments. And it's several times faster than R. Also Bioawk is glorious.

A few months ago, I learned about this utility known as bioawk, written by Heng Li of samtools fame. Apparently, it is essentially a tweaked version of awk, with some extra goodies added for parsing and processing of bioinformatics file formats. While the functionality seems cool, I was wondering whether it is worth installing on my server, and incorporating into our workflows, because it seems so niche. I have not seen many references to it. Or is it better if we stick to Python scripts for this sort of work? Are there any computational speed advantages, etc. that bioawk offers over regular Python scripts for processing of, let's say, BED files or VCF files?

Beside that their core lectures to non-computer scientists are public (survey), workshops by software carpentry move around the globe. Maybe your intent to seed hands-on knowledge is in similar tune before heading for biopython, bioperl, bioawk. It doesn't hurt to tap into resources initially written for non-labrats either, e.g. about regular expressions by programming historian.

On the other hand, some of the techniques to set the ground for data analysis are equally valuable in other situations. The two installments about regular expressions on programming historian Understanding Regular Expressions and Cleaning OCR’d text with Regular Expressions, for example. They have no relevance to handling chemicals in the lab, yet since then, I find myself working with data files more efficiently, than earlier because of grep, an utility in Linux to crawl across data files. Or AWK, actually picking up theses "regexes", which I find generally useful since Benjamin Porter's "Hack the planet's text" (presentation video, and exercise video) with its link back to chem/bio e.g., to bioawk (btw, there equally is biopython, too).

Well, what language do you want to learn? What is your background so far? Assuming it is more on the side of biology, software carpentry's Python may eventually lead to biopython? Though there equally is a chance for AWK (Hack the planet's text! and bioawk...

There's even a version of awk specifically designed for bioinformatics that natively knows how to handle fasta, fastq, and bam files, among other formats.

https://github.com/lh3/bioawk

My book, Mastering Python for Bioinformatics (O'Reilly, 2021), uses many biofx challenges from the Rosalind.info site, but it's not necessarily a beginner book. The most important thing I teach is the use of tests to verify that a program/function is correct (or at least behaves predictably). You can see https://github.com/kyclark/biofx_python for all the code/tests. To learn more about Python and testing, I would recommend you start with other books such at my Tiny Python Projects (Manning, 2020). Code and tests are at https://github.com/kyclark/tiny_python_projects. I recorded videos showing how to write and test all those programs at tinypythonprojects.com. Best of luck!

From Clark's Tiny Python Projects (the corresponding code shared on GitHub) I learned the concept of test driven development (specific to Python, the book elected pytest for quality control) which equally can be applied for other programming languages. For me, continuous integration tests (some projects on GitHub use), or unit tests tap into this field.

What the 101 beginner courses sometimes/often skip (because there isn't enough time, attendees become tired, etc) is the next level, automated testing. As an example, pytest for Python allows you to set up "a test bank" to monitor if the output of your program's result are reasonable. This then is test driven development (e.g., Clark's Tiny Python Projects).

Only as recommendation: If the lines of the source code (here: you C code you aim to document) are kept short, in manageable bytes (similar to entries parser.add_argument in Clark's "Tiny Python Projects", example seldomly pass beyond the frequently recommended threshold of 80 characters/line), reporting with listings becomes easier (equally, the reading of the difference logs/views by git and vimdiff), than with lines of say 120 characters per line. Though we no longer are constrained to 80 characters per line by terminals/screens and punch cards (when Fortran still was FORTRAN), this is a reason e.g., yapf for Python allows you to choose between 4 spaces/indentation (PEP8 style), or 2 spaces/indentation (Google style).