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

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

#141

Post by loonattic » Tue, Nov 03, 2015, 5:45 AM UTC

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…

Honestly, I think build system complexity and breakage, and library/dependency/versioning hell is a much bigger problem than just learning how to use tar. The number of times I've had autoconf configure scripts whine about not being able to find some library when it is installed for whatever reason...

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

#142

Post by copperx » Tue, Nov 03, 2015, 5:47 AM UTC

chubot wrote: post #130

kohanz wrote: post #11

I actually love the term he used. I started my programming in the Windows world and wasn't exposed to POSIX command line stuff until later. I'm comfortable with it nowadays, yet I know exactly what he's talking about with the 'wall'. To me, the 'bullshittery' would mean the inconsistency of it all. There's no standard for command-line tools, so they all tend to be slightly different. The end result is having to learn…

Yeah but the shell actually provides a mechanism that allows you to FORGET all the bullshit -- functions. I look up commands on the Internet, and then put them into single line shell script functions with a name. And then I write a comment about how it works, and check it into a git repo. Then I never have to remember the exact invocation. I just type my nice function name, which is consistently named, and describes…

I find it depressing that after decades of working in the command line, this never occurred to me.

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

#143

Post by lowlevel » Tue, Nov 03, 2015, 5:53 AM UTC

I have trouble taking this complaint seriously. If the platform's interface paradigm is such a hinderance just sheild them from it as much as possible by providing pre-configured environments or use a different platform. There is tremendous value in knowing how the command line work, how the systems work and how they are configured whether you are talking about Unix, Windows, AS/400 or whatever. If you skip this, you are likely to be eaten by a grue.

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

#144

Post by [deleted] » Tue, Nov 03, 2015, 5:53 AM UTC

[deleted]

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

#145

Post by vacri » Tue, Nov 03, 2015, 6:06 AM UTC

dexiwz wrote: post #96

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

You're talking about a mythical shop which already has all the tools - very few shops have them all. Similarly, there are plenty of physical tools which are not obvious to use; my housemate tinkers in the shed with wood and he's got a variety of tools, some of which I'm nonplussed in how to use. Plenty of the tools are hidden, whether 'hidden' is defined as 'not present' or 'unclear usage'.

Likewise methodology. As a carpenter you might wonder how to curve wood. You might even hear about steam being involved. But unless you're finding out from someone who's already done it, it's not that simple to just steam a bit of wood and usefully bend it from first principles.

Hell, even just using a chisel for a novice is easier if you talk to someone first - especially a metalworking chisel.

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

#146

Post by vacri » Tue, Nov 03, 2015, 6:26 AM UTC

tormeh wrote: post #104

wfo wrote: post #83

Earlier quoted context omitted.

Okay, a trivial and meaningless nitpick but a technically accurate one. Every general purpose computing machine that you can interact with and reprogram can be done by command line. Sometimes you have to plug another machine and use ITS command line to send communications to the original machine. I'll agree with you that microwaves do not have command line interfaces but calling them "computers" is quite a stretch.

No, it's not a meaningless nitpick! Yes, general purpose computers need to be programmed, but the reason we do it with a command line is because we prefer keyboards for data entry. When we stop using keyboards we will stop using command lines, just as we've stopped using punch cards. Everything that's not manually and physically setting voltages on memory is an abstraction. It's important to note that the command lin…

> Everything that's not manually and physically setting voltages on memory

If you're going to be that pedantic, then you should go all the way and note that there are computers that have neither memory nor use electricity.

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

#147

Post by vacri » Tue, Nov 03, 2015, 6:29 AM UTC

cdnsteve wrote: post #86

Docker is looking better and better... I recently decided to use Python 3.5 and Flask for a project. I didn't have time to learn them and Docker so I used a regular OS X setup. I thought the setup wasn't that bad until I had to share my setup with other team members... It took me 25 minutes to write up a wiki page on just the local environment setup. Pyenv, homebrew, pyenv-virtualenv switcher thing, setting python ve…

Docker doesn't 'magic' away the complexity. It just means that operational complexity is handled by fewer team members - the ones that handle the docker ecosystem and keep everything current.

And then on top of that, you have to train everyone using it in Docker bullshittery instead of commandline bullshittery.

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

#148

Post by vacri » Tue, Nov 03, 2015, 6:36 AM UTC

stevebmark wrote: post #137

pdkl95 wrote: post #97

Earlier quoted context omitted.

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

Shell is a 'glue' language, not a 'be' language. It's for gluing things together, not for being something in it's own right.

Though yes, it'd be a lot nicer if arrays in particular didn't suck so much in shell.

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

#149

Post by djbf » Tue, Nov 03, 2015, 6:58 AM UTC

distrill wrote: post #132

gozo wrote: post #80

Earlier quoted context omitted.

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

In those days, we also had magazines like Byte, Family Computing, Enter, etc. that included sections of type-in programs. My mom and I spent years doing that together!

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

#150

Post by netheril96 » Tue, Nov 03, 2015, 7:12 AM UTC

nostrademons wrote: post #108

p4wnc6 wrote: post #55

Earlier quoted context omitted.

I actually disagree with this. I came to computing from the reverse direction (I did theoretical math in grad school and then steadily needed to become better at programming as I needed it in industrial jobs). At first I thought a lot of stuff classified as 'bullshittery' and that with convenience tools like MATLAB, most of it was obsolete and taking time away from focusing on the supposedly more fundamental "real wo…

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…

> Frontend devs frequently make more than backend devs, and have many more job opportunities to choose from.

Out of curiosity, how true is this statement? I hear from my friends that most frontend devs start with higher salary, but have a hard time climbing the corporate ladder, especially if the frontend is not the core competency of the company. I wonder which one is a more accurate depiction of reality.