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

111–120 of 168 posts

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

#111

Post by ddingus »

zem wrote: post #10
hspak wrote: 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?

If you argue that supporting the GUI is an undue burden, you're merely shifting that burden onto everyone who has to perform the same steps manually every single time. Automating or away may be more up front work, but it only needs to be done once.

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.

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

#112

Post by dexiwz »

ocschwar wrote: post #101
dexiwz wrote: post #89

Earlier quoted context omitted.

The 'bullshit' he is referring to is not the software itself, but its arcane interface. Think about the first time you tried to install a new version of python, only to have both version end up in your PATH somehow. Or run into permission issues and someone told you to run 'chmod 777.' As a novice, hours are easily lost trying to find the perfect commands to do something, and it often ends up being only one or two li…

If you want to do research into something interesting and worthwhile, you can't expect to just have a fully fleshed out programming environment with no rough edges to deal with. To use an analogy, you're walking behind the guys who cut the trail for you with machetes. You don't get a blacktop highway to where you're going.

Turns out a machete is much easier to use than the machine that is Unix. A machine that will mow down the entire forest in 30 seconds, or blow itself up, depending on what you tell it. Oh, and that machine has 1014 levers, knobs, dials, most of which are only labeled with single letters, or vague snippets.

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

#113

Post by nostrademons »

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…

IIRC Docker on a Mac requires a virtual machine, right? If you're going to use a virtual machine for ordinary development, why not ship around a VM image that has everything pre-installed and ready to go?

(This is actually a very sane way of doing development...for much of 2002-2008 I did my development inside a Linux virtual machine running on VMWare Workstation, because my normal laptop was Windows. Macs have spoiled us; since they are POSIX-compatible, we've gotten used to running our dev environment directly on the box. But if you're having trouble configuring everything, it may be worth re-examining the VM solution, because you get much better isolation and many fewer configuration bugs than Docker.)

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

#114

Post by andrewchambers »

Rob Pike already pointed out the growing complexity of our systems - http://harmful.cat-v.org/cat-v/unix_prog_design.pdf

This is all incidental complexity caused by people adding dependencies and options without caring about the cognitive overload they introduce.

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

#116

Post by hackaflocka »

Command line bullshittery is the greatest source of job security to coders. If it all became too easy to do (not saying that's possible), it would make a lot of us less employable. This situation is an inversion of what Upton Sinclair said: "It is difficult to get a man to understand something, when his salary depends upon his not understanding it!"

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

#118

Post by MBlume »

I think this is poorly written. I don't object to him calling it "command-line bullshittery" in his title, but doing it over and over again in the article is excessive. We get it. You don't like it. You aren't going to convince us not to like it by naming it with the same obscenity 500 times.

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

#119

Post by orionblastar »

tptacek wrote: post #14
ams6110 wrote: post #2

If students can't deal with the bullshittery on the command line, how do they hope to deal with the even deeper bullshittery found in the libraries of most programming frameworks?

He's not suggesting that they can't. He's suggesting that doing so is an obstacle to doing research (it clearly is) and that the obstacle isn't intrinsic to the research process itself.

They should add a class to take before his class called Intro to POSIX 101 on how to use a Unix-type system and the command line options.

My 16 year old son taught himself how to program in order to mod his own video games. I wanted to teach him, but he figured it out from Youtube Videos and Google searches. He had to learn how command line switches worked, etc in order to use free and open source programming tools.

I learned Unix at a university in 1986 as part of a computer science class. I got into Linux in 1995 using Slackware on a 486DX clone. I remember a time before the GUI was used where everything was command line based in DOS and writing batch files to do things. Nobody taught me how to do that, I sort of learned it from trial and error. A lot of my DOS programming classes I had to use command line switches to compile my programs and edit text files with a Word Processor or the edit.com in DOS 5.0 or something. Things sure have changed now with IDEs and source code editors that highlight syntax in color. I learned HTML using Windows Notepad to make HTML text files. Things would have been easier if there was a class on this stuff that was required before taking the classes that needed it.

I worked in a computer lab in 1990-1994 at a college and taught the command line options to students just learning how to program.

When I learned Visual BASIC, everything was GUI based and it even generated forms I could paint controls on. It changed the way programming worked for me.

But free and open source tools are still command line based, and someone has to train the students how to use them. I sort of wish I still worked in a computer lab and training students, but those days are gone.

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

#120

Post by [deleted] »

ocschwar wrote: post #101
dexiwz wrote: post #89

Earlier quoted context omitted.

The 'bullshit' he is referring to is not the software itself, but its arcane interface. Think about the first time you tried to install a new version of python, only to have both version end up in your PATH somehow. Or run into permission issues and someone told you to run 'chmod 777.' As a novice, hours are easily lost trying to find the perfect commands to do something, and it often ends up being only one or two li…

If you want to do research into something interesting and worthwhile, you can't expect to just have a fully fleshed out programming environment with no rough edges to deal with. To use an analogy, you're walking behind the guys who cut the trail for you with machetes. You don't get a blacktop highway to where you're going.

[deleted]
Post reply on HN