I read the post you linked and I disagree with it because familiarity with the *nix command line is very useful for a developer working in industry. This guy sees it as a roadblock because he believes that the complicated nature of it will turn students away who would otherwise be good computer science researchers. This could be true. In any event, the post linked here seems aimed at people who want quick vocational education.
This is the difference between being a craftsman or being an academic. If you're a craftsman, you'd better know how to use your tools well. They're not an "obstacle" in the way of interesting research. They're a means to an end in accomplishing a goal.
At some point one should realize not every programmer is a computer scientist. Many of us are so much of computer scientists as a carpenter is an architect. For those of us who like to build things rapidly, familiarity with the posix shell and variants is a huge asset.
> familiarity with the nix command line is very useful for a developer working in industry.
Depends on the industry. Familiarity with the command line for a Java developer is hardly required. Familiarity with the nix command line for a C# developer is utterly useless. Ditto that for video game developers.
On the other hand, if you're writing for linux, then yes, knowing the *nix command line is going to be incredibly useful. That said, there's a lot to "know" - it is its own programming language after all. How much familiarity do you want them to have, and what tradeoffs are you willing to assume if they have that familiarity?
>Familiarity with the command line for a Java developer is hardly required.
You are assuming that developers would never require to grep app/db logs etc, I think in practice Java developers have to deal with the command line, I would partly agree with the C# bit
I'm a Java developer that touches the command line for something besides git almost every single day. Just because you're in a higher level language does not mean you don't need tooling or don't have repetitive tasks. I refuse to start a JVM just so I can do some arbitrary task.
It's also partly the case of "everything looks like a nail". I personally feel that we are problem solvers first, and "programmers" second. So using a tool is a perfectly valid way to solve a problem. In fact, it works towards one of our key programming tenets of "reusability".
As an interesting aside to that; I have recently worked with a very peculiar older developer (his age isn't related, btw). He lives, and breathes the entire Microsoft stack. Knows all the buzzwords, configs, arcane incantations, etc. Whatever problem he comes across, his first response is "write a C# program". He has riddled our source control with arbitrary little executables, sitting next to *.pdb and app.config files.
Luckily, he doesn't work on our backend which runs on AIX (and we haven't pioneered trying Mono on it, yet).
I've read that before. To be honest, it seems kind of whiny.
If what you are using is in a mature (not likely a field of research) domain, then yes, just click on install.exe and grunt (click) at [Next] once or twice, or on *nix go to Debian/Ubuntu style package manager and click on "install that" (and all its dependencies). BUT, if what you are doing is research that involves some newer tools, you might have to get a little bit dirty.
Maybe we can have a discussion about "dialog box bullshittery" (or registry bullshittery)? And how if you are stuck in that tar pit, there is no easy way out such as rolling up a tar of several packages which includes a top level "install.sh" script. You simply have to include the instructions of all the dialogs in a sequence and all the arcane buttons, checkboxes and radio buttons to be selected "just so", of you're SOL.
Yeah, cry me a river about the mean old command line.
There's some interesting comments in the "anti-forward" of the Unix Hater's Handbook suggesting that the "former prisoners" offer some commentary about the "facilities" to which they have been reassigned. ... "a system whose content and tone are set by Sonic the Hedgehog" indeed :-)
This is one of my favorite things about Racket: DrRacket itself is the language's killer app.
Why? Because if I want to program in Racket, I install DrRacket, and then I run it, and now I am programming in Racket. When I want to run my program, I click run.
The end.
Whereas with basically every other language out there there is indeed a whole wall of bullshit in between me and just writing some goddamn code.
First I have to install the language. If I'm on Linux, this probably means installing a package from my distro's package manager, unless of course I'm on Debian or something, in which case that's the last thing I want to do because it's probably out of date anyway, so I go hunting for an alternate package somewhere. If I'm on Windows, if I'm lucky there's a standard installer and it goes without a hitch, except almost none of them ever set the path properly so now I have to dive down into the environment variables to make sure cmd.exe can actually find my compiler when I need it.
Next, I need an editor, because of the contemporary languages present, virtually none of them actually include one, and the ones that do are usually terrible. So now I have to find an editor or IDE I can stand, then whatever plugin I need for it to properly recognize my language syntax, and there's a good chance the latter is only available for Emacs or Vim, neither of which are exactly a trivial learning curve.
So now I have my language, and I have my editor, and it's time to start coding, right? Oh my no. Turns out I've picked one of the increasingly common languages that basically requires you to set up a package or project file before you can even start writing the bloody thing, so now I'm diving into making sense of Leiningen syntax or hunting for and then configuring Visual Studio templates, just so I can doodle out a quick script.
And now, if I'm lucky, I finally start coding! But now I've done some coding, and I want to actually run my program (hope you got your path set right!), which means I need to know what arcane series of compiler flags I have to pass in just to get the damn thing to run a file, and if anything goes wrong there's always the chance that rather than being able to just click "stop" and halt the process, it will instead hang my entire system with a runaway thread because I typoed an if statement somewhere in one of my loops.
Compare all this to Racket: Download Racket, install Racket, run DrRacket from convenient shortcut or commandline, write code, run code. It's the first language since QBasic that's really got it right.
This is the difference between being a craftsman or being an academic. If you're a craftsman, you'd better know how to use your tools well. They're not an "obstacle" in the way of interesting research. They're a means to an end in accomplishing a goal.
At some point one should realize not every programmer is a computer scientist. Many of us are so much of computer scientists as a carpenter is an architect. For those of us who like to build things rapidly, familiarity with the posix shell and variants is a huge asset.