Helping my students overcome command-line bullshittery (2014)

I took something slightly different. My reading is that many people refuse to accept that there are obvious deficiencies in the dominant paradigm, and instead they cling to it religiously as if it were a be-all-end-all rather than a local maximum embedded with strong network effects.

I recall my high school computer science courses. They consisted of us writing stuff in DrJava, using a framework our teacher made to abstract some Java-specific things away. We ran the programs we made within it, without going into the command line. It was quite a simple IDE, but it allowed us to get things done without using a command line.

I actually disagree with this. I came to computing from the reverse direction (I did theoretical math in grad school and then steadily needed to become better at programming as I needed it in industrial jobs). At first I thought a lot of stuff classified as 'bullshittery' and that with convenience tools like MATLAB, most of it was obsolete and taking time away from focusing on the supposedly more fundamental "real work" of some domain science.

But as I have gone down rabbit holes with Haskell, C, LLVM, and some other tools, I have discovered that seeing those 400 different implementations of basic data structures has been extremely helpful. Reading and re-reading decades-old tutorials on finer points of gdb and memory layout and books on what NUMA-aware memory architectures are like has been extremely educational and important. I would now regard MATLAB, and even the idea of wanting a prototyping platform like MATLAB, as bullshittery.

I used to think that progress, so to speak, in computing was supposed to mean less and less need to be proficient with low-level tools, and a constant push to abstract away the low level and use languages or tools that offer the same things in a high level, black box manner.

But I totally don't think this any more. Now I want to be a power user of all the low level things and I wish that the surface area of tech and science wasn't growing so fast that it forces me to be a wimpy abstraction user in a lot of domains that I don't have time for.

Anyway, I'm just adding my perspective that the attitude that seemingly cumbersome low-level stuff that was formerly instructional but now abstracted is a nuisance is wrong. The world overall doesn't have nearly enough competent technicians and engineers who really know (intuition in the fingertips) that low level stuff, and we're allowing the superficial pleasantries of limiting abstractions to raise up generations of programmers who not only don't know this stuff at all, but also aren't even curious about how it works. They can do jobs when the black box abstractions are working, but as soon as something breaks, they don't know how to fix it.

Maybe one way to say it is that we're breeding programmers who have shifted their curiosity away from how fundamental atomic parts aggregate to make functioning tools and towards how to permute a series of ready-made black box abstractions for some social-level end goal (e.g. how do I permute Heroku and Postgres and Spark ML to make a recommender system) -- but it's not actually clear to me that it's better in a utilitarian sense that we're supposedly "freed" from our low level chains to think about these one-level-up problems.

At least standard UNIX commandline bullshittery doesn't change much. What drives me nuts is new build system command line bullshittery. There are lots of build systems, all different. Go and Rust both have their own build systems and their own directory layouts.

A few months back, the Mozilla Foundation insisted that add-on developers switch from their old build system (useful for nothing else) to their new, roughly equivalent build system. The new system by default generates the new package in the same directory in which the package files live, then, on the next build, including a zipped copy of the old package inside the new package. (The documentation says it won't do that. It lies.)

This week, I'm using ROS, the Robot Operating System, which is a large collection of robotics packages hammered into working together using a clunky interprocess communication system. It has its very own set of file system commands ("rosls", "roscd", etc.) which work on its own interpretation of the file system, depending on various environment variables. It has its very own build system, Catkin, with its own command line bullshit ("catkin_make", etc.) and lots of configuration files, some of which are in XML, some of which are in YAML, and some of which are in their own special format. Many configuration files contain pathnames, and there are function calls which can be embedded in some strings to call functions which use environment variables to search for things.

ROS2 is coming, with a shiny new build system. I can hardly wait.

Nowadays I'd say "just use IDLE".

P.S.: Granted, it's not always going to be the best tool as a project grows, but it drastically lowers the barrier to one-off experiments and lessons.