Live data from Hacker News

Helping my students overcome command-line bullshittery (2014)

pgbovine.net

21–30 of 168 posts

Re: Helping my students overcome command-line bullshittery (2014)

#21
Can't upvote this enough, and I urge people also to read his other article on this topic, as well as the rebuttal linked within.

I got into computers in the early 1980s when built-in BASIC interpreters were considered Terribly Clever and graphics were something you got by loading/constructing an alternate character set to fit on the text grid. Like many others I stumbled onwards through Vax terminals and onto PCs, where I was lucky enough to obtain a copy of AT&T System V/386, heh heh. So that's a fairly decent 35 years of experience with command-line interfaces...

...and about 15-20 years of dismay at people continuing to reinvent the damn things. Look, you know the only reason for commands like mv and cp was that one time we had 300 baud modems hooked up to dumb terminals and there were good reasons to worry about minimizing character count? It doesn't mean that the resulting obscurantism was a good thing in itself. It's not. There are no good reasons to make people go through typing everything and to perpetuate ASCII graphics fetishism and so on. If anything, it's become an unspoken set of rules to keep people away from our nerd treehouse. Actually typing out all that shit is a huge waste of time.

Writing shell scripts and makefiles by hand is insane, we buiilt computers precisely to save us from this sort of pointless tedium. I find it really depressing that UI innovation on Linux has basically ground to a hatl and that KDE, Gnome and so on are have basically not evolved at all over the last 15 years. Back around 1999 I was running Gnome and E.16 (or was it 15?) and I had a hugely customizable UI that was may more powerful and flexible than anything on Mac/Win (admittedly this was less true for applications, but still. Nowadays when I boot into Linux it mostly feels old and tired.

As I pointed out, I've been using CLIs for a good long time. I got my first copy of Linux from comp.os.minix because there were no distributions as such at the time. It's not like I can't figure this stuff out. But I'm sick of it! There's a reason most consumer software is built around GUIs - they are better. In a well-designec GUI, you can find everything you need within the user interface, instead of having to accumulate a heap of arcane CLI knowledge (starting with the question 'what do I type?!').

It's true that the CLI offers greater flexibility of you know exactly what you want to do. It's also true that for physical items, you can cast or 3d print something that is absolutely perfectly shaped if you know what you're doing. But if you have kids and you want them to discover the joys of engineering, you should probably buy them a big box of Lego instead of a set of carving tools or a CAD workstation.

Re: Helping my students overcome command-line bullshittery (2014)

#22
I think it is ineffective to only focus on command line "bullshittery" and not discuss API bullshittery. I think the problem of learning commands pales to the problem of learning poorly-designed APIs. One extreme example of this is the Windows Event Tracing API [1], but there are many more along the same vein.

[1] http://mollyrocket.com/casey/stream_0029.html

Re: Helping my students overcome command-line bullshittery (2014)

#23
While I completely agree with the gist and point of the the article, the word "bullshittery" is a bit over-the-top.

I grew up in the suburbs of Detroit and in middle school and high school there was an abudance of shop classes; wood shop, metal shop, electronics, auto shop. In first-year wood shop, we started out with a little coping saw and a file and made golf tee holders and bird houses out of soft pine. After a while, our projects got bigger and we moved on to using stuff like planer and jigsaw. After we demonstrated proficiecy with those we moved on to more complex/dangerous tools like the lathe, table saw and drill presses. Stuff that could easily take a finger off, if you weren't careful.

Throwing someone unexperienced at a lathe or a bandsaw is simply _irresponsible_. I think that one need to learn the basics, to grasp the the mechanics, with simplier/less dangerous tool. However, one proficiency is gained there is a new class of tool available to a skilled craftsperson/professional.

Yes, its important to learn how to use a coping saw, but that doesn't make a table-saw "bullshit". Just a different class of tool, that could seriously hurt you if you don't know what you are doing.

Re: Helping my students overcome command-line bullshittery (2014)

#25
post #3

You can call command line bullshit, but at the end of the day it has the least amount of abstraction meaning more visibility in what's actually happening. Visibility is always nice, especially when something breaks. Say there was this nice GUI that built and setup lot's of projects for you. Who's responsibility is it to make sure that everything it supports stays supported?

Invariably, unless it's a major software product with a lavish budget, the GUI based setup program is less intelligible than the command line, and is accompanied by instructions consisting of page after page of screen shots, "with circles and arrows, and a paragraph on the back of each one," to quote the balladeer. And when the next version of the OS comes out, or a new version changed the installation slightly, the…

You can get anything you want with Make and Make Install.

Re: Helping my students overcome command-line bullshittery (2014)

#26
post #6

I like the same author's "The Two Cultures of Computing"[0]. It's somewhat in the same vein, and also really important. 0: http://www.pgbovine.net/two-cultures-of-computing.htm

I've always had people who wanted to learn programming become so bogged down in the tools around programming. It led me to thinking that it might be better to teach the fundamentals with pen/paper/whiteboard. To get the "this is why programming is important/powerful" message across. Anyone tried this/had any success with it?

Re: Helping my students overcome command-line bullshittery (2014)

#27
There's some merit in what the professor is saying. A lot of the minutiae get in the way when you want to get something done. Who wants to wrestle with some obscure option to some kernel module to get ones graphics drivers working before starting work on a serious graphics project?

However, having grown up in an era when GNU/Linux wasn't friendly at all, I think I learnt a lot of stuff that's valuable to me even today. Much of it was concrete factoids which I no longer need or use but the valuable parts were some kind of "meta" skills (which Eytan[1] discusses much more eloquently in his rebuttal) which serve me very well even though I don't wrangle with the nitty gritty of getting obscure software working on my computer. Some examples I can think of are.

a. I can decipher man pages and other unfriendly but mostly technically complete documentation. b. I can speak the language of the programmer fairly well which makes my work much more smoother than if I had to speak through a UX interpreter. c. Given some kind of task, I have the confidence that once I learn the domain specific stuff, the computer and software can't really cripple me and prevent me from getting work done. d. In case of an emergency, I know where the metaphorical life jackets are and what to do. I also have the confidence to get and use them. e. I'm conversant with the ideas of pipes and other such tools that allow me to automate away annoying tasks which would have otherwise bothered me. f. Even when resources are scarce (e.g. over a slow net connection on some remote machine), I know that I get work done without the fancy interfaces.

This makes me generally more efficient and I don't think I'd trade all those years of dealing with these arcane tools for anything else. I mentor students these days and a thumb rule I use to evaluate them is to see if the've managed to install a "non-mainstream" Gnu/Linux distro on their machines. If they've managed, it's almost surely a sign that they're good learners.

This is not an argument for making command line interfaces hard or keeping them that way. It's just that there's a school of thought that'll sacrifice ease of use for power and there's some value in that even for people not directly working on the tools themselves.

Footnotes: [1]: https://medium.com/@eytanadar/on-the-value-of-command-line-b...

Re: Helping my students overcome command-line bullshittery (2014)

#28
He's 100% right. It's all "bullshittery". Unfortunately, that's a rather trivial observation. Kinda like saying 2 + 2 = 4. The next part is the hard part - which to fix first?

I think what he really wants is a suri like AI that just does it all for him. Of course, at that point, I suspect skynet will have taken over.

Re: Helping my students overcome command-line bullshittery (2014)

#30
post #18

Honestly it comes down to whether or not you want to understand how something really works. If you are 99% of users then someone has pre-anticipated everything you will ever do with a computer and so there are nice pretty GUI tools to do whatever you want to do that someone has worked very hard and possibly been paid a great deal of money to create to make your life easier. If you are going to be building things or p…

The command-line is also an abstraction. I'm not anti-command line (for non-user stuff), but it irks me that we see the command line as some kind of god-given fundamental bloc, rather than just another abstraction that just happen to be at a level most programmers are happy with. I think the command line will persist as long as keyboards are the primary data entry tool, but nothing makes the command line inherently less leaky than other interfaces.
Post reply on HN