Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Helping my students overcome command-line bullshittery (2014)

pgbovine.net

Post reply on HN
Print view View original

61–70 of 168 posts

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

#61

Post by distrill »

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…

I'm in my fourth year of a computer science degree, and there are students graduating with me in a few months who have never written code outside of eclipse.

They've even had us 'deploy' a website with filezilla. It obviously works well enough for the size of projects we were dealing with, but I can't help but be a little put off by how unfamiliar/uncomfortable most people (in most of my classes) are with the command line.

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

#62

Post by Terr_ »

opnitro wrote: post #26
tormeh wrote: 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?

I haven't pushed it on any family-members yet, but "Code: The Hidden Language of Computer Hardware and Software" does a pretty good job building up from the basics, although my eyes started to glaze over a bit when it came to some of the circuit-diagrams.

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

#63

Post by iak8god »

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…

> before we could get into any Python I had to explain all kinds of things I took for granted ...

It's possible to start writing Python without really knowing any of the things you list with an IDE like PyCharm -- which is probably a similar environment to the one they used for Java in "Computer Science."

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

#64

Post by tedunangst »

Shank wrote: post #54
rsync wrote: post #45

Frankly, I appreciate a good bottleneck that selects against people that can't grok basic unix admin and system maintenance. How many hours (thousands) and dollars (tens of thousands) have I wasted on "programmers" that don't even have a home server running in their closet... That's an interview question at rsync.net, btw. What computer(s) do you have (running) in your closet ? What computer is connected to your tele…

I think that's a poor interview question. You're bound to only get people who have a disposable income to throw a server in their closet, and certainly a computer attached to their TV. Maybe it'd be a better interview question to have them work on a project for a week, which requires using the command line, rather than asking this somewhat limited question set. I don't mean to tear into you -- I see the value in what…

It's not a great question, but it's actually pretty telling if you're hiring for an admin type position. It's bizarrely, unfortunately easy to find people with five years professional experience managing unix systems who have never actually installed a system, because they were on a team and their role was chief log inspector or something. Somebody running their own server has presumably, at least the once, done the whole song and dance from start to finish.

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

#65

Post by stevebmark »

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 tell me what all the flags of `tar -xvzf` do? Do you think you would ever discover that combination on your own from reading the man pages? I certainly wouldn't have, and I'm comfortable with the command line. `man tar` is a nightmare. (Also, bash is a lesson in language design failure).

Of course the command line makes many things easier. Carving up history with git is much faster on the command line, once you really grasp it. Most build processes require some command-line fu these days. Etc. I still see his point that it's a hindrance to early learning.

However, I don't know the ideal solution. Making a full OSX install wizard is obviously more work than writing a shell script. Maybe the best middle ground is Homebrew packages. `brew install ___` is usually only one command and usually works without problems.

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

#66

Post by tormeh »

wfo wrote: post #48
tormeh wrote: post #30

Earlier quoted context omitted.

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 l…

The command line isn't an abstraction: a particular shell is, sure. Directly inputting machine instructions is a form of a command line. At its most basic the computer is executing an ordered sequence of commands and you need a way to tell it to execute the commands you wish. Machines run on a sequence of function-argument instructions -- this is fundamentally what the command line is. I suppose you could invent a GU…

>Every machine in existence has a command line interface.

No they don't. Embedded computers do not have command lines, for example. Embedded computers don't give a shit about text. Most computers do not accept commands at all. As for those who do, some don't accept it in text form, for example gaming consoles or punch-card antiquities.

Command lines are the consequence of keyboards, and whenever you see a computer on which a keyboard cannot be attached or emulated (phones) then you're looking at a computer without a command line.

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

#67

Post by balls187 »

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…

> Can you tell me what all the flags of `tar -xvzf` Yes.

x: extract

v: verbose

z: zip (or unzip) archive

f: file name to follow.

> Do you think you would ever discover that combination on your own from reading the man pages?

Yes. Turns out, I wanted to tar up my nodejs directory, but omit the `node_modules` folder.

> Of course the command line makes many things easier.

Exactly. I'm not a high level computer scientist, but I imagine, being able to easily deal with files and data would help things out quite a bit. So there while it can be painful to learn bash, it's something that pays off heaps in the long run. My opinion.

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

#68

Post by lallysingh »

JackDanger wrote: post #12

Having read the article I half-agree with the author. Yes, learning arcane and inconsistent APIs is not the work the students signed up for and studying command-line tools doesn't materially help them in the near-term. However, the things that make the command-line so difficult also make it easy to package tools together underneath simpler apis. I suspect the students are struggling with having to use tools that aren…

And hopefully it makes the students less likely to half-ass the build and command line steps in the apps that they write later.

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

#69

Post by ocschwar »

I really find this off-putting.

The same things he labels as "bullshittery" are those things that meant when I got into CS, I didn't have to hold a soldering iron, enter the CHS triplet from a hard drive's label into the BIOS, or write code in an assembler.

Other people's work, their "bullshittery" relieved me of a lot of tedious work that they DID do when it was their turn.

What makes their stuff "bullshittery" is that they did not write their code or even design it to carry out my wishes. They did it to carry out their designs. And what they wrote did not DWTheyWanted perfectly, because they were human. But they gave at least some thought to what others would do with their work. And that calls for a bit more respect.

I am right now learning Android app development. Are Intents and Activities bullshit?

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

#70

Post by a_bonobo »

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 committee, no supervisor cares.

Here are some of my "command line bullshittery" problems I run into in bioinformatics:

- There's no Makefile, just .cc files, you have to figure out how it was compiled. 90% of the times a simple "gcc" won't cut it.

- There is a Makefile but the flags are all outdated and there's no ./configure to get flags for your system

- There is a Makefile, but it depends on old versions and doesn't say so. The new versions don't work. (samtools v1.0 changed the API and there's a ton of software (BioDB::Sam) out there that assumes a pre-v1.0 API, so you have to override the system-wide installation, great "fun" if you're on a cluster where each node has its own environment and you have no root)

- the software depends on other research software that doesn't exist anymore (google-fu to find a forgotten dusty tar.gz somewhere)

- It's a binary, but it gives you empty output if you have a typo in your flags (Just last week with Blast2Go: if you use "annot" instead of "-annot" it won't complain, you just get empty output)

- it depends on environment variables but it doesn't tell you so, it just crashes when it tries to run a dependency program using $PROGRAM_ROOT/bin/program (even better: MAKER doesn't crash, you just have one error line in about a million lines of STDOUT, chances are you don't realize that it had problems in the first place)

- program depends on loading data from disk using MySQL but MySQL wasn't compiled with local-infile=1

I'm sure I've wasted about half of my PhD's time finding out about highly program-specific problems that don't appear anywhere else. It has made me a somewhat proficient debugger but that is lifetime that I could have spent on analyzing actual results & writing papers, things that are actually helpful in my career.

Post reply on HN