I'm a command line chauvinist and I'm not ever going to apologize for it. > [Incidental complexity] arises simply because modern research software development

I'm a command line chauvinist and I'm not ever going to apologize for it. > [Incidental complexity] arises simply because modern research software development is a messy jumble of open-source tools tied together by the duct tape of command-line scripts. That's ironic, I think the output of modern CS research is this way because students don't learn this "bullshittery". Good luck getting your interesting research to compile elsewhere with that makefile that you copied off of stackoverflow and edited with hardcoded values until it built. This past summer I worked for about a week and a half with a local startup trying to exist in fitness-watch IoT. They wanted to flash the boards with some proprietary tool provided in the board devkit. I wanted to flash the board using flashrom. They were content using a cloud compiler that had a costly license and hooked in the bootloader magically using a closed source library. I wanted to get us using arm-none-eabi- and a proper build system. They wanted to press a green button in their IDE. They wanted their familiar starting point of int main(int argc, char* argv[]) { } And that's the real hidden tax of not learning this "bullshittery"-- a lack of an ability or urge to learn or do more. Oh, we need to do OTA flashing? Well we don't understand the bootloader. Or the flashing process. Good. luck. with. that. And I guess that's fine if your goal is just to make theoretical software for a paper. But if you're trying to make code that isn't meant to be disposed of, you need to know what's going on underneath-- you need to be able to explore things from first principles.