Helping my students overcome command-line bullshittery (2014) • Hacker News Board

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

#91

Post by spion » Tue, Nov 03, 2015, 3:34 AM UTC

gtrubetskoy wrote: post #34

He makes a good point. I once tried teaching my two teen-age kids Python. I was surprised to discover that before we could get into any Python I had to explain all kinds of things I took for granted (or, perhaps I don't remember how I learned them) - what is terminal (this is OSX), what is the command line, why it's called "shell" and what is the kernel, what is the current directory, what are text files, how to edit…

This is why I prefer Racket (and Dr Racket). It even comes with a great book: http://www.htdp.org/2003-09-26/Book/ . Although I'm not really sure if the material / exercises there can really spark the imagination of a child, it is fairly accessible: unlike SICP, it doesn't assume knowledge of other advanced engineering and math topics.

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

#92

Post by wfo » Tue, Nov 03, 2015, 3:34 AM UTC

kragen wrote: post #77

wfo wrote: 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…

I think you have it backwards. Someone has pre-anticipated 99% of everything you will ever do with a computer, no matter who you are. And if you don't take the time to learn the things that let you do these things in one minute flat each: comm -13 foos-not-in-bar awk 'BEGIN {while (getline 0) {sym[$1]=1}} ($2 in sym) {print $0}' sizes | sort -rn join -v2 quux zgrep -n " XYZ," /foo/bar.out.gz | awk '{print $0} END {pr…

No, nobody, say, anticipated that I would try to upgrade Ubuntu while using Spotify. Otherwise it wouldn't have broken the app. Nobody anticipated that my friend would have upgraded to Windows 10 in whatever machine state he did it otherwise it would not have deleted and reset his user profile and all his permissions. Both these issues are unexpected and require handling on a deeper (commandline) level than 99% of uses, not because the users are trying to do something weird but because the systems are so complex that even normal use can lead to wildly unexpected situations.

You can use the shortcuts and use GUIs and they are excellent and of course I use them as everyone does but if they are all you learn the moment anything unexpected happens (which happens a lot when you are using or building experimental software) you are dead in the water because you haven't developed a mental model of how your system actually works.

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

#93

Post by morganvachon » Tue, Nov 03, 2015, 3:35 AM UTC

fnordfnordfnord wrote: post #79

stevebmark wrote: post #65

This is a valid point. Learning the command line has a time and a place but it's almost entirely separated from doing computer science work at a "higher" level. Draining cognitive power to learn an unrelated technology is at best a necessary evil. It's compounded by the fact that the command line is full of tools that are inherently hard to use, because they're designed not to be terse, not user friendly. Can you tel…

man pages are horrible. I think git ( all version control, really ) would be conceptually easier to grasp with a visual representation.

> man pages are horrible.

Linux and GNU man pages can be horrible, yes. For great examples of not horrible man pages, look at OpenBSD. Their documentation is second to none. You can take what you learn by playing around with OpenBSD and apply it to just about any other UNIX-like OS.

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

#94

Post by ramidarigaz » Tue, Nov 03, 2015, 3:40 AM UTC

Animats wrote: post #57

At least standard UNIX commandline bullshittery doesn't change much. What drives me nuts is new build system command line bullshittery. There are lots of build systems, all different. Go and Rust both have their own build systems and their own directory layouts. A few months back, the Mozilla Foundation insisted that add-on developers switch from their old build system (useful for nothing else) to their new, roughly…

Oh god I can't stand ROS. I had to use it for a school project and it drove me insane. The project requirements had us using it on a Raspberry Pi, and the startup times were intolerable, for no apparent reason.

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

#95

Post by ddingus » Tue, Nov 03, 2015, 3:40 AM UTC

stevebmark wrote: post #65

This is a valid point. Learning the command line has a time and a place but it's almost entirely separated from doing computer science work at a "higher" level. Draining cognitive power to learn an unrelated technology is at best a necessary evil. It's compounded by the fact that the command line is full of tools that are inherently hard to use, because they're designed not to be terse, not user friendly. Can you tel…

Actually, I learned most command line options from the man pages. Tar, in particular, has a pretty darn useful man page, and on SGI, came complete with example use cases. The first few times I needed to use tar, I glanced through those pages, assembled what I thought made sense and gave it a dry run. After a time or two, I had what I needed and proceeded to use it for years afterword.

When exploring new software and systems, the man page system or it's equivalent is the very first thing I learn how to do. Having this skill, along with a basic idea of how to work through the use cases safely is a great skill! Sometimes I'm away from things for a while, or I get stuck with one that is strange to me, or new. I don't always remember, or I need a quick refresher too.

A glance at the consistent "man" type documentation, or maybe even the quick help many utilities give when no arguments are supplied is often all I need. This is a basic, "so? what is the lay of the land?" type exercise on par with most orientation type tasks. Nobody particularly enjoys doing them, but when they do, the stuff they do enjoy goes much better.

Re: early learning

Maybe some basic literacy is early learning! Today, one can expect to see a few basic ways we do things. Command line, shells and scripting, gui, python and other interpreters, java script, web interface...

An overview of these with some quick strategy, words of wisdom, maybe even a walk through on some representative examples would put all of this to bed early and quickly. How else are they really going to cope with computing? It's not like they can expect to only use the good stuff, can they?

In a way, this argument seems to be putting the cart before the horse. I get it. People want to get right into the good stuff, but the reality of systems today isn't like that. Why not enable people early?

Edit: And it seems the author is doing that enabling. He's careful to explain that it's necessary, important, foundation work. And doing it gets one to the interesting and new work too.

Good on him.

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

#96

Post by dexiwz » Tue, Nov 03, 2015, 3:40 AM UTC

32bitkid wrote: post #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 w…

This analogy falls flat when you compare the levels of Unix 'bullshittery' to a shop. In a shop you have a limited number of already working machines that are readily visible. In Unix, you not only have to know how to use the machines, but how to install them, how to repair them, how to select similar, yet slightly different ones, how to copy your machines and make them run the same way in a different location. And on top of that to a novice all of the machines are hidden, and you have to read manuals/tutorials/forums to even know that they exist.

Unix tools can sometimes be horribly obtuse to use when first starting out. As you get use to them, you may discover the elegance of simple programs with pipable output, but their beauty is not readily obvious. Going from Windows installers to apt-get to git clone/make/setup, is a long process. Expecting students to already know this eats up time.

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

#97

Post by pdkl95 » Tue, Nov 03, 2015, 3:44 AM UTC

stevebmark wrote: post #65

This is a valid point. Learning the command line has a time and a place but it's almost entirely separated from doing computer science work at a "higher" level. Draining cognitive power to learn an unrelated technology is at best a necessary evil. It's compounded by the fact that the command line is full of tools that are inherently hard to use, because they're designed not to be terse, not user friendly. Can you tel…

What man page are you reading? "man tar" is very informative. Also, try reading the full documentation at "info tar".

Yes, I learned a lot of commands (including tar) from the man & info pages. If you consider "man tar" to be confusing, good luck with some of the actual CS concepts that are far more confusing. Tool documentation is nothing compared to e.g. the complexity of paxos or the dry verbosity of RFC 2616.

> bash is a lesson in language design failure

Bourne Shell is one of the best languages I've ever used. Have you actually read "man bash"? Or are you cargo-culting shell like a lot of people do instead of actually learning the language?

Trying to learn modern computing without this background is like trying to learn physics without calculus. You may be able to skipping it in theory, but that will require skipping almost the entire history of the field.

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

#98

Post by kragen » Tue, Nov 03, 2015, 3:45 AM UTC

wfo wrote: post #92

kragen wrote: post #77

Earlier quoted context omitted.

I think you have it backwards. Someone has pre-anticipated 99% of everything you will ever do with a computer, no matter who you are. And if you don't take the time to learn the things that let you do these things in one minute flat each: comm -13 foos-not-in-bar awk 'BEGIN {while (getline 0) {sym[$1]=1}} ($2 in sym) {print $0}' sizes | sort -rn join -v2 quux zgrep -n " XYZ," /foo/bar.out.gz | awk '{print $0} END {pr…

No, nobody, say, anticipated that I would try to upgrade Ubuntu while using Spotify. Otherwise it wouldn't have broken the app. Nobody anticipated that my friend would have upgraded to Windows 10 in whatever machine state he did it otherwise it would not have deleted and reset his user profile and all his permissions. Both these issues are unexpected and require handling on a deeper (commandline) level than 99% of us…

Hmm, I guess I see what you mean. I don't think that's mostly the kind of thing pgbovine was talking about, though. He was talking about the hurdles of getting to "hello, world", or whatever the equivalent is in terms of modifying some random piece of research software they've downloaded. Those hurdles are what cost his students productivity when they don't know how to navigate them, and how he teaches them to leap over them.

Now, it's also true that when things break at one level of abstraction, you have to debug them at the next level of abstraction down, which means you have to understand that level of abstraction. But I don't think he's talking about that, because (among other things) that rarely has to do with the command line as such.

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

#99

Post by ryandrake » Tue, Nov 03, 2015, 3:47 AM UTC

Why not just insist that "Basic command line bullshittery 101" be a prerequisite class for whatever course he's teaching? Done.

I wasn't allowed to take all my senior-level programming electives before I learned how not to blow my leg off with C++. Same should be true for whatever research he teaches--you need to learn your tools before you do your research.

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

#100

Post by stragulus » Tue, Nov 03, 2015, 3:47 AM UTC

a_bonobo wrote: post #70

mikekchar wrote: post #60

I think the author is running afoul of a very common problem (albeit he seems to be slightly more aware of it than most): "Ease of Use" and "Ease of Learning" are two different, and often incompatible goals. He praises the command line utilities as offering productivity improvements of an order of magnitude or more, but then castigates is for not having changed in half a century. His description of the 2 cultures of…

> nobody has found a better way to do it. People have found a better way to do it! It's just that research software ignores the better way because it's mostly "proof of concept", once the paper is out, who cares who uses it, that's not my department. The incentive is to publish, not to create usable software . In fact, spending the time to make your software usable is wasted - no funding committee, no tenure committe…

All of those things sound like they are mostly the product of someone before you being lazy and very poor at writing maintainable software or documentation. This argument is akin to blaming carpentry when someone has built a poorly constructed house.

Sure, it would be nice if you could spend the majority of your time on the fun stuff, and it looks like your predecessors certainly tried. But in that case you should probably not actually write software and choose a more theoretical career path if you can't be bothered to learn how to use a hammer.