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

131–140 of 168 posts

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

#131

Post by gozo »

tmptmp wrote: post #125
nostrademons wrote: post #108

Earlier quoted context omitted.

I'm curious - what's your motivation for being interested in tech? Have you given some thought about what drives you? I've found, personally, that my motivation has changed fairly dramatically over the years, and with it, my perspective on high-level vs. low-level programming. When I was in high school and college, my motivation was that I wanted to feel competent - I wanted a skill that was all my own, that I could…

>The people who make the most (founding CEOs) often have the wimpiest coding skills of all. What makes for a status hierarchy where the closer to the machine you are, the higher the status? Continuing your analogy a bit further, we can say that many politicians (dictators) make much much more than most founding CEOs and they have the wimpiest of wimpiest coding skills of all! I mean, we must not confuse between the a…

You might want to read up on Tesla ;)

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

#132

Post by distrill »

gozo wrote: post #80
iak8god wrote: post #63

Earlier quoted context omitted.

> 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."

It still too tricky to do things that make people, that don't know much about computers, excited about programming. Things like the C64, DOS or Qbasic were much "simpler" and of course the expectations were already lower. I would recommend something like Scratch or Processing instead.

Admittedly I didn't cut my teeth with C64 or DOS, but I have to imagine that it was only simpler because the barrier to entry was so much higher for those machines than it is today. And I would argue that expectations were higher in the past. Looking through some older 'entry level' computer science textbooks recently, I've been amazed at how complicated the material is and how quickly it covers things that we've only begun discussing as I'm about to graduate.

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

#133

Post by ddingus »

zem wrote: post #123
ddingus wrote: post #111

Earlier quoted context omitted.

Until it needs to be done again. Things change. It's a balance between the pay off and the ongoing investment to maintain the automation.

right, but it needs to be done again by the single person maintaining the automation tools, who presumably is more of the "programmer" than "user" inclination. everyone else in the lab benefits.

And who is that exactly?

For long established, regularly used tools, there is a case for funding this activity somehow.

For the many specialized tools? I'm not sure how this would actually happen, unless the person who creates it decides to maintain it. When their career focus doesn't value that tool, we can't really expect anything.

Worse, let's say some established systems exist. They have a barrier to entry in that new software needs to be compliant and potentially integrated on some level. People already are focused away from this stuff. Raising that bar means fewer overall contributions.

Now, it's often: I wrote this. It's open. You can use it.

And they move on.

If, suddenly, I wrote this, and it's open gets followed up by, "you need to make sure this works with all this other stuff..." what happens?

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

#134

Post by marvy »

tedunangst wrote: post #56
tptacek wrote: post #37

Earlier quoted context omitted.

Think about it this way: in 1995, you'd have spent those 10,000 hours reading other people's C code, reading the same dumb hash table or linked list implemented 400 different ways, the same goofy 4-5 line loops implementing "split" with strtok() over and over. But you don't anymore, because most research isn't done using C. In 1995 you'd have said "learning to understand what a strtok string split routine looks like…

> whatever it is strcspn does. It deletes the new line from the end of the string that fgets() insists on including, even though nobody anywhere has ever wanted it. :)

Don't write things like that, people might believe you. That is not at all what it does.

http://www.cplusplus.com/reference/cstring/strcspn/

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

#135

Post by ww520 »

Even after dealing with command line commands for many years, I don't remember most of the gory detail of them. That's why I keep a note file saving all the common and interesting command line commands I encountered. This has enabled me to "forget" (offload) most of these bullshittery and concentrate on the real problem at hand.

The note file is just a Emacs org file with different sections for different topics.

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

#136

Post by stevebmark »

kragen wrote: post #85
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` do? Do you think you would ever discover that combination on your own from reading the man pages? Is this some kind of sad joke? Of course. The tar man page is 8 pages long. You can read it in its entirety in ten minutes. I agree that it's far from ideal, since you ought to be able to figure out how to use a command immediately instead of after thirty minutes of rer…

>What is wrong with you?

Do you want the list or the summary?

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

#137

Post by stevebmark »

pdkl95 wrote: post #97
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. > b…

I have written many arguably complicated shell scripts. It is almost always a painful experience that involves things that are hard to look up because of terse and confusing syntax. There are plenty of examples. Dealing with executing commands with nested quotes (double and single) with file names with spaces, doing anything with arrays, [] vs [[]], the rules of subshells, loop syntax when dealing with space delimiter vs line break delimiter, the lengthy list of -flag if[[]] conditions, comparing strings to variables... when I say "design failure" it's completely from personal experience and frustration from trying to do simple tasks in bash and hitting confusing syntax wall after wall. I hope you are saying

>"one of the best languages I've ever used"

in an argumentative sense and not sincerely! Bash is obviously not capable of many things and seems limiting to choose as a favorite (main go to?) language.

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

#138

Post by stevebmark »

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.

Git documentation is especially bad. The book "Pro Git" does a decent job of covering the need-to-knows in an approachable way.

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

#139

Post by benzesandbetter »

There are plenty of installers and tools (e.g. brew, apt, yum) available to reduce this "command-line bullshittery" of which you speak. Of course, finding and using them may require some "search engine bullshittery" ;)

Being able to navigate this "command-line bullshittery" is one of the basic filters for people in the software development and CS research fields. Personally, I've hired people with CS degrees who could barely do basic operations in the shell. I'm often the person on a software team, who is coaching the less-skilled members on getting their environments and tools set up.

Rather than reduce these friction points, I think we need to encourage a culture where people learn to solve their own problems, or at least read the docs and try to do a bit more before thowing up their hands and asking for someone else to solve their problem.

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

#140

Post by loonattic »

balls187 wrote: post #67
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…

`z' means to use gzip compression when extracting or creating a tarball. `J' means xz, `j' bzip2.

For example, to create an xz-compressed tar file:

tar cJvf archive.tar.xz some_directory/

Generally, you can omit those when uncompressing, at least with GNU tar.

OpenBSD's tar is less friendly - it doesn't seem to try to autodetect the compression format. Last time I checked, it didn't support xz either. One had to install the package and then do something such as tar cf - directory/ | xz > something.txz

where the - means that the tarball is written to standard output. /dev/stdout would work as well.

Post reply on HN