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

11–20 of 168 posts

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

#11

Post by kohanz »

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 and memorize a ton of (what are in the end useless) variations of syntax.

Please note I'm not saying anything is better in the Windows world; far from it. I'm more talking about the transition from GUI tools, where feeling your way around in the dark is much less daunting to the uninitiated, to the command line.

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

#12

Post by JackDanger »

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't supported by their department or industry community. Otherwise they'd have a shared script that they all maintain that turns a bare PC/Mac/*nix box into one that's capable of doing great work.

This happens with every single engineering team. Those who understand the tools wrap them up into something solid so new folks have a great experience on their first day.

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

#13

Post by ekidd »

If you want a mostly nice, mostly well-documented development toolchain, you can either:

1. Install some proprietary, GUI-based development tools and color inside the lines,

2. Figure out what toolchain you want your students to use, and package it up using apt or docker or whatever (and tell your students to get a VM if they're on a different OS), or

3. Give your students remote logins on shared computers.

Any of these will allow you to keep the "bullshittery" to a tolerable minimum, and get on with the subject of the course.

But in the long run, unfortunately, if you want to be a programmer, you've got to learn to manage your own tools. This might mean being able to figure out command-line "bullshittery", or it may mean knowing how to unit test ASP.NET REST controllers. Even in the days of MacOS 8, back when there was no command line, there were still plenty of unholy, mind-eating horrors hiding in the dev stack. (The Component Manager, for instance.) And let's not even talk about the complexities of the web stack.

You can choose your flavor of "bullshittery", but if you want to be halfway good at this job, you've eventually got learn how to deal with whatever tools you choose.

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

#14

Post by tptacek »

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.

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

#15

Post by delish »

I consider "programming" to be a religious journey:

* "You're on your own path" you get errors that the person next to you doesn't.

* "To learn is to invent; you must come to realizations by yourself" different solutions in stackexchange in 2012, '13, and '14 don't work for you.

* I don't have a cliche-quip for this, but if religion is how you find your complex relationship with the world, programming is how you find your complex relationship with computation. I emphasize "how" because its a process and a practice.

* It's mostly bullshit. Because we don't have physics-for-everything, we have religion. Because we don't have math-for-everything[0], we have programming. I'm speaking loosely and rhetorically.

* Related to the above, religion is a bunch of workarounds, like programming. This ecumenical counsel said such, but that ecumenical counsel revised it.

[0] In this instance, I'll define "programming" to be "mostly failed attempts at precise description." Math-for-everything would be "very precise descriptions."

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

#16

Post by analog31 »

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?

Invariably, unless it's a major software product with a lavish budget, the GUI based setup program is less intelligible than the command line, and is accompanied by instructions consisting of page after page of screen shots, "with circles and arrows, and a paragraph on the back of each one," to quote the balladeer. And when the next version of the OS comes out, or a new version changed the installation slightly, the instructions are invalid, but were too costly to update.

After years of that, "sudo apt-get install" was like a breath of fresh air.

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

#17

Post by etrain »

I'm a researcher in the same basic field, and I too am pretty good at this "bullshittery."

However, Philip trivializes the "10,000 hours" spent learning this stuff as merely learning how to cope with this interface. This is so far off it hurts. Those countless hours spent messing with free software is how I learned to use other people's work, compile it, read it, fix bugs in it, and learn how other people think and write software. This is an incredibly important educational experience and there's sometimes no substitute for time and patience.

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

#18

Post by wfo »

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 programming or creating new things you have to understand how things actually work. I'm sorry if that means you need to know that python on OSX is different from python on Windows but you do.

If you are doing research by definition your needs can never be anticipated so you will never have pretty GUI tools to satisfy your needs. So I know the command line sucks for most people but if you want to do real work you're going to have to learn how to use it since it drops all of the leaky abstractions that prevent you from doing what you need to do when you're doing something novel.

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

#20

Post by analog31 »

ekidd wrote: post #13

If you want a mostly nice, mostly well-documented development toolchain, you can either: 1. Install some proprietary, GUI-based development tools and color inside the lines, 2. Figure out what toolchain you want your students to use, and package it up using apt or docker or whatever (and tell your students to get a VM if they're on a different OS), or 3. Give your students remote logins on shared computers. Any of th…

The Python crowd has worked out what I think is a decent compromise, which is to create some packaged installers that are good enough for most of us. I use WinPython. I don't know what it would take to do something like that for other languages.
Post reply on HN