Live data from Hacker News

Helping my students overcome command-line bullshittery (2014)

pgbovine.net

31–40 of 168 posts

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

#31

I think it is ineffective to only focus on command line "bullshittery" and not discuss API bullshittery. I think the problem of learning commands pales to the problem of learning poorly-designed APIs. One extreme example of this is the Windows Event Tracing API [1], but there are many more along the same vein. [1] http://mollyrocket.com/casey/stream_0029.html

The two problems are sort of equivalent when you realize that the shell is just a REPL to your OS, and commands you type are, generally, API calls.

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

#32
That we still revolve around static, line-based interpreters from the VT100 era (over more intelligent CLIs or hybrid UIs like Oberon) is indeed rather quaint, and the proliferation of underdesigned programming tools also, but I strongly disagree with the author's claim that all these Unix programs are "[bullshit] not intellectually interesting in any way". Perhaps I'm one of the few people who actually likes to read the source code to the nodes in their /var/log/packages, but potentially getting involved with userspace system programming is not to be dismissed.

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

#33
post #17

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

He's not trivializing anything, he's merely expressing a rather obvious (and frankly sophomoric) statement - software can be made more user friendly. And making software more user friendly actually isn't that hard. What is hard is to figure out which software to make more user friendly (given finite resources). That is a very very challenging problem.. and what's more is a sign of your intellectual worth in solving it.

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

#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 them, why there is vi, vim and emacs, etc, etc. All in all it's many many hours of explanation of the environment which you need to understand before you can do any programming. We spent a couple of weeks on this stuff, got to some basic Python and then the summer was over :(

It's especially curious that one of these kids took a class in high school called "Computer Science" and they were using Java as the learning language. Somehow they managed to write programs that performed cool animations without knowing what the command line is.

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

#35
Yes, and algebra is the "command-line bullshitery" of doing physics.

I struggled for many years over this (my username is an in-joke with myself). There's basically two days a month that i can actually comprehend algebra, the rest of the time those little symbols merge and splurge themselves across the page until i'm dizzy.

The beginnings of a breakthrough happened when I started writing a program (algorithm) for every bit of algebra I couldn't understand. Now I am starting to see that the equals sign is just not for me. I think in processes, not static equalities. And indeed, there is a whole branch of mathematics with this philosophy: category theory.

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

#36
post #7

If you read this, definitely follow up by reading the (more recent) response: https://medium.com/@eytanadar/on-the-value-of-command-line-b...

This follow up article is definitely worth reading. But just to put things in perspective, I got my degree in physics, and I overcame bullshitteries in programming, plumbing, machining, electronics, mechanics, bike repair, and so forth.

I think that part of the value, if not the major part, is that at the PhD level, you're given a problem that is ill defined, that your advisor doesn't know how to solve, and whose solution doesn't necessarily come entirely from within your field. Though I was a physics student, solving my thesis problem required developing skills beyond my advisor's own expertise, in areas such as electronics and programming. I had to invent a solution that he had not imagined. It helped a lot that those things were also my hobbies.

Which brings us to this reality. One day, and I pretty much guarantee it will happen, your student will download something from the Web and they will get stuck.

You don't know stuck until it's actually on fire. ;-)

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

#37
post #17

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

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 is learning how other people think and write software". And you'd have been right. But you would also have been describing bullshittery that we are all glad not to have to deal with anymore.

That's the overall feeling I get from this piece: there is more bullshittery to eliminate than the 400 different versions of "xmalloc" that we had to deal with in 1995.

Also: that because understanding how to iterate over the tokens of a colon-delimited string with strtok() isn't actually intrinsic to much computer science research, it's very important that we don't judge aptitude or capability by how conversant people are with strtok, or whatever it is strcspn does.

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

#38
post #17

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

I'm also a researcher in the same basic field but not that good at this "bullshittery".

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

#39
post #25

Earlier quoted context omitted.

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…

You can get anything you want with Make and Make Install.

[deleted]

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

#40
post #38
post #17

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

I'm also a researcher in the same basic field but not that good at this "bullshittery".

[deleted]
Post reply on HN