1. 26

  2. 14

    A response (not mine)

    1. 9

      A rebuttal by Eytan Adar at the end of the article is also worth a read - sums up the faults with this article.

    2. 12

      Criticism is cheap without a positive counterproposal. The author complains “nowhere did I suggest that we rely only on GUI-based tools” - but when you characterise the problem as “command-line” and offer no further clarification, what on earth do you expect your readers to think?

      1. 11

        Don’t most large research centers have staff to handle some of this? Maybe some don’t, but they should.

        It’s been about 200 years since astronomers needed to polish their own mirrors (or force their sister to do so). Maybe inventing red-blue-green-black trees shouldn’t mean having to write their own Makefile, but instead somebody does that for them. This doesn’t mean the command line is bullshit and should be abandoned, anymore than polished mirrors are bullshit.

        1. 13

          The trend is more in the other direction unfortunately. CS departments used to provide research clusters with proper sysadmin support, installed software (site-licensed or free), guides to use the clusters and the supported software, etc., but nowadays it’s more of a DIY free-for-all.

          At least three of the things conspiring to make that happen are:

          1. Some people have impatience for that model, and want root on their own machine so they can install/configure everything as they want. So they opt out of using the departmental setup, and/or lobby for a more flexible “department provides only VM instances” type thing.

          2. It’s more practical to opt out than it used to be, since even if you had to pay out of pocket, you can rent a VPS for affordable prices, or even install stuff on your OSX machine, or in a Virtualbox instance, or whatever.

          3. University budgets are being squeezed, especially at public universities, and so they’re offloading as much “non-essential” stuff as they can. If people don’t even seem that committed to using a departmental cluster in the first place, why pay for either the cluster or the sysadmins? If some profs really do want a cluster and/or a sysadmin for a big research project, they’re advised that they can pay for it themselves out of grant money. Really big projects do have that kind of infrastructure, but you need to be getting DARPA-level grants to pay support-staff salaries. Most areas of CS get grants in the $100k/yr range, which is just about enough to pay a few PhD students, buy them laptops, and wish them luck with StackOverflow.

          As a result I think the amount of “bullshittery” has gotten considerably higher, compared even to the early 2000s. As an undergrad ~10-15 yrs ago, all I had to learn was how to log in to the servers and run the software, which someone else maintained. And there was a nice guide provided by the CS department on what software they had installed, what it did, and how to run it. There was even an officially supported gcc version. If you needed software not already installed and it was plausibly research-related, you could file a request and they’d install & support it. Now, you’re more or less on your own, and I see new students spending a lot of time and frustration just trying to get things installed and working on their laptop.

          1. 1

            I can’t speak to the general case, but at my alma mater (Univ. of KY) the supercomputer had proper sysadmins, installed software, guides, etc.

            The individual systems were free-for-all, though.

        2. 14

          I want to work with the best students I can find, so it’s profoundly stupid to disproportionately filter out entire demographics based on bogus criteria such as prior familiarity with incantations like “nohup tar -jxvf giant.tar.bz2 2> cmd.errs &”


          If they (and the author) only view that as an incantation.They are lost.

          It they view it as a sentence in a powerful language with a large vocabulary, which they can break down and understand each part and as a whole… they are on their way.

          Calling it “bullshittery” is to miss the point.

          Packed with legacy, yes.

          Could we afford to dump some of that legacy? Yup.

          Would a rant explaining the legacy and suggesting improvements be much more useful? Yup.

          For example “nohup”. Ye Olde modems sent a SIGHUP “Hang UP” signal when you, duh, hung the phone up on the hook switch.

          That same signal is sent when you log out of an ssh session to a server. “nohup” blocks that signal so it doesn’t kill the long running command you are running in the background (the “&” instruction)

          Now I haven’t hung a phone on any hook switch whilst any of his students have been alive…. but the English language still has “hung up” as the phrase meaning “ended the voice data session” in common usage.

          Should we rename “nohup” to something less mystic? Probably not.

          Should we rename “tape ar” (tar) to something less obscure? Probably yes.

          Now let’s take a large step away from our screens and reconsider program invocation.

          Invoking the file names of executable programs, resulting in them loaded, dynamically linked, executing them with an array of strings, which by convention may have ‘-’ prefixes to indicate named optional arguments, but apart from that is Stringly typed.

          Bit weird if you think about it.

          Would you really really, even on a Bad Day, design an IDL (Interface Definition Language) that way?

          Yet here are, with the largest user base combined with worst defined IDL on the planet.

          There has been many attempts at redefining “sh”.

          They are all sort of hung up at this uncomfortable intersection of stringly typed IPC (Inter Process Communication) to sub programs, and the need to minimize keystrokes for someone at the command line, with being a vaguely decent language when you gather commands into a file as a script.

          Although the systemd debate has generated much heat and steam….

          …one bit of light is it does (in combination with dbus and kdbus) define a vastly advanced (compared to stringly typed) and pragmatic IDL (compared to CORBA).

          I think there is room for yet another shell, (or extension to an existing one).

          One that uses reflection within dbus to provide “typing” assist.

          Bash command line completion and TheFuck go someway along this path (of providing typing assist), partly by the authors reading the man page, or (as in the case of TheFuck) assuming existence of –help, inspecting it and assume certain conventions.

          1. 6

            Oh and while we’re on it…

            Peter Miller’s libexplain is bloody marvellous.

            Now that thing decreases bullshittery wondrously.

            I grew up using strace… so I tend to reach for strace rather than explain as it is more powerful.

            But for anyone just learning… libexplain should be mandatory.

          2. 4

            this is why i like having an IDE when i’m learning a new language. code completion, tooltips etc. are optional, but being able to just type in some code and click a button to build it is invaluable.

            1. 5

              I think a lot of the commenters here so far are mistaking the intent of the article. It is not so much a complaint about “command-line bullshittery” (although it has some aspects of that) as it is about the value of helping students work through it without becoming completely bewildered and demoralized.

              In other words, he’s saying that one of the most effective uses of his time as a research advisor is to take the time to tutor students in how to deal effectively with the command line! And a part of that is not belittling those that have not been steeped in it previous to their school experience, and assuring them that while it’s complex and powerful stuff, it’s not what their research is about and they shouldn’t feel like they’re inadequate because they don’t know it yet.

              So this is not about how terrible command line stuff is, it’s about how it’s complex and it’s really valuable to take the time to teach people about it and how to deal with its complexity without making them feel bad that they didn’t know it already. They’ll no doubt end up picking it up, but they’ll do so faster and they’ll be doing productive research faster if you do some work to remove stumbling blocks up front. And doing that work is the “solution” that’s being advocated!

              1. 2

                I agree with the author that there’s a lot of incidental complexity in software, and it takes time to learn. I guess I’m confused as to what the author wants. Computers != CS. If he wants to do some theoretical research using nothing but his brain and some dead trees, no incidental complexity is required. If he finds that unix clusters are a necessary tool for his students to do their work, then I guess a little incidental complexity is required. Not every piece of experimental equipment can be a spherical duck in a vacuum.


                The middle ground is to say that he can envision a set of tools that would allow him and his students to do their job without exposing them to several crusty decades old interfaces. Sounds awesome. I look forward to seeing the lobste.rs post when he launches that project.