Sometimes I think progress is defined as the reduction in the number of things we need to understand to accomplish any given task.
Helping my students overcome command-line bullshittery (2014)
71–80 of 168 posts
Re: Helping my students overcome command-line bullshittery (2014)
#72He 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…
Java (along with XCode) is unique in that there are nicely-packaged IDEs that let you do professional-level coding just by downloading one program.
My first professional experience was in Java. I worked for a year for a startup, working on 3-4 different programs and doing the entire UI for their product. After 2 days trying to compile things with Notepad, one of the other devs suggested "Go use JBuilder, we have a site license", and I never looked back. I didn't have to touch the command-line once. I would hit "Run program" and my program would run. I'd select "Add library JAR" by right-clicking on the project file and selecting the library. I could check out files from the VCS with the SourceSafe plugin just by right-clicking on a file and selecting a menu item.
Then I got to college, and, as some unpaid volunteer work, tried to rewrite a quickly-growing Harry Potter fansite as a database-backed PHP webapp. And in the course of getting that to work, I had to learn all these crazy UNIX commands. I had to learn about CVS (this was before Subversion and git) and how its command-line worked. I had to learn vi, because that's what I had to edit files on the server. I had to learn how to unpack tarballs. I had to learn ssh and scp because our server-admin guy was like "No way in hell am I opening up telnet on this box." I had to learn Apache configs and PHP.ini and all sorts of other magic incantations.
I'm really glad I learned them - my Linux & vim skills have actually aged better than my Java skills have, and I use vim & UNIX commands every day now. But damn, it was a lot of bullshit when I just wanted to get some text up on a website.
Re: Helping my students overcome command-line bullshittery (2014)
#73Earlier quoted context omitted.
The command-line is also an abstraction. I'm not anti-command line (for non-user stuff), but it irks me that we see the command line as some kind of god-given fundamental bloc, rather than just another abstraction that just happen to be at a level most programmers are happy with. I think the command line will persist as long as keyboards are the primary data entry tool, but nothing makes the command line inherently l…
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…
> I suppose you could invent a GUI that lets you click on the opcodes and memory addresses you want to execute but that's bordering on silly.
Makes me think of the Altair 8800 front panel...
Re: Helping my students overcome command-line bullshittery (2014)
#74Can'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…
In my similarly long experience, I have discovered that it's OK if the tools that you use nearly every day are "arcane", whether they have a GUI or not. Any time invested in getting to learn the tools will be paid back in efficiency later down the road.
As a simple example; an avid gimp user will not click through menus for most of the common actions, but will rather use keyboard shortcuts. It is no different for any CLI environment where you need to memorize a bunch of programs.
It certainly would be nice if your very first early start would focus more on the actual programming, and less on the weird abstract environment that most of us work in. But once you're hooked on programming, and that probably happens quite fast if you are into it, I find it hard to believe that you would not be willing to spend time to optimize your tool usage. The CLI does not get in your way there at all IMHO. The old unix philosophy of having a bunch of very simple tools that do one thing well and can be combined, is very useful in the day to day working environment.
Re: Helping my students overcome command-line bullshittery (2014)
#75Right or wrong, I usually start the year off by having the students install the OS on their lab workstations. It is a hassle, but I think it helps. Some people need more help than others, some hit the ground running having had prior experience. They'll install Python libs, various software packages, various types of software packages (from OS repo, Java, WINE, github, etc.) I try to cover the most common cases. They install Windows in a VM x2 (XP and Win7), and then install some flaky old Windows software that only likes to run in XP (PLC software), then they'll make the hardware work through the VM. Nearly everything we do could be done from the CL or from a GUI, but disseminating the instructions is accomplished most quickly using the command line.
Re: Helping my students overcome command-line bullshittery (2014)
#76I 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 have a small anecdote about this.
In the last couple of years I've had few people ask me 'how can I write a program with a GUI.' And I give the advice, 'Download the free version of Microsoft Visual Studio for C# and select new project, windows forms' and then start mucking around.
All of them were convinced by others to use qt and C++ All of them gave up after a week or two of no progress.
Re: Helping my students overcome command-line bullshittery (2014)
#77Honestly 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 p…
I think you have it backwards. Someone has pre-anticipated 99% of everything you will ever do with a computer, no matter who you are. And if you don't take the time to learn the things that let you do these things in one minute flat each:
comm -13 foos-not-in-bar
awk 'BEGIN {while (getline 0) {sym[$1]=1}} ($2 in sym) {print $0}' sizes | sort -rn
join -v2 quux
zgrep -n " XYZ," /foo/bar.out.gz | awk '{print $0} END {print NR}'
./configure && make
Now, I'm not going to claim that the command line is the only way to do these things (except for the last one). SQL or Excel or probably REXX would work too. But take advantage of the massive body of software that's already out there that can solve the 99% of your problems you have in common with everybody else, so you can spend your time mostly on the 1% that is your research.
Re: Helping my students overcome command-line bullshittery (2014)
#78I 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?
Sort of. I taught middle-school students programming using Scratch (and a whiteboard) for three summers, and found that its interface of dragging and dropping blocks of code worked well for teaching programming fundamentals (conditionals, loops, functions, events, etc) without the hassle of a command-line.
Re: Helping my students overcome command-line bullshittery (2014)
#79This 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…
man pages are horrible.
I think git ( all version control, really ) would be conceptually easier to grasp with a visual representation.
Re: Helping my students overcome command-line bullshittery (2014)
#80He 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…
> before we could get into any Python I had to explain all kinds of things I took for granted ... It's possible to start writing Python without really knowing any of the things you list with an IDE like PyCharm -- which is probably a similar environment to the one they used for Java in "Computer Science."
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.