This is like an alternative form of "Yak Shaving." :)
Instead of going super far down a path, following each step along the way, and somehow ending up with a yak in your hands, you're immediately asked to find a yak and you rightfully ask, "what does this have to do with yaks?"
Yes, the command-line is powerful, but it is definitely a huge hurdle for most as they're really just trying to do something else. Well stated PG.
This is exactly the problem we're trying to solve with http://bowery.io. There's so much amazing OSS that's hard to set up, making it hard to focus on the actual development/coding/research you want to do.
Similar with https://cloud.sagemath.com, except in the domain of computational mathematics. People like you and I deal with a lot of the BS, so it's already setup for other people.
I feel like any field of research has a base set of knowledge and skill sets required to do high level research. One could say that biology research is filled with "Microscope Bullshittery" or Paleontology is filled with "Fossil Digging Bullshittery".
A base skill of doing computer science research is programming.
Can you program without computer science? Absolutely. Can you Computer Science without programming? I would say no. Being able to look at and understand how to use a language or library is just something required to get to the last tier of computers science knowledge. I think every researcher would love to get rid of their bullshittery, and often they have lab technicians or interns do it for them but in the end they all had to pay their dues and have to know it in order to mentor and help those below them.
The author specifically calls out that he's not talking about programming, per se. He's talking about the skill set of wrestling useful free software packages to one's own aims:
So perhaps what is more important to a researcher than programming ability is adeptness at dealing with command-line bullshittery, since that enables one to become 10x or even 100x more productive than peers by finding, installing, configuring, customizing, and remixing the appropriate pieces of free software.
I'm torn about this article. Clearly this researcher, in his role as mentor, has identified a skill gap that's hindering his students. And it's perhaps even a problem that the software community can ease the pain of. But many of the things he lists in passing get down to fundamental tools of software work: version control, package management, data manipulation, etc. Yes, the usage of these things on the command line tends to be "arcane", but that's because each is encoding its own problem domain. And if you're going to be working in software in any non-ivory-tower capacity, you'd better know this stuff.
I've dealt with this kind of problem numerous times before in various contexts with workflow tooling. I.e. a single (usually) command-line tool that neatly encapsulates the most common development use cases to reduce learning curves, cycle time, and errors. These can be phenomenally successful if done well, but if the context doesn't define a workflow (e.g. student A vs. student B's research ideas) then there's no easy way to encapsulate the user's problems.
> Clearly this researcher, in his role as mentor, has identified a skill gap that's hindering his students.
This is a well known pre-course prep step, part of a bigger to do list for all teachers to make sure the tools you suggest to the students are bundled to be setup in an easy way for your target audience.
I don't think he's talking about courses here. He's talking about his role as an advisor, not lecturer.
This issue comes up all the time with young researchers (i.e. graduate students). There are a huge number of free and open source packages that can help them implement and test their ideas, but actually getting them to work together can be an exercise in yak shaving.
That being said, having facility with command line tools is a valuable skill for any researcher.
Paraphrasing some actual experiences I've had: I want to install GNU Guile 2 on my Mac laptop so that I can write a prototype of an AI program. To install Guile 2 I need to install some prerequisite library. The prerequisite library won't build with the version of GCC I have installed. The easiest way to upgrade GCC is to get the newest version of Apple Xcode tools. The newest version of Xcode tools requires the latest version of OS X. But I also run Avid Pro Tools for music production on this computer, and the latest version of OS X is not clearly compatible with my version of Avid Pro Tools. So I'd need to pay $300 to upgrade Pro Tools so I can upgrade OS X so I can upgrade Xcode so I can upgrade GCC so I can build a library so I can install Guile 2.
In this case, I'd suggest using a VM driven by Vagrant, unless you really need to be running native under OS X. That provides an isolated and repeatable environment, but at the cost of learning whole other domains of experience. My suggestion also hugely reinforces Dr. Guo's point: we've perhaps solved a problem by adding piles of additional tooling layers: (vagrant CLI, Vagrantfile interface, VM domain knowledge, setting up a Linux host (even as a toy environment), setting up a Linux host as a build environment, etc.) Heck, if we're doing it right it'd be nice to use a provisioning tool to automate the VM and build environment setup. All of this stuff is awesomely powerful, but front-loading a student project with it is nuts unless there's a domain expert who's building this tooling for them and coaching the students through it. Again, that's not the sort of thing that's likely to happen for per-student research projects.
I think the biggest issue is that beyond the setup phase of development, these tools don't get used by the new researchers the author works with. If I'm developing a new program, having to run ten programs I've never seen before just to get started can be frustrating if I won't be actively using as them I work.
Programmers should learn the tools to stay efficient. Version Control, build tools, etc. are priceless. But if you force feed too much at once, nothing will stick. Couple that with what for some may be their first time on the command line, and you have a recipe for bullshittery.
I'm having a hard time understanding other commenter's grief that explaining git to someone who's never typed "ls" before is anything less than bullshit to slog through. These things are best learned one or two at a time.
"Throughout this entire ordeal where I'm uttering ridiculous epithets like 'git pipe fork pipe stdout pipe stderr apt-get revert rollback pipe pipe grep pipe to less make install redirect rm rm ls ls -l ls tar -zxvf rm rm rm ssh mv ssh curl wget pip,'"
In other words, "ridiculous epithets" seems to be equivalent to telling the machine to do something. Have you got a way to get git to control your source without actually invoking git?
Workflow tooling can indeed be incredibly useful, but the context isn't the only requirement for success. If something underpinning that tooling changes or breaks, someone is going to have to understand what happened.
The people who regard that understanding as "ridiculous" are the worst people to work with and to my mind are the primary reasons that this "profession" gets little respect.
> Have you got a way to get git to control your source without actually invoking git?
No, but git does involve ridiculous epithets. No quotes, because I'm dead serious. As an interface, Git command line is laughable, and doesn't deserve a passing grade. Yes, it's the only one we've got. Yes, many interfaces are even worse. Still, that's no excuse. We can do better. Hopefully someone will: http://tonsky.me/blog/reinventing-git-interface/
---
Let's take a simpler example:
$ tar -xzf foo.tar.gz
So, you have to learn the name "tar". The option "-x" for extract, the option "z" for gzip, and the option "-f" for file (by the way, the "f" must come last, or it won't work). What the fuck is this retarded interface?
First, why do I have to tell tar to extract the thing, since it's obviously a compressed archive? Why do I have to tell tar that it's in gzip format? It can decompress it, surely it can check the compression format? And why, why, WHY do I have to tell it I'm processing a file? It KNOWS it's a freaking file!!!
Surely there must be an alternative, like… like…
$ decompress foo.tar.gz
I personally don't know of such alternative, and don't use them, because I was retarded enough to learn the basic 'tar' incantations by heart. Now that I know them, I can't summon the courage to use a decent interface instead.
But you see my point. Even for a simple tool such as tar, the common use case involves a cryptic incantation that shouldn't be needed in the first place. I'm sure many other UNIX tools are like that, I just didn't think about critiquing their interfaces thoroughly. Yet.
The core principles of the command line are very good. The level of relatively easy automation it provide is nothing short of amazing. This technology for the 70's is arguably more capable than most graphical interfaces in current use. But it does have its fair share of incidental complexity and useless quirks. We can do better. Let's not forget that.
You don't specify -f to tell it you're processing a file, you specify -f to tell it that the next argument is the filename. And it doesn't have to come last.
tar -z -f foo.tar.gz -x
That's a perfectly valid tar command. Also, obviously you have to tell it that you're extracting the file. How else would it know that you don't want to create an archive?
You're the second commenter who believed I didn't know this stuff.
I know that, and more. But go and explain each and every flag to a student that just want to extract the first lesson of his first UNIX course. At this point, this is all magic and arbitrary.
Lets take your tar example. The -z and -x options are flags, they specify binary on/off options. You can specify all the flags separately on the command invocation like so:
$ tar -x -z -f foo.tar.gz
However typing -flag -flag2 -flag3 is too many keystrokes so an a convenience you can combine all the flags in one call -xzf. The -f isn't a flag though it takes an argument which in this case is the filename foo.tar.gz. The argument is required and comes directly after the flag. Which is why the f has to come last because that argument has to come right after. Order doesn't matter for the x and z because they don't take arguments they are just flags. It makes sense if you add in another flag like -C which also takes an option you would end up with:
$ tar -xzfC foo.tar.gz directory_to_change_to
Which argument goes to which flag? Maybe the first flag gets the first argument? Then your argument order changes if you type in the flags backwards.
I don't know about your z flag, GNU tar doesn't need it. The x flag is needed because tar can do things other than extract like list the contents of the archive with the -t flag, or create a new archive with -c.
Finally why is the f command required? My first assumption was that maybe because you need to specify the output file when you are creating an archive. I took a look in the manpage and the reason is a lot more interesting.
Use archive file or device ARCHIVE. If this option is not given, tar will
first examine the environment variable `TAPE'. If it is set, its value will
be used as the archive name. Otherwise, tar will assume the compiled-in
default.
I knew that tar's name comes from the phrase tape archive but I hadn't put two and two together. Of course you need to specify if you are writing the archive to a file because tar was created to back up data to tape! If you think about it tar is actually doing the "right thing". Considering why it was written tar has a sane default, write the data to the tape drive.
Maybe you already understand all this and I'm reading too much into your simple example. It feels to me though that when people have issues with something like the unix command line its because they just wanted to get something done and memorized an incantation to do it. There isn't anything wrong with that of course but a tool like tar is SO much more powerful than just decompressing files. Once you start to dig into it though there is an internal consistency and logic to it though.
Yes I do. Every single item. I just feel for the hapless student that is required to send a compressed archive of his work to the teacher, and is using tar for the first time.
There's only one little exception: I didn't know GNU tar doesn't require the '-z' flag (which by the way means 'this is a gzip archive') when extracting tar.gz archive. Anyway, I bet my hat that the '-z' is required if you compress something and output the result to the standard output: there will be no '.gz' hint to help the tool magically understand you want it compressed. If you omit it, tar will likely not compress anything.
The '-f' option is the most aggravating. Nobody uses tapes any more. Tar was doing the right thing, but no longer. -f should be dropped, or rendered optional, or replaced by '-o' for consistency with compilers… As it is, it's just ugly.
> It feels to me though that when people have issues with something like the unix command line its because they just wanted to get something done and memorized an incantation to do it. There isn't anything wrong with that of course […]
Actually there is. The users want to do something (usually a very common case such as compressing or decompressing an archive), then they have to memorise an arcane incantation. Yes, tar can do much more. Yes, the command line is powerful and flexible and more. This is Good. (Seriously, I miss my command line whenever I have to touch Windows.) On the other hand, some common cases are just not well handled, and it is full of idiosyncrasies that have nothing to do with the aforementioned benefits.
When the user wants to decompress files, it should not be more complicated than 'decompress archive.tar.gz'. Though thanks to an uncle comment, I now know of the 'unp' tool, which works just like that: 'unp archive.tar.gz', and you're done. (And the man page is refreshingly short.)
> Yes, the usage of these things on the command line tends to be "arcane", but that's because each is encoding its own problem domain.
Not necessarily. I came to believe lately that Git for instance, has beautiful, simple, and powerful core principles… and an unacceptably crappy user interface. A hashed DAG of commits with a few pointers to navigate it, that's great. But the magic incantation that you're required to type on the command line are too complex, unintuitive, inconsistent… and intellectually utterly uninteresting.
Git's core model is the interesting part, the one that will make you a better programmer, or computer user, or whatever it is you want to do that involves version control. But the specifics of the command line interface? That's neither interesting nor a portable skill. "Command line bullshitery" is a perfect term to describe it.
Seriously, even "end losers" could use this. I also believe this can be generalised: some software just isn't usable through the command line. For day to day interactive use, it needs a neat, special purpose graphical user interface —Bret Victor has taught us how powerful they can be.
The command line is still invaluable when interacting with other software, or for automation. Then it should be designed for those, not for interactive use. Simply put, it should be an API —which you could use to build your wonderful GUI on top of.
Paul Graham has talked about the pain of installing software, and every time I have to do it, I always have trepidation. "Is this going to be the time apt-get barfs at me?"
Software installation is still a big pile of bullshit. For the people who spend their time deep inside one ecosystem, it can be okay, but most people have something to do besides live deep inside one ecosystem.
A few weeks ago I was just trying to find a JavaScript minifier on a Linux VM. So I googled and spent an hour digging through various pieces of crap, incompatible versions of libraries, asinine "gem install" error messages, and fun reading Stack Overflow answers saying things like "why didn't you have lib-foo-fuck-you installed already?"
And none of this is valuable for me to learn because in five years all the current package maintenance stuff is going to be thrown out and replaced. Not necessarily by something better (although that's likely the hope, leading to http://xkcd.com/927/ ).
The bullshitery he's talking about isn't programming, but compiling, installing and setting up various software that are still in an early stage of development and aren't user friendly yet. Just something you have to do but isn't related to programming or research.
Somehow, I agree that an all-around computer scientist has to know how to deal with this, but it's probably not the best way they can spend their time.
One of the neat things about computer science research is that researcher B's work is frequently based on researcher A's software and A's software is "academic", which means that it actually works on exactly the three examples in A's dissertation.
Well, yes and no. If you want to look at something very small, you have to learn how to use a microscope. It's not that hard to learn how to use a simple microscope, and you can make adjustments by thinking about the physical principles, which are universal. And if a certain type of microscope isn't suitable, you can always change or someone can design a better one.
The *nix command line is not based on physical law. There is no mathematical or physical reason that human-computer action has to be through an underpowered, user hostile design that requires lots of unnecessary memorization. People use it because everyone does. You can come up with a better design, but you'll still have to use the old design if you want to interact with anyone else.
Edit:
By "underpowered", I mean that passing byte streams and parsing them is less powerful than passing objects. And this is made worse by the fact that different commands have different output syntaxes.
> (...) underpowered, user hostile design that requires lots of unnecessary memorization.
User hostile I can understand. Underpowered is just plain false. Parsing log files, relating data between them and aggregating results is a common task for any decent sysadmin. I know no interface as powerful (measured as the ratio of information quality over time spent) as the Unix command line.
Many powerful interfaces have ultra steep learning curves. The Unix shell is one of them. Steep learning curves are a flaw, of course, but they do not invalidate the other qualities of the interface.
In your opinion, of course. Many of us find the * nix command line not only elegant and highly-productive, but actually enjoyable.
In fact, the only Linux command line tools that I did not immediately start using in a highly productive manner are `tar` and `find`, arguably two of tools that least abide by the ideals of * nix command line tools (I've since gotten used to `find`, but `tar` may always send me searching for my personal wiki's corresponding entry[1]).
If you want to argue that there are better ways to program on the console, I grant that it's possible -- although as mentioned, I find the composability of * nix tools to be an almost magically productive approach.
But to condemn anyone to a life of GUI tools is not only going to drastically increase their chance of developing carpal tunnel syndrome, but also inevitably will slow down their work flow -- often drastically. It's simply not possible for even an experienced user to point and click with a mouse as fast as an fluent typist can issue commands on the terminal.
I too love the CLI, but I wish someone would go through and standardize flags, naming, ordering concerns, long-form arguments, etc across all of the POSIX tools. GNU put in some effort here, but in my opinion they didn't go far enough and non-GNU operating systems (BSD, OSX, etc) are missing out.
Actually, as much as I dislike Apple, they're probably one of the few entities that could pull off something like this.
I so agree with you. The only thing I hate about the *nix userland is that all tools follow their own set of arbitrary concerns regarding the things you mentioned. Really limits the intuitiveness and discoverability of the system.
Honestly I feel like most Unix command-line tools are pretty good. I can make a good guess what "-n" and "-i" will mean on a new Unix tool based on context.
The git commands are a big exception; it's like each individual git command was written by its own committee, each deep with NIH syndrome. The one example I remember is two different git tools having a different way of colorizing their output.
If the command line were underpowered, it would have been abandoned decades ago. It's still around precisely because it's incredibly powerful, and nobody has come up with a suitable replacement that doesn't involve sacrificing a lot of power.
Further, all of the "No, obviously this would work much better!"s have been tried already. Dozens of times, if not hundreds. Some of them you can even download right now. Nevertheless, the command line persists. It may not be perfect in every detail, but it's far harder to exceed than it seems at an initial, frustrated glance. If you hope to someday so replace it, it would be wise to understand exactly why that is, lest your effort completely fail in exactly the same way as so many prior attempts.
I use command lines maybe once a month. For almost everything, it has been replaced. For those places it hasn't, I blame the tool for not automating some process that could have easily been automated.
I absolutely live at the command line, and when I'm forced into a walled garden I blame the tool for not properly exposing its functionality to the rest of the system so I can easily automate it the way I want it automated.
Edited to add:
Note that this isn't a claim that anyone else (in particular) is Doing It Wrong - it's what works for me, I'm sure there are other points in the space that work as well or better for others. That, itself, should not be taken as a claim that every point in the space is equivalent - that's not true either. What I do strongly refute is any notion that the command line is "under powered" in general.
"I used to be fluent in French. But I got sick of remembering all the arcane stuff. Now it's just pages away in a phrase book."
Probably you were never really fluent in French in the first place. Which is to say, you were never really entirely comfortable at the shell. Which is fine - as I said, I don't assert that it's the best fit for everyone. But for me, just like producing English doesn't feel like I'm "remembering arcane stuff" neither does producing Bash, even though I fully recognize that objectively both are plenty weird.
That's just wrong. I've written shells. I've written tools. I started in this business before IDE's existed. Some folks grow out of it, some stay because its so cool to know what all those switches mean.
"And the last comment was to match the tone of the parent comment."
Except you didn't match the tone of the parent comment. You said, "You're juvenile and only prefer the command line because of pride." The parent contains nothing similar; the nearest I see is a reasoned guess at your level of comfort using a tool - not even your level of skill with the tool - accompanied by an explicit statement that it's not intended as a judgement. Even if it's wrong, that's not an insult.
If this is the level of discussion I'm going to be getting, I'm done with this thread.
I guess I was put off by the glib dissection of my skills and personality. Maybe it didn't seem that way when written, but it sure did when read. Its call 'ad hominem' and I responded in kind, which was probably not very cool. I apologize.
It's not that the commandline is necessarily underpowered, imo, it's that the discoverability and intuitiveness of the *nix userland is pretty low. Man pages are a great way to document every flag a program accepts, but are a terrible way for someone to figure out some simple use case for the program. Similarly, flags are named without any regard for intuitiveness (-l is liable to mean different things for any program you encounter, and the precise meanings one program decided on can be hard to remember because there is no explicit commonality with any other tool).
In that sense, it absolutely is a user hostile design and it involves lots of unnecessary memorization.
Yes, by no means consider my post a defense of every quirky detail of history. My point is more that one must start by correctly identifying the problems before one could hope to solve the problems, and "lack of power" is definitely not it.
The command line is the heart of Unix and Friends, which is why it wasn't abandoned decades ago. And it's almost impossible to replace the *nixes because of network effects and extraordinarily high costs.
The command line is "powerful" because it is "simple" in the sense that it doesn't really do anything for you. Commands have their own input and output syntax based on their needs and it's up to the user to figure out how to fit it together. I think one having standard serialization format, so that you wouldn't have to waste time learning and thinking about each command's special little syntax would be much more powerful.
Part of the reason that people still use the *nix style interface is that the large number of people who thought they'd come up with a better design were actually wrong about that. It's harder than it looks.
You can totally "Computer Science" without programming. It's a big field, and a big portion of it is pretty much math. You probably cannot "Applied Computer Science" without programming.
But it does involve command-line bullshittery which is more what the article is about.
The article isn't bemoaning the state of programming languages or their tooling necessarily---more all the steps to get a programming language toolchain off-the-ground and working (like an Android dev environment etc. or a cross-compiling environment).
I just replied in the context of the article. I'm assuming if you are doing math proofs all day you probably aren't dealing with "command line bullshittery".
I find it sad, that in an academic setting no less, a PROFESSOR is telling his students it's BULLSHIT to know how the systems that are vital to their work actually function. He sounds like the guy that goes to jiffy lube because he doesn't know what an oil filter is, and thinks that it's "bullshit" that anyone does. I just want to turn the key and go! That's great, but as an academic you should also want to know what the fuck happens when you turn the key. And encouraging your students to devalue knowing how things work under the covers... I think he needs to find a new line of work.
Shouldn't computer skills courses be prerequisites for programming courses? He's right that setting up the needed software shouldn't be an impediment to completing work in a programming, but that's because the university should be preparing the students with those skills before they get to his course.
If you're going to need to configure a VM and toolchain for many of your subsequent courses, it makes sense to start off with a "configure a VM and toolchain" course.
Y'know, even at MIT 20 years ago, there wasn't an assumption that people knew how to use computers, even for the computer science classes. Each class had an evening lecture on getting through all the "bullshit" that you needed to get started and actually learn the interesting things, instead of the peculiarities of the latest flash-in-the-pan toolchain that didn't exist 5 years ago.
The very first class in the CS curriculum I took was "Intro to UNIX". Every other class in the curriculum assumed that as background knowledge. It's completely reasonable to expect a configured environment.
I understand the perspective you're taking, but I politely disagree. I think you're missing the bigger point here.
Let's say someone is interested in baking a cake. There is a LOT you can learn, spanning general baking techniques, chemistry, design, art, tasting, etc. But if your immediate response is "we need flour, so go plant some wheat and wait a few months," they would likely lose interest.
Teaching people to plant and harvest wheat is awesome, but for most people it probably shouldn't be the first thing you're met with when you are trying to learn how bake a cake.
If you're studying "Baking Science", which covers everything from the beginning to the end, starting with "Let's grind some flour" is a good idea. People studying "Baking Science" need to understand the whole process, rather than believing everything starts and ends with pre-packaged recipes and machines that do everything for them.
That's what's going on here. A "Baking Science" curriculum that didn't impart people with a knowledge of where flour comes from and how it's made would be a joke.
There may be space in the whole curriculum for that, but it's probably not essential here and now. The whole pull of Bret Victor's presentations is that they show us what it would look like to program if our tools were as modern as Word.
The baking-metaphor problem is that you have students who are supposed to come in and investigate how the arrangements of toppings on a pizza affect both nebulous qualities (like deliciousness and heterogeneity) and rigorously measurable ones (like moisture and elasticity) of the pizza crust. However, when they come to your kitchen, usually most professors put them in a totally new room which contains millstones and grain and milk ready to be turned into fresh mozzarella, with nothing labeled. There are reasons for this -- real pizza aficionados have very different choices about how they want to compose their sauces and which cheeses they want on the finished result and even what leavening agent causes the dough to rise, so the framework for pizza-baking is as general-purpose as possible. But those reasons make things difficult for the newcomer.
The professor is just saying, "when we start, I walk everyone through the process of finding the flours over here, the additives over there, and using the bread-machine to mix them and knead them. I then show them where to find the canned sauces and the pre-grated cheeses, so that they can start with minimal knowledge baking up some pizzas for science. Our concerns are very high-level and I want them to be fussing with baking times and topping arrangements, but so many of my students seem to be stuck on trying to turn milk into mozzarella."
The problem he overlooks is that we do not want our tools to be "as modern as Word". We want modern tools, but not modern as Word defines it.
There are excellent solutions for his problem. Distributing a pre-configured VM is a good one. Instead, he wants students to have the experience of bootstrapping, but he also wants it to be painless and magical.
But instead of looking at his actual problem, he's wound up railing against all the critical freedom that makes the field something other than a glorified exercise in painting by numbers.
EDIT: For the record, turning milk into mozzarella is actually really easy and quite suitable for a novice. I've done it. Takes about an hour, end to end.
My understanding is that this is not so much for a single course (where a VM would be a good solution) as for general student research. Prepackaged works less well there (though may still be made to work).
> If he decides to ignore all the tools (puppet, chef, scripts, etc.) designed to make all of this easier, that's his fault.
You're kidding here, right?
I find Puppet and Chef superconfusing and not worth the effort to learn at my job right now, and I'm a fucking programmer by hobby and profession. This is exactly the kind of bullshit people doing science should never have to deal with.
Puppet, at least, is pretty straightforward. You are describing what you want your system to look like. Puppet takes that description and makes your system look like that.
People doing science who want to use computers should expect to have to learn a thing or two about using them. As in more than using Word if they want to do complex, custom, not-done-before tasks. Much like people who want to do novel things in chemistry should expect to learn more than how to make black powder.
This guy is upset that novel things haven't already been thought of and planned for by the people who make shiny GUIs. This is a farcical position. If it's really that novel, of course nobody's written a GUI for it.
Point is, tools to address his problem already exist. He dismisses them, because they don't do it in an arbitrarily flexible and powerful way while still being infinitely iTunes-y.
> People doing science who want to use computers should expect to have to learn a thing or two about using them.
A thing. Or two. Not half-a-year-worth of full-stack dev education many.
He is not complaining about having to learn things. He's complaining about having to learn irrelevant things. Infrastructure. He wants to make a soup, and he's being asked to run his own plumbing to get water, and to drill his own gas for heating. And people here are saying he should stop complaining, because nobody is making him build his own drill - it's already provided via Puppet script in a Git repository.
He doesn't dismiss tools because there ain't iTunes-y. He dismisses them, because to use those tools he has to learn more tools, for which he has to learn even more tools, and all that effort is throwaway, because the next time he will need to learn different toolchains (or should I say, tooltrees with stupidly high branching factors).
> Puppet, at least, is pretty straightforward. You are describing what you want your system to look like. Puppet takes that description and makes your system look like that.
It makes sense for a team of web developers doing high-scalability applications. It is bullshit for a researcher who just wants to crunch some numbers with a bit of Python code.
There's the problem. He doesn't understand what the proper bounds of relevance are. He can't see how a given task is relevant, so it's bullshit. That's more a comment on the limits of his thought processes than anything else.
He wants to do novel things. This means going places where not everything is preconfigured for his pleasure. It also means he needs to know how to use his tools, because when he runs off the edge of what point-and-drool does for him he will need them.
He asks for a world where point-and-drool covers everything. All I can say is that what he asks is impossible for what he wants.
To be fair, unfortunately as of 2014 considering there are 10^2 main disciplines, with 10^4 main research areas, with 10^6 different things to learn and 10^7 researchers building stuff to teach, expecting a GUI button to do those myriad of functions in diverse ways would be naive. Maybe, the primary school education tools are close to what you/he describe in simplicity of use.
The analogue in CS would be to give the students a pre-configured environment if you want to deep dive into a specific topic before teaching how to set things up. If the students are using a known OS, all you need to distribute is a shell script. Otherwise give 'em a Vagrantfile or something.
That being said, you'll want your students to understand their tools sooner rather than later.
That explains why NASA (and other agencies) always seem to have so many issues with unit conversions. It's all just Measurement Bullshitery that they shouldn't have to deal with! /s
"But what about the magic of version control, GitHub, pull requests, forking clones, cloning forks, diffing forks, forking diffs, etc., etc., etc.? None of that matters for someone who works with binary file formats (i.e., user culture) rather than plain-text formats (i.e., programmer culture). There was such a disconnect between the two cultures that it was hard for me to come up with responses to these sorts of “why use X rather than Y” questions without sounding either incomprehensible or patronizing."
1. Is he seriously implying that version control is just some arcane thing that Unix programmers do, and that it's bull shit that students have to learn it?
2. If you can't answer students' questions about why these CLI tools are needed, then that does not mean there are no good reasons--it means you don't know, because you don't understand yourself.
"It's comically absurd that the most sophisticated computer programmers nowadays are still using an interface that's remained unchanged since before humans landed on the moon. What the duck?!?"
"Students are starting to grow suspicious: These instructors are supposed to be expert programmers, but their tools look pretty primitive to me."
This is a problem of perception, both on the students and on the professor's part, not a problem of reality. Do you think there's a reason that programmers still use these interfaces decades later? I'll give you a hint: it's not because they don't like change.
1. He is implying the students believe it. From their point of view, the CLI does look arcane, primitive, and useless.
2. it's more complicated than that. Yes, if you understand something, you can explain it. No, you can't automatically explain it in 5 minutes. Sometimes, the knowledge gap is so great that you need months to explain it all. In 5 minutes, you can only make claims your students will feel entitled not to believe if they feel like it. If your claims don't match their experience, and you have not demonstrated trustworthiness, they simply won't believe you, then tune out. http://lesswrong.com/lw/kg/expecting_short_inferential_dista...
Speaking as someone who has changed his own oil more than once: if I needed to know how to do that in order to operate my car, that would indeed be bullshittery. I benefited in no way whatsoever from changing my own oil. It was, as it turned out, simply a very- low- ROI- recreational activity.
The point here isn't that the command line is bullshit. Knowing how an engine lubrication system works isn't bullshit... for a mechanic. But it is a waste of time for a cab driver.
So considering the OP is an "Assistant Professor of Computer Science University of Rochester" please refine your analogy whether his target audience falls closer to become the cab driver or the mechanic?
Edit: quoted below OP's case:
>> Write a piece of prototype computer software that demonstrates the feasibility of a novel idea."
>> Write a piece of prototype computer software that collects, processes, and analyzes data to produce novel insights about some topic"
Nonsense. The standard writing tool in mathematics and computer science is LaTeX, which has plenty of bullshittery of its own. Most researchers will generally be suspicious of a Word-produced paper, since it usually will come from crackpots.
As a professional programmer, I think that prof offers excellent advice. There's a difference between programming-in-the-abstract, and the mis-evolved "ls -l ls tar -zxvf rm rm rm ssh mv". Written by people in real-world dysfunctional settings.
There's alternatives to bash commandlines, to interactively explore/navigate running systems. Take REPLs, SQL prompts, etc.
Profs don't do their students any favors if they let poor design pass without comment. Unix has a history, which you can get if you read early papers from those involved, and users can critique it like they critique whatever website they use nowadays.
That's still "command-line bullshitery" according to him though. Because it's an 'arcane interface' that "hasn't changed since the 60's". When his student wonders why he is using a text-based interface, he doesn't have an answer. Since he doesn't know, then obviously there is no good reason, so It's All Bullshit(tm) is the answer.
There is indeed a difference between programming-in-the-abstract and Guo's "bullshit"; it is exactly the difference between whiteboard doodles and running code: programming.
His point was that it is a bullshit tax that you must pay.
The Jiffy lube analogy is wrong. It is more like buying car insurance, registration, inspection, and filling the car with gas. Those things are "bullshit" that has nothing to do with what I am trying to accomplish with a car, which is going places faster than walking, and carrying more stuff. I must do them, but they have little to do with what I want to accomplish with a car.
While the original article didn't particularly garner my sympathy, I get concerned when people start complaining that others don't know how systems "actually function".
Image that, the next time you sat down to write come code, you're asked for the value of Planck's constant and to solve a couple of Feynmann diagrams for holes in a semi-conductor before you can write a single line. After all, a programmer can't just live with the high level abstractions of machine code and Kirchhoff's rules - she should know how the systems she works on actually function!
Everyone uses some abstraction when they think about writing code. High quality abstractions (e.g. machine code) should be encouraged and things which violate those abstraction (e.g. bombarding memory with radiation) should be avoided. Low quality abstractions (e.g. monads are burritos) should be avoided. Being charitable, the professor seems concerned that poor quality abstraction are dominating and students are being forced to drop to abstraction levels that aren't relevant to their studies.
At this point, isn't it more effective to have a virtual machine image with everything set up? Virtualbox runs on tons of platforms, and I imagine you could build a 'CS' box with most of the tools installed and just update it a few times a year.
Granted, that keeps them from learning how to set it up on their own, but his stated goal is to cut out that BS.
I think this would be even more valuable in undergrad, I remember my first few college CS classes spending the whole lab helping people install java on various flavors of windows.
This was what I was going to say. As an example, a course I did on Coursera recently had an ubuntu VM you could just download and it ran everything that was required for the course. This is probably quite prevalent in CS-related MOOCs and I think in most cases is a great idea.
A course I've taken on Coursera years ago did exactly that. Not that would have been a big problem for me to setup the software we needed (I was on the very same Linux distro anyway) but it saved time to me too and I didn't read all the usual bullshittery (funny word) in the forums.
So Dear Professor, you had to deal with the command line to setup your own machine, do it in a VM and let your students download it.
For extra safety pin the versions of the software your students will be working on (for example Octave) if you're afraid that an automatically updated new version will be incompatible with the assignments and all the other stuff you prepared for your class.
The bad thing here is that it sounds like these are graduate students, not undergrads. Grad students should understand how to wrangle the command line (if not, how did they get through undergrad?).
The first lab of my second programming course in University involved making sure that every student knew how to compile and run Java programs on the command line. The reason the Prof gave for this exercise was, to paraphrase, that he was tired of dealing with grad students who have no command line knowledge.
It is certainly possible to get through a computer science undergrad at (to borrow Spolsky's term) a Java School and have absolutely no knowledge about Unix nor the command line. "Modern" tools like Eclipse and IntelliJ hide all of that stuff away.
That is a good point, I majored in Computer Engineering, so my experience is a little bit different (kind of hard to cross compile to various embedded platforms without using a command line).
I think this is a "stages of moral development(1)" thing. In post-conventional levels of development, all tools would be valued for their strengths. We wouldn't denigrate a tool for belonging to a class of tools.
"I've spent the past decade mostly leading my own research projects. This meant that I did the majority of the command-line bullshittery and programming to produce the results that led to publications, especially ones where I was the first author. In short, I've gotten very, very, very good at command-line bullshittery."
You mean you learned a new skill and got better at it? Your example suggests that there's only one way to improve your skills when it comes to working with "command-line bullshittery"
In a linked article about why the "command-line" is "bullshittery" in the first place he compares Python to Excel and declares Excel superior because it can make graphs much more easily. His students apparently ask why use Python when you can use Excel.
First off, Python is not a command line. Secondly, what the fuck does he think Excel's source code is written in? MS Publisher? They're just different things.
The author does not seem to understand why command line tools still work the way they worked in the sixties (as he loves to point out), which is because it just works. He mentions git, the version management system that uses the command line mostly, but forgets to mention that although git could surely have (and has) a GUI, it would disable you from doing many things. I often pipe git output to other tools, something you just cannot do with a GUI.
Oh, and he uses nano for command line text editing. I suppose that also explains a thing or two when working with Vim or Emacs is so much better than any other text editor.
I imagining a scenario in which I have a team and I have 10% git experts, 90% not -- can I create a system in which they are basically "drop boxing" and the merging etc gets handled automatically or decisioned by an expert? -- Maybe ultimately everyone should just learn git since it isn't that complicated.
I've been in such a scenario. Making it simple and drool-proof for some people while everyone else works around the consequences of that is not as lovely as it sounds. It winds up being much, much easier to just teach whoever else enough of the basics to use git.
It's almost certainly less difficult to use than whatever ERP the company uses.
> Python to Excel and declares Excel superior because it can make graphs much more easily.
I don't really think he meant to say that. I think he is using a writing style which emphasizes with different view points, namely seasoned programmers and their befuddlement with normal user's inefficient tools, and the normal users' befuddlement with the seasoned programmers seemingly arcane tools that seemingly accomplish the same things that their prettier, more easy to use tools already do.
> [he] declares Excel superior because it can make graphs much more easily.
You should read more carefully. He claimed no such thing. His real claim was that users tend to react like that. And we programmers must be prepared for such backlash.
> The author does not seem to understand why command line tools still work the way they worked in the sixties
The author is saying the users don't understand. He knows about their goodness. The problem is to teach it.
> He mentions git, the version management system that uses the command line mostly, but forgets to mention that although git could surely have (and has) a GUI, it would disable you from doing many things.
> I often pipe git output to other tools, something you just cannot do with a GUI.
A nice GUI could, among other things, record what you just did and translate it into the command line equivalent. But more importantly, when you have a GUI, the command line no longer have to act as an interactive user interface. It can now be dedicated to what it does best: API.
Removing the command like would bring the apocalypse (as it mostly did on Windows), but merely adding a GUI can make things much better.
> Oh, and he uses nano for command line text editing. I suppose that also explains a thing or two when working with Vim or Emacs is so much better than any other text editor.
He knows about the Vim/Emacs holy flame wars, so he most likely used one or the other. But go teach either of them to the hapless student. The Emacs tutorial alone takes several dozens minutes to get through. Extremely useful, but quite steep. Nano on the other hand can be taught in seconds. So it is more likely the first text editor the students will see. If you want them to write Python code and you only have an hour before they leave, you have little choice.
Clearly, all of the people who make useful and powerful tools should spend less time on useful features and more time on shiny Apple-style UIs. Because who wants useful features when you can make software cater to people who don't want to learn?
This author's problem is not with bullshit. It's that he doesn't believe he should have to understand his tools at all. He wants them to magically work because he knows what he wants them to do.
Do you want to do novel, interesting things with your tools? Don't expect someone else to have paved the way for you first.
While I can sympathize, does anyone else feel it is odd that we are talking about a Computer Science professor complaining about how basic unix tools work? Sure, they aren't perfect, but I think it is going a bit far to say that CS researchers shouldn't have to understand on the other 99.999% of developers in the world use computers. This feels a bit ivory tower to me.
Consider that a computer science professor beginning a research program with students is roughly equivalent to a software development manager, just recently promoted from a development role.
I think it's got to be time to revisit some of the ideas of the Smalltalk or Lisp machines, principally that of one language all the way down from app to lowest level.
One of the biggest pieces of brain damage the UNIXes have inflicted on the world is the division between command environment and programming language. It may have once served a purpose, but in modern systems we have a level of madness that is the equivalent of expecting a literature student to master all Indo-European languages before being able to work in French.
The growing importance of services over the network and containers gives some cause for optimism, since if we can agree about the interfaces between services (yeah, big if) then each container can hopefully become a steadily simpler world unto itself.
Yes. We should definitely require everyone to use the One True Way! Because that has always worked so well in the past!
[P.S. You also fail to explain why not just use Microsoft for the One True Way rather than a LISP machine. Microsoft is all about making their tools work together with other Microsoft tools so that everyone should do things the Microsoft Way!]
I think there is really a market for this sort of thing now or in the near future. Most people now have a computer in their pocket capable of doing all their personal computing, but incapable of doing most of their professional computing. So there's a big opening for purpose-built professional systems, and in that arena, I think Smalltalk style system malleability could be a big win.
He mentions "bullshit" 19 times in the article. It's a shame he isn't able to describe why it is bullshit (apart from that he has to use it) or how we could make it any better.
The command line is an incredibly powerful tool, which allows us to very quickly combine components together in many more ways than use cases that could be considered by a GUI developer. This is why he's having to use a command line in the first place: no GUI developer has addressed his very specific use case, and nobody has figured out a better of doing these things in the general case than the command line.
It would be great if it were easy to learn. But short of any real workable suggestions, nothing is going to change.
In general, I understand the word "bullshit" to mean something that has been constructed to obstruct somebody in a way that isn't actually necessary. I don't see how that applies here. The command line is the only known way for him to achieve his goals. By definition, then, it cannot be bullshit.
This results in people like a friend of mine, who has a Masters degree in computer science... yet I had to walk her through swapping out the power supply in her PC.
I would think that someone who would go so far as to get a masters degree in a topic would also be curious enough to know exactly how some of the tools used in that field plug together and work? Am I wrong here?
Maybe you're right, maybe you're wrong. But the power supply and the case are probably the two least interesting parts of the computer to somebody with a Master's degree in CS; it may well be the case that she knows a lot about the cache in her cpu and the various sockets in her motherboard, and she just doesn't care about the PSU because as long as it supplies enough power, it's boring.
Also, let's be clear here. At heart, building your own computer is like playing with Lego, except that each piece is very expensive and you're terrified of breaking it. Plus there's probably a specific order you need to follow to make sure everything fits properly, but you get no instructions about what that order is, because it depends entirely on what pieces you bought. Also, if you don't already know what you're doing, it's entirely possible to buy pieces that just plain don't fit together and you won't realize it until you're elbow deep in the case searching for a socket that just plain doesn't exist.
As somebody who has gotten a master's degree in computer science and also built his own computer, I definitely feel like the master's degree was far more interesting of an endeavor and if somebody said "I'm really interested in computers, but not in putting them together; it seems like just putting tab A into slot A but all of the tabs and slots are poorly labeled", I'd nod my head and say "Yeah, that's basically it. I enjoyed building my own, but it's not for everybody".
Everybody's knowledge breaks down if you dig deep enough. You can for example ask how to produce the metal for the wiring of that power supply and from which minerals and ores. You don't need to know this since this isn't computer science and other people provide the materials for you. So the issue boils down to two questions. A philosophical one and a practical one.
Does understanding of the power supply belong to computer science or to some other discipline, like electrical engineering?
Do you need to swap your power supply on your own or can you rely on other people offering this as a service? Apple's move to prevent users from replacing batteries in iPhones offers an interesting perspective here.
"A computer scientist specializes in the theory of computation and the design of computational systems." Computer science is about hardware e.g. VLSI. It is a shame that CS undergrads aren't forced to learn a little more about circuits, etc
Every domain - whether it be physics, chemistry, electrical systems, biology, and yes, even computing systems, has an initial training window in which the practitioner requires some training on the the basic elements of the toolset. Initially, it's painful, and annoying, as you are literally starting from the ground, and you have no understanding of even the language to understand the instructions you are being given. But, eventually you develop a vocabulary, and learn the rudiments of the tools - even if they are completely peripheral to your actual domain of research.
I have a friend who wanted to be a cook - she was interested in food, when she went to chef school for a couple years, and she was learning how to cook meat, they spent two-three days just talking about knives. Apparently knives are very important to chefs. So they taught her about the metals, the edges, the sharpening, the care and maintenance - the entire science of knives. She went in with no expectations she was going to have to learn any of this stuff - but before she could start cooking, she had to learn how to use her tools, and jigs, and moran edges, and Scandinavian Grind, and what the hell does this have to do with cooking again?
Same with working in a field that requires you use software systems. The command-line is your toolset. Master it, and you can do anything. Don't master it, and you are like a chef who is using whatever knives happen to be in the kitchen, and in whatever condition they happen to be in.
But, if he thinks that we have "command-line bullshittery" today, when 95% of the time I can just type "brew install foo", or "apt-get update bar", and have a pretty damn good chance that 95% of my dependencies are fullfilled, and if not, a quick google of the error message will usually give me a stack-exchange/server-fault/stack-overflow solution, I can't imagine what he thought working with these systems was like in the 1990s...
A computer science professor complaining about command-line "bullshittery" is like an astrophysicist complaining about telescope "bullshittery". C'mon, it's the 21st century, we should just be able to take a rocket to other planets!
Not to mention that even if one replaces "pipe" with "|", the resulting string would return a syntax error on the shell? When the hell would you pipe the command "git" to anything (not "git log", not "git diff", but "git")?
Yep that's what I was thinking. If he's annoyed that students are wasting too much time setting up software, they should hire some folks to build a nice repository of packages and maintain them.
when did command line builds of free software that enable one to " ... be 10x or even 100x more productive than peers who don't know how to set up those tools." become too tedious and esoteric for computer science students to master without hand holding?
"There is a huge disconnect between the elegant high-level ideas discussed on the whiteboard (while presumably sipping cappuccinos) and the grimy, grungy, terrible command-line bullshittery required to set up a computing environment suitable for implementing those ideas in code."
Welcome to real life outside academia, where you need to step down from the ivory tower and actually get your hands dirty. Incidentally we never had automatic configuration and deployment as easy as now with all the recent tools.
I've been on both sides of the fence, I remember being a frustrated student who couldn't get libraries, tools, etc. to work, and now I have some years of experience and know the ropes of working in a Linux environment. My best advice for people struggling is that if something feels difficult and painful, you're probably doing it wrong and should look for an easier way.
I remember I would bang my head against a wall trying to get Linux/Unix software to compile in Windows using cygwin, mingw, etc. and it was just a complete nightmare. However running a Linux virtual machine on Windows is drop dead easy--you can have one up in seconds with something like Vagrant. Much, much easier to get stuff working in a real Linux environment.
Once you're in a modern Linux environment if you're compiling software yourself, again you're probably doing it wrong. Check out your package manager and there's probably a compiled version already available. Is it too old? Look for someone else who's compiled it, or an experimental package source and try that next. Still can't find it? Ok download the source and give it a shot. If you have to do anything more than a typical './configure && make && sudo make install' step back and see if maybe you're doing something wrong.
So here's my theory. Whenever we have the experience of a field of useful knowledge being "bullshittery," it's because we ourselves learned it in an ad-hoc and unsystematic way. There's no question that the C language, say, is complex and full of arcana, both syntactic and from the library. But most people go about learning it with the expectation that this is so. We're often accompanied by friends and guides. Learning a language we usually have the sense that there's a fairly clear beginning, middle, and (just maybe) end--or at least saturation point, where our mastery is sufficient to do useful work--to our quest.
The (UNIX?) command line feels like bullshittery not, I suggest, because it's intrinsically more arcane and arbitrary than many languages and standard libraries, but because of our procedure of learning. People tend to discover it. We tend to learn each part (command, option) in response to a specific need. And this both compartmentalizes our knowledge (we know what "ls -la" does but not what "ls -a" does) and makes us quick forgetters (on the idea that what we learn for a specific purpose we tend not to retain for long).
Therefore, don't blame the command line. Blame the educational process. And if you want to experience the command line without frustration--not as "bullshittery" but as simply a tool you understand and have mastered--the solution is to do what the author seems to allude to, which is to take a more systematic and deliberate approach to learning the thing.
220 comments
[ 3.0 ms ] story [ 233 ms ] threadInstead of going super far down a path, following each step along the way, and somehow ending up with a yak in your hands, you're immediately asked to find a yak and you rightfully ask, "what does this have to do with yaks?"
Yes, the command-line is powerful, but it is definitely a huge hurdle for most as they're really just trying to do something else. Well stated PG.
A base skill of doing computer science research is programming.
Can you program without computer science? Absolutely. Can you Computer Science without programming? I would say no. Being able to look at and understand how to use a language or library is just something required to get to the last tier of computers science knowledge. I think every researcher would love to get rid of their bullshittery, and often they have lab technicians or interns do it for them but in the end they all had to pay their dues and have to know it in order to mentor and help those below them.
So perhaps what is more important to a researcher than programming ability is adeptness at dealing with command-line bullshittery, since that enables one to become 10x or even 100x more productive than peers by finding, installing, configuring, customizing, and remixing the appropriate pieces of free software.
I'm torn about this article. Clearly this researcher, in his role as mentor, has identified a skill gap that's hindering his students. And it's perhaps even a problem that the software community can ease the pain of. But many of the things he lists in passing get down to fundamental tools of software work: version control, package management, data manipulation, etc. Yes, the usage of these things on the command line tends to be "arcane", but that's because each is encoding its own problem domain. And if you're going to be working in software in any non-ivory-tower capacity, you'd better know this stuff.
I've dealt with this kind of problem numerous times before in various contexts with workflow tooling. I.e. a single (usually) command-line tool that neatly encapsulates the most common development use cases to reduce learning curves, cycle time, and errors. These can be phenomenally successful if done well, but if the context doesn't define a workflow (e.g. student A vs. student B's research ideas) then there's no easy way to encapsulate the user's problems.
This is a well known pre-course prep step, part of a bigger to do list for all teachers to make sure the tools you suggest to the students are bundled to be setup in an easy way for your target audience.
This issue comes up all the time with young researchers (i.e. graduate students). There are a huge number of free and open source packages that can help them implement and test their ideas, but actually getting them to work together can be an exercise in yak shaving.
That being said, having facility with command line tools is a valuable skill for any researcher.
Or maybe `brew install guile`?
In this case, I'd suggest using a VM driven by Vagrant, unless you really need to be running native under OS X. That provides an isolated and repeatable environment, but at the cost of learning whole other domains of experience. My suggestion also hugely reinforces Dr. Guo's point: we've perhaps solved a problem by adding piles of additional tooling layers: (vagrant CLI, Vagrantfile interface, VM domain knowledge, setting up a Linux host (even as a toy environment), setting up a Linux host as a build environment, etc.) Heck, if we're doing it right it'd be nice to use a provisioning tool to automate the VM and build environment setup. All of this stuff is awesomely powerful, but front-loading a student project with it is nuts unless there's a domain expert who's building this tooling for them and coaching the students through it. Again, that's not the sort of thing that's likely to happen for per-student research projects.
Programmers should learn the tools to stay efficient. Version Control, build tools, etc. are priceless. But if you force feed too much at once, nothing will stick. Couple that with what for some may be their first time on the command line, and you have a recipe for bullshittery.
I'm having a hard time understanding other commenter's grief that explaining git to someone who's never typed "ls" before is anything less than bullshit to slog through. These things are best learned one or two at a time.
"Throughout this entire ordeal where I'm uttering ridiculous epithets like 'git pipe fork pipe stdout pipe stderr apt-get revert rollback pipe pipe grep pipe to less make install redirect rm rm ls ls -l ls tar -zxvf rm rm rm ssh mv ssh curl wget pip,'"
In other words, "ridiculous epithets" seems to be equivalent to telling the machine to do something. Have you got a way to get git to control your source without actually invoking git?
Workflow tooling can indeed be incredibly useful, but the context isn't the only requirement for success. If something underpinning that tooling changes or breaks, someone is going to have to understand what happened.
The people who regard that understanding as "ridiculous" are the worst people to work with and to my mind are the primary reasons that this "profession" gets little respect.
No, but git does involve ridiculous epithets. No quotes, because I'm dead serious. As an interface, Git command line is laughable, and doesn't deserve a passing grade. Yes, it's the only one we've got. Yes, many interfaces are even worse. Still, that's no excuse. We can do better. Hopefully someone will: http://tonsky.me/blog/reinventing-git-interface/
---
Let's take a simpler example:
So, you have to learn the name "tar". The option "-x" for extract, the option "z" for gzip, and the option "-f" for file (by the way, the "f" must come last, or it won't work). What the fuck is this retarded interface?First, why do I have to tell tar to extract the thing, since it's obviously a compressed archive? Why do I have to tell tar that it's in gzip format? It can decompress it, surely it can check the compression format? And why, why, WHY do I have to tell it I'm processing a file? It KNOWS it's a freaking file!!!
Surely there must be an alternative, like… like…
I personally don't know of such alternative, and don't use them, because I was retarded enough to learn the basic 'tar' incantations by heart. Now that I know them, I can't summon the courage to use a decent interface instead.But you see my point. Even for a simple tool such as tar, the common use case involves a cryptic incantation that shouldn't be needed in the first place. I'm sure many other UNIX tools are like that, I just didn't think about critiquing their interfaces thoroughly. Yet.
The core principles of the command line are very good. The level of relatively easy automation it provide is nothing short of amazing. This technology for the 70's is arguably more capable than most graphical interfaces in current use. But it does have its fair share of incidental complexity and useless quirks. We can do better. Let's not forget that.
Try unp, it's in the repo.
I know that, and more. But go and explain each and every flag to a student that just want to extract the first lesson of his first UNIX course. At this point, this is all magic and arbitrary.
I don't know about your z flag, GNU tar doesn't need it. The x flag is needed because tar can do things other than extract like list the contents of the archive with the -t flag, or create a new archive with -c.
Finally why is the f command required? My first assumption was that maybe because you need to specify the output file when you are creating an archive. I took a look in the manpage and the reason is a lot more interesting.
I knew that tar's name comes from the phrase tape archive but I hadn't put two and two together. Of course you need to specify if you are writing the archive to a file because tar was created to back up data to tape! If you think about it tar is actually doing the "right thing". Considering why it was written tar has a sane default, write the data to the tape drive.Maybe you already understand all this and I'm reading too much into your simple example. It feels to me though that when people have issues with something like the unix command line its because they just wanted to get something done and memorized an incantation to do it. There isn't anything wrong with that of course but a tool like tar is SO much more powerful than just decompressing files. Once you start to dig into it though there is an internal consistency and logic to it though.
Yes I do. Every single item. I just feel for the hapless student that is required to send a compressed archive of his work to the teacher, and is using tar for the first time.
There's only one little exception: I didn't know GNU tar doesn't require the '-z' flag (which by the way means 'this is a gzip archive') when extracting tar.gz archive. Anyway, I bet my hat that the '-z' is required if you compress something and output the result to the standard output: there will be no '.gz' hint to help the tool magically understand you want it compressed. If you omit it, tar will likely not compress anything.
The '-f' option is the most aggravating. Nobody uses tapes any more. Tar was doing the right thing, but no longer. -f should be dropped, or rendered optional, or replaced by '-o' for consistency with compilers… As it is, it's just ugly.
> It feels to me though that when people have issues with something like the unix command line its because they just wanted to get something done and memorized an incantation to do it. There isn't anything wrong with that of course […]
Actually there is. The users want to do something (usually a very common case such as compressing or decompressing an archive), then they have to memorise an arcane incantation. Yes, tar can do much more. Yes, the command line is powerful and flexible and more. This is Good. (Seriously, I miss my command line whenever I have to touch Windows.) On the other hand, some common cases are just not well handled, and it is full of idiosyncrasies that have nothing to do with the aforementioned benefits.
When the user wants to decompress files, it should not be more complicated than 'decompress archive.tar.gz'. Though thanks to an uncle comment, I now know of the 'unp' tool, which works just like that: 'unp archive.tar.gz', and you're done. (And the man page is refreshingly short.)
Not necessarily. I came to believe lately that Git for instance, has beautiful, simple, and powerful core principles… and an unacceptably crappy user interface. A hashed DAG of commits with a few pointers to navigate it, that's great. But the magic incantation that you're required to type on the command line are too complex, unintuitive, inconsistent… and intellectually utterly uninteresting.
Git's core model is the interesting part, the one that will make you a better programmer, or computer user, or whatever it is you want to do that involves version control. But the specifics of the command line interface? That's neither interesting nor a portable skill. "Command line bullshitery" is a perfect term to describe it.
Why I believe that has been said better than I can ever do here: http://tonsky.me/blog/reinventing-git-interface/
Seriously, even "end losers" could use this. I also believe this can be generalised: some software just isn't usable through the command line. For day to day interactive use, it needs a neat, special purpose graphical user interface —Bret Victor has taught us how powerful they can be.
The command line is still invaluable when interacting with other software, or for automation. Then it should be designed for those, not for interactive use. Simply put, it should be an API —which you could use to build your wonderful GUI on top of.
Software installation is still a big pile of bullshit. For the people who spend their time deep inside one ecosystem, it can be okay, but most people have something to do besides live deep inside one ecosystem.
A few weeks ago I was just trying to find a JavaScript minifier on a Linux VM. So I googled and spent an hour digging through various pieces of crap, incompatible versions of libraries, asinine "gem install" error messages, and fun reading Stack Overflow answers saying things like "why didn't you have lib-foo-fuck-you installed already?"
And none of this is valuable for me to learn because in five years all the current package maintenance stuff is going to be thrown out and replaced. Not necessarily by something better (although that's likely the hope, leading to http://xkcd.com/927/ ).
The bullshitery he's talking about isn't programming, but compiling, installing and setting up various software that are still in an early stage of development and aren't user friendly yet. Just something you have to do but isn't related to programming or research.
Somehow, I agree that an all-around computer scientist has to know how to deal with this, but it's probably not the best way they can spend their time.
The *nix command line is not based on physical law. There is no mathematical or physical reason that human-computer action has to be through an underpowered, user hostile design that requires lots of unnecessary memorization. People use it because everyone does. You can come up with a better design, but you'll still have to use the old design if you want to interact with anyone else.
Edit: By "underpowered", I mean that passing byte streams and parsing them is less powerful than passing objects. And this is made worse by the fact that different commands have different output syntaxes.
User hostile I can understand. Underpowered is just plain false. Parsing log files, relating data between them and aggregating results is a common task for any decent sysadmin. I know no interface as powerful (measured as the ratio of information quality over time spent) as the Unix command line.
Many powerful interfaces have ultra steep learning curves. The Unix shell is one of them. Steep learning curves are a flaw, of course, but they do not invalidate the other qualities of the interface.
In your opinion, of course. Many of us find the * nix command line not only elegant and highly-productive, but actually enjoyable.
In fact, the only Linux command line tools that I did not immediately start using in a highly productive manner are `tar` and `find`, arguably two of tools that least abide by the ideals of * nix command line tools (I've since gotten used to `find`, but `tar` may always send me searching for my personal wiki's corresponding entry[1]).
If you want to argue that there are better ways to program on the console, I grant that it's possible -- although as mentioned, I find the composability of * nix tools to be an almost magically productive approach.
But to condemn anyone to a life of GUI tools is not only going to drastically increase their chance of developing carpal tunnel syndrome, but also inevitably will slow down their work flow -- often drastically. It's simply not possible for even an experienced user to point and click with a mouse as fast as an fluent typist can issue commands on the terminal.
1. http://xkcd.com/1168/
Actually, as much as I dislike Apple, they're probably one of the few entities that could pull off something like this.
The git commands are a big exception; it's like each individual git command was written by its own committee, each deep with NIH syndrome. The one example I remember is two different git tools having a different way of colorizing their output.
Further, all of the "No, obviously this would work much better!"s have been tried already. Dozens of times, if not hundreds. Some of them you can even download right now. Nevertheless, the command line persists. It may not be perfect in every detail, but it's far harder to exceed than it seems at an initial, frustrated glance. If you hope to someday so replace it, it would be wise to understand exactly why that is, lest your effort completely fail in exactly the same way as so many prior attempts.
Edited to add:
Note that this isn't a claim that anyone else (in particular) is Doing It Wrong - it's what works for me, I'm sure there are other points in the space that work as well or better for others. That, itself, should not be taken as a claim that every point in the space is equivalent - that's not true either. What I do strongly refute is any notion that the command line is "under powered" in general.
"I used to be fluent in French. But I got sick of remembering all the arcane stuff. Now it's just pages away in a phrase book."
Probably you were never really fluent in French in the first place. Which is to say, you were never really entirely comfortable at the shell. Which is fine - as I said, I don't assert that it's the best fit for everyone. But for me, just like producing English doesn't feel like I'm "remembering arcane stuff" neither does producing Bash, even though I fully recognize that objectively both are plenty weird.
Please explain, rather than simply asserting.
"I've written shells. I've written tools."
I've written GUIs. That's pretty well unrelated to whether the interface fits you well.
"I started in this business before IDE's existed."
I don't see how that undermines my point. It would explain why you wound up using the shell despite it being a poor fit for you.
"Some folks grow out of it, some stay because its so cool to know what all those switches mean."
Veiled insults don't make your point stronger.
I was a command-line master. Because you had to be, before IDEs.
And the last comment was to match the tone of the parent comment.
Okay.
"And the last comment was to match the tone of the parent comment."
Except you didn't match the tone of the parent comment. You said, "You're juvenile and only prefer the command line because of pride." The parent contains nothing similar; the nearest I see is a reasoned guess at your level of comfort using a tool - not even your level of skill with the tool - accompanied by an explicit statement that it's not intended as a judgement. Even if it's wrong, that's not an insult.
If this is the level of discussion I'm going to be getting, I'm done with this thread.
In that sense, it absolutely is a user hostile design and it involves lots of unnecessary memorization.
Remember, intuition is not some inborn instinct. It's a product of training. To a user of MULTICS, iOS is wildly unintuitive.
The command line is "powerful" because it is "simple" in the sense that it doesn't really do anything for you. Commands have their own input and output syntax based on their needs and it's up to the user to figure out how to fit it together. I think one having standard serialization format, so that you wouldn't have to waste time learning and thinking about each command's special little syntax would be much more powerful.
The article isn't bemoaning the state of programming languages or their tooling necessarily---more all the steps to get a programming language toolchain off-the-ground and working (like an Android dev environment etc. or a cross-compiling environment).
If you're going to need to configure a VM and toolchain for many of your subsequent courses, it makes sense to start off with a "configure a VM and toolchain" course.
Let's say someone is interested in baking a cake. There is a LOT you can learn, spanning general baking techniques, chemistry, design, art, tasting, etc. But if your immediate response is "we need flour, so go plant some wheat and wait a few months," they would likely lose interest.
Teaching people to plant and harvest wheat is awesome, but for most people it probably shouldn't be the first thing you're met with when you are trying to learn how bake a cake.
That's what's going on here. A "Baking Science" curriculum that didn't impart people with a knowledge of where flour comes from and how it's made would be a joke.
The baking-metaphor problem is that you have students who are supposed to come in and investigate how the arrangements of toppings on a pizza affect both nebulous qualities (like deliciousness and heterogeneity) and rigorously measurable ones (like moisture and elasticity) of the pizza crust. However, when they come to your kitchen, usually most professors put them in a totally new room which contains millstones and grain and milk ready to be turned into fresh mozzarella, with nothing labeled. There are reasons for this -- real pizza aficionados have very different choices about how they want to compose their sauces and which cheeses they want on the finished result and even what leavening agent causes the dough to rise, so the framework for pizza-baking is as general-purpose as possible. But those reasons make things difficult for the newcomer.
The professor is just saying, "when we start, I walk everyone through the process of finding the flours over here, the additives over there, and using the bread-machine to mix them and knead them. I then show them where to find the canned sauces and the pre-grated cheeses, so that they can start with minimal knowledge baking up some pizzas for science. Our concerns are very high-level and I want them to be fussing with baking times and topping arrangements, but so many of my students seem to be stuck on trying to turn milk into mozzarella."
There are excellent solutions for his problem. Distributing a pre-configured VM is a good one. Instead, he wants students to have the experience of bootstrapping, but he also wants it to be painless and magical.
But instead of looking at his actual problem, he's wound up railing against all the critical freedom that makes the field something other than a glorified exercise in painting by numbers.
EDIT: For the record, turning milk into mozzarella is actually really easy and quite suitable for a novice. I've done it. Takes about an hour, end to end.
If he decides to ignore all the tools (puppet, chef, scripts, etc.) designed to make all of this easier, that's his fault.
You're kidding here, right?
I find Puppet and Chef superconfusing and not worth the effort to learn at my job right now, and I'm a fucking programmer by hobby and profession. This is exactly the kind of bullshit people doing science should never have to deal with.
People doing science who want to use computers should expect to have to learn a thing or two about using them. As in more than using Word if they want to do complex, custom, not-done-before tasks. Much like people who want to do novel things in chemistry should expect to learn more than how to make black powder.
This guy is upset that novel things haven't already been thought of and planned for by the people who make shiny GUIs. This is a farcical position. If it's really that novel, of course nobody's written a GUI for it.
Point is, tools to address his problem already exist. He dismisses them, because they don't do it in an arbitrarily flexible and powerful way while still being infinitely iTunes-y.
A thing. Or two. Not half-a-year-worth of full-stack dev education many.
He is not complaining about having to learn things. He's complaining about having to learn irrelevant things. Infrastructure. He wants to make a soup, and he's being asked to run his own plumbing to get water, and to drill his own gas for heating. And people here are saying he should stop complaining, because nobody is making him build his own drill - it's already provided via Puppet script in a Git repository.
He doesn't dismiss tools because there ain't iTunes-y. He dismisses them, because to use those tools he has to learn more tools, for which he has to learn even more tools, and all that effort is throwaway, because the next time he will need to learn different toolchains (or should I say, tooltrees with stupidly high branching factors).
> Puppet, at least, is pretty straightforward. You are describing what you want your system to look like. Puppet takes that description and makes your system look like that.
It makes sense for a team of web developers doing high-scalability applications. It is bullshit for a researcher who just wants to crunch some numbers with a bit of Python code.
He wants to do novel things. This means going places where not everything is preconfigured for his pleasure. It also means he needs to know how to use his tools, because when he runs off the edge of what point-and-drool does for him he will need them.
He asks for a world where point-and-drool covers everything. All I can say is that what he asks is impossible for what he wants.
That being said, you'll want your students to understand their tools sooner rather than later.
Dijkstra famously observed that computer science is as much the study of computers as astronomy is of telescopes.
"But what about the magic of version control, GitHub, pull requests, forking clones, cloning forks, diffing forks, forking diffs, etc., etc., etc.? None of that matters for someone who works with binary file formats (i.e., user culture) rather than plain-text formats (i.e., programmer culture). There was such a disconnect between the two cultures that it was hard for me to come up with responses to these sorts of “why use X rather than Y” questions without sounding either incomprehensible or patronizing."
1. Is he seriously implying that version control is just some arcane thing that Unix programmers do, and that it's bull shit that students have to learn it? 2. If you can't answer students' questions about why these CLI tools are needed, then that does not mean there are no good reasons--it means you don't know, because you don't understand yourself.
"It's comically absurd that the most sophisticated computer programmers nowadays are still using an interface that's remained unchanged since before humans landed on the moon. What the duck?!?"
"Students are starting to grow suspicious: These instructors are supposed to be expert programmers, but their tools look pretty primitive to me."
This is a problem of perception, both on the students and on the professor's part, not a problem of reality. Do you think there's a reason that programmers still use these interfaces decades later? I'll give you a hint: it's not because they don't like change.
2. it's more complicated than that. Yes, if you understand something, you can explain it. No, you can't automatically explain it in 5 minutes. Sometimes, the knowledge gap is so great that you need months to explain it all. In 5 minutes, you can only make claims your students will feel entitled not to believe if they feel like it. If your claims don't match their experience, and you have not demonstrated trustworthiness, they simply won't believe you, then tune out. http://lesswrong.com/lw/kg/expecting_short_inferential_dista...
The point here isn't that the command line is bullshit. Knowing how an engine lubrication system works isn't bullshit... for a mechanic. But it is a waste of time for a cab driver.
Edit: quoted below OP's case:
>> Write a piece of prototype computer software that demonstrates the feasibility of a novel idea."
>> Write a piece of prototype computer software that collects, processes, and analyzes data to produce novel insights about some topic"
http://www.cs.utexas.edu/users/EWD/
[1] http://books.google.com/books?id=Gb6vumaGwJAC&pg=PA47&lpg=PA...
There's alternatives to bash commandlines, to interactively explore/navigate running systems. Take REPLs, SQL prompts, etc.
Profs don't do their students any favors if they let poor design pass without comment. Unix has a history, which you can get if you read early papers from those involved, and users can critique it like they critique whatever website they use nowadays.
That's still "command-line bullshitery" according to him though. Because it's an 'arcane interface' that "hasn't changed since the 60's". When his student wonders why he is using a text-based interface, he doesn't have an answer. Since he doesn't know, then obviously there is no good reason, so It's All Bullshit(tm) is the answer.
The Jiffy lube analogy is wrong. It is more like buying car insurance, registration, inspection, and filling the car with gas. Those things are "bullshit" that has nothing to do with what I am trying to accomplish with a car, which is going places faster than walking, and carrying more stuff. I must do them, but they have little to do with what I want to accomplish with a car.
Image that, the next time you sat down to write come code, you're asked for the value of Planck's constant and to solve a couple of Feynmann diagrams for holes in a semi-conductor before you can write a single line. After all, a programmer can't just live with the high level abstractions of machine code and Kirchhoff's rules - she should know how the systems she works on actually function!
Everyone uses some abstraction when they think about writing code. High quality abstractions (e.g. machine code) should be encouraged and things which violate those abstraction (e.g. bombarding memory with radiation) should be avoided. Low quality abstractions (e.g. monads are burritos) should be avoided. Being charitable, the professor seems concerned that poor quality abstraction are dominating and students are being forced to drop to abstraction levels that aren't relevant to their studies.
Granted, that keeps them from learning how to set it up on their own, but his stated goal is to cut out that BS.
I think this would be even more valuable in undergrad, I remember my first few college CS classes spending the whole lab helping people install java on various flavors of windows.
So Dear Professor, you had to deal with the command line to setup your own machine, do it in a VM and let your students download it.
For extra safety pin the versions of the software your students will be working on (for example Octave) if you're afraid that an automatically updated new version will be incompatible with the assignments and all the other stuff you prepared for your class.
It is certainly possible to get through a computer science undergrad at (to borrow Spolsky's term) a Java School and have absolutely no knowledge about Unix nor the command line. "Modern" tools like Eclipse and IntelliJ hide all of that stuff away.
1 - with apologies to Kohlberg
You mean you learned a new skill and got better at it? Your example suggests that there's only one way to improve your skills when it comes to working with "command-line bullshittery"
First off, Python is not a command line. Secondly, what the fuck does he think Excel's source code is written in? MS Publisher? They're just different things.
The author does not seem to understand why command line tools still work the way they worked in the sixties (as he loves to point out), which is because it just works. He mentions git, the version management system that uses the command line mostly, but forgets to mention that although git could surely have (and has) a GUI, it would disable you from doing many things. I often pipe git output to other tools, something you just cannot do with a GUI.
Oh, and he uses nano for command line text editing. I suppose that also explains a thing or two when working with Vim or Emacs is so much better than any other text editor.
It's almost certainly less difficult to use than whatever ERP the company uses.
(And no, you don't have to give up any power).
I don't really think he meant to say that. I think he is using a writing style which emphasizes with different view points, namely seasoned programmers and their befuddlement with normal user's inefficient tools, and the normal users' befuddlement with the seasoned programmers seemingly arcane tools that seemingly accomplish the same things that their prettier, more easy to use tools already do.
You should read more carefully. He claimed no such thing. His real claim was that users tend to react like that. And we programmers must be prepared for such backlash.
> The author does not seem to understand why command line tools still work the way they worked in the sixties
The author is saying the users don't understand. He knows about their goodness. The problem is to teach it.
> He mentions git, the version management system that uses the command line mostly, but forgets to mention that although git could surely have (and has) a GUI, it would disable you from doing many things.
Not necessarily: http://tonsky.me/blog/reinventing-git-interface/
> I often pipe git output to other tools, something you just cannot do with a GUI.
A nice GUI could, among other things, record what you just did and translate it into the command line equivalent. But more importantly, when you have a GUI, the command line no longer have to act as an interactive user interface. It can now be dedicated to what it does best: API.
Removing the command like would bring the apocalypse (as it mostly did on Windows), but merely adding a GUI can make things much better.
> Oh, and he uses nano for command line text editing. I suppose that also explains a thing or two when working with Vim or Emacs is so much better than any other text editor.
He knows about the Vim/Emacs holy flame wars, so he most likely used one or the other. But go teach either of them to the hapless student. The Emacs tutorial alone takes several dozens minutes to get through. Extremely useful, but quite steep. Nano on the other hand can be taught in seconds. So it is more likely the first text editor the students will see. If you want them to write Python code and you only have an hour before they leave, you have little choice.
This author's problem is not with bullshit. It's that he doesn't believe he should have to understand his tools at all. He wants them to magically work because he knows what he wants them to do.
Do you want to do novel, interesting things with your tools? Don't expect someone else to have paved the way for you first.
One of the biggest pieces of brain damage the UNIXes have inflicted on the world is the division between command environment and programming language. It may have once served a purpose, but in modern systems we have a level of madness that is the equivalent of expecting a literature student to master all Indo-European languages before being able to work in French.
The growing importance of services over the network and containers gives some cause for optimism, since if we can agree about the interfaces between services (yeah, big if) then each container can hopefully become a steadily simpler world unto itself.
[P.S. You also fail to explain why not just use Microsoft for the One True Way rather than a LISP machine. Microsoft is all about making their tools work together with other Microsoft tools so that everyone should do things the Microsoft Way!]
The command line is an incredibly powerful tool, which allows us to very quickly combine components together in many more ways than use cases that could be considered by a GUI developer. This is why he's having to use a command line in the first place: no GUI developer has addressed his very specific use case, and nobody has figured out a better of doing these things in the general case than the command line.
It would be great if it were easy to learn. But short of any real workable suggestions, nothing is going to change.
In general, I understand the word "bullshit" to mean something that has been constructed to obstruct somebody in a way that isn't actually necessary. I don't see how that applies here. The command line is the only known way for him to achieve his goals. By definition, then, it cannot be bullshit.
Also, let's be clear here. At heart, building your own computer is like playing with Lego, except that each piece is very expensive and you're terrified of breaking it. Plus there's probably a specific order you need to follow to make sure everything fits properly, but you get no instructions about what that order is, because it depends entirely on what pieces you bought. Also, if you don't already know what you're doing, it's entirely possible to buy pieces that just plain don't fit together and you won't realize it until you're elbow deep in the case searching for a socket that just plain doesn't exist.
As somebody who has gotten a master's degree in computer science and also built his own computer, I definitely feel like the master's degree was far more interesting of an endeavor and if somebody said "I'm really interested in computers, but not in putting them together; it seems like just putting tab A into slot A but all of the tabs and slots are poorly labeled", I'd nod my head and say "Yeah, that's basically it. I enjoyed building my own, but it's not for everybody".
Does understanding of the power supply belong to computer science or to some other discipline, like electrical engineering?
Do you need to swap your power supply on your own or can you rely on other people offering this as a service? Apple's move to prevent users from replacing batteries in iPhones offers an interesting perspective here.
Definitely something worth thinking about as we build tools for other developers/engineers to use.
I have a friend who wanted to be a cook - she was interested in food, when she went to chef school for a couple years, and she was learning how to cook meat, they spent two-three days just talking about knives. Apparently knives are very important to chefs. So they taught her about the metals, the edges, the sharpening, the care and maintenance - the entire science of knives. She went in with no expectations she was going to have to learn any of this stuff - but before she could start cooking, she had to learn how to use her tools, and jigs, and moran edges, and Scandinavian Grind, and what the hell does this have to do with cooking again?
Same with working in a field that requires you use software systems. The command-line is your toolset. Master it, and you can do anything. Don't master it, and you are like a chef who is using whatever knives happen to be in the kitchen, and in whatever condition they happen to be in.
But, if he thinks that we have "command-line bullshittery" today, when 95% of the time I can just type "brew install foo", or "apt-get update bar", and have a pretty damn good chance that 95% of my dependencies are fullfilled, and if not, a quick google of the error message will usually give me a stack-exchange/server-fault/stack-overflow solution, I can't imagine what he thought working with these systems was like in the 1990s...
Then his students will know that it's on the bleeding-edge of The Future.
Anyone care to speculate why he is using curl for one thing and wget for something else?
Add the university repo, install metapackage and have dependency resolution take care of the rest.
Computing might help solving your problem. [1]
[1]https://www.virtualbox.org/
Welcome to real life outside academia, where you need to step down from the ivory tower and actually get your hands dirty. Incidentally we never had automatic configuration and deployment as easy as now with all the recent tools.
I remember I would bang my head against a wall trying to get Linux/Unix software to compile in Windows using cygwin, mingw, etc. and it was just a complete nightmare. However running a Linux virtual machine on Windows is drop dead easy--you can have one up in seconds with something like Vagrant. Much, much easier to get stuff working in a real Linux environment.
Once you're in a modern Linux environment if you're compiling software yourself, again you're probably doing it wrong. Check out your package manager and there's probably a compiled version already available. Is it too old? Look for someone else who's compiled it, or an experimental package source and try that next. Still can't find it? Ok download the source and give it a shot. If you have to do anything more than a typical './configure && make && sudo make install' step back and see if maybe you're doing something wrong.
The (UNIX?) command line feels like bullshittery not, I suggest, because it's intrinsically more arcane and arbitrary than many languages and standard libraries, but because of our procedure of learning. People tend to discover it. We tend to learn each part (command, option) in response to a specific need. And this both compartmentalizes our knowledge (we know what "ls -la" does but not what "ls -a" does) and makes us quick forgetters (on the idea that what we learn for a specific purpose we tend not to retain for long).
Therefore, don't blame the command line. Blame the educational process. And if you want to experience the command line without frustration--not as "bullshittery" but as simply a tool you understand and have mastered--the solution is to do what the author seems to allude to, which is to take a more systematic and deliberate approach to learning the thing.