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

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

#81

Post by vox_mollis » Tue, Nov 03, 2015, 3:23 AM UTC

opnitro wrote: post #26

tormeh wrote: post #6

I like the same author's "The Two Cultures of Computing"[0]. It's somewhat in the same vein, and also really important. 0: http://www.pgbovine.net/two-cultures-of-computing.htm

I've always had people who wanted to learn programming become so bogged down in the tools around programming. It led me to thinking that it might be better to teach the fundamentals with pen/paper/whiteboard. To get the "this is why programming is important/powerful" message across. Anyone tried this/had any success with it?

I've always had people who wanted to learn programming become so bogged down in the tools around programming

Bogged down in an editor and a compiler?

When first starting out, there are two tools.

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

#82

Post by soyiuz » Tue, Nov 03, 2015, 3:24 AM UTC

I strongly disagree with the author's position. I think it betrays bias in favor of computer science as opposed to software engineering. The stereotypical computer scientist operates in a an abstracted world. The physical limitations of computing only stands in the way of perfection. The stereotypical software engineer delights in maintaining real-world systems. The imperfect messiness of the world---its onslaught on all things man-made presents a beautiful challenge in itself.

I'll give you an example. A colleague of mine was stuck debugging a fairly complicated piece of Python Pandas data sciency code. In trying to help him, I realized he does not understand the difference between absolute and relative paths. In fact, I don't think he understood what a file is.

Now, you can say such details are bullshit. Who needs to know about paths? They should just work. I want to do data science, not poke around some arcane legacy operating system standards. I am an artist and a mathematician, dang it! Yet the greatest generation of computer scientists and software engineers always did both. People like Donald Knuth and Brian Kernighan made their own "bullshit" which continues to run our machines. For me, to encounter that history is to understand the delicate compromise between theory and practice. To become a great architect, one cannot bypass gaining intimate knowledge of building materials.

We are lucky that our systems contain the trace of their history. We should study it closely, instead of calling it bullshit. Without that history, our students and our colleagues are bound to play with prefabricated toys, while the true polymaths write their own compilers and operating systems.

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

#83

Post by wfo » Tue, Nov 03, 2015, 3:24 AM UTC

tormeh wrote: post #66

wfo wrote: post #48

Earlier quoted context omitted.

The command line isn't an abstraction: a particular shell is, sure. Directly inputting machine instructions is a form of a command line. At its most basic the computer is executing an ordered sequence of commands and you need a way to tell it to execute the commands you wish. Machines run on a sequence of function-argument instructions -- this is fundamentally what the command line is. I suppose you could invent a GU…

>Every machine in existence has a command line interface. No they don't. Embedded computers do not have command lines, for example. Embedded computers don't give a shit about text. Most computers do not accept commands at all. As for those who do, some don't accept it in text form, for example gaming consoles or punch-card antiquities. Command lines are the consequence of keyboards, and whenever you see a computer on…

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.

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

#84

Post by dougdonohoe » Tue, Nov 03, 2015, 3:24 AM UTC

I prefer to live in both of these worlds.

For example, when necessary, I'll do git stuff on the command line, but far prefer to do it in IntelliJ - with side-by-side merge conflicting, it is much better than anything on the command line. Seriously - blame, history, branching, diffs, etc are far easier in a graphical UI.

On the other hand, sometimes you need to drop down into the command line when (a) s@&t hits the fan or (b) you need to do something unique or complex that the UI doesn't handle. It definitely is worthwhile knowing (or being able to learn) sed, awk, tar, find, scp, rsync, ssh, dd, df, grep, egrep, bash, mv, cd, ls, and [fill in your favorite] *nix commands.

In fact, I don't really understand how Windows developers do anything without installing cygwin.

Net-net, I think a good developer/engineer has the ability to read and grok a man page, but the wisdom to use a simpler UI or IDE when it gets the job done.

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

#85

Post by kragen » Tue, Nov 03, 2015, 3:26 AM UTC

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 rereading a man page over and over again, but "ever"? "Do you think you would ever discover that combination"? What is wrong with you?

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

#86

Post by cdnsteve » Tue, Nov 03, 2015, 3:27 AM UTC

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 version, setting environment variables... After reviewing the instructions and going through this with two team members, I am realizing more and more that this is a major barrier to jumping in and out of different technologies easily for teams.

We take for granted our environment setups, until you need to have someone else jump into what you're doing. After I get this shipped I'm going to circle back and get it up and running inside Docker. If the promise holds true, one or two commands and you should be up and running for any environment... we'll see.

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

#87

Post by anigbrowl » Tue, Nov 03, 2015, 3:28 AM UTC

Estragon wrote: post #47

anigbrowl wrote: post #21

Can't upvote this enough, and I urge people also to read his other article on this topic, as well as the rebuttal linked within. I got into computers in the early 1980s when built-in BASIC interpreters were considered Terribly Clever and graphics were something you got by loading/constructing an alternate character set to fit on the text grid. Like many others I stumbled onwards through Vax terminals and onto PCs, wh…

> Back around 1999 I was running Gnome and E.16 (or was it 15?) and I had a hugely customizable UI Why don't you keep using it? I'm still using sawfish.

Oh I still like E. What I mean is, I'm disappointed that UI experimentation and development on Linux seems to have stalled. I'm having trouble thinking of the last time I saw something that suprised/impressed me there, maybe Compiz?

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

#88

Post by acbart » Tue, Nov 03, 2015, 3:29 AM UTC

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

That's why it's nice to have online systems like my BlockPy [1], or Skulpt/Pythy/CodeMirror.

[1] http://blockpy.com

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

#89

Post by dexiwz » Tue, Nov 03, 2015, 3:31 AM UTC

ocschwar wrote: post #69

I really find this off-putting. The same things he labels as "bullshittery" are those things that meant when I got into CS, I didn't have to hold a soldering iron, enter the CHS triplet from a hard drive's label into the BIOS, or write code in an assembler. Other people's work, their "bullshittery" relieved me of a lot of tedious work that they DID do when it was their turn. What makes their stuff "bullshittery" is t…

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 lines, something an expert would know immediately.

His job as a mentor is to empower his students to do research, not be sysadmins. Selecting a student based on a pre existing ability to use a tool drastically limits the pool.

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

#90

Post by vox_mollis » Tue, Nov 03, 2015, 3:33 AM UTC

Shank wrote: post #54

rsync wrote: post #45

Frankly, I appreciate a good bottleneck that selects against people that can't grok basic unix admin and system maintenance. How many hours (thousands) and dollars (tens of thousands) have I wasted on "programmers" that don't even have a home server running in their closet... That's an interview question at rsync.net, btw. What computer(s) do you have (running) in your closet ? What computer is connected to your tele…

I think that's a poor interview question. You're bound to only get people who have a disposable income to throw a server in their closet, and certainly a computer attached to their TV. Maybe it'd be a better interview question to have them work on a project for a week, which requires using the command line, rather than asking this somewhat limited question set. I don't mean to tear into you -- I see the value in what…

It's not "silly filtering", it's pretty decent filtering, especially for what his business does.

I know that software and systems engineering has become wildly popular because of the money and Aaron Sorkin screenwriting, but it's good for hiring filters to select for those who have an internally driven interest in the subject.