> and in most cases programmers who are comfortable with the command line version are also the ones who are better at writing code
These two statements indicate to me that you are ineffective at communicating what skills you are looking for in a programmer.
The reason they are coding a sorting algorithm is that you're interviewing a programmer for a programming position. The assumption is that they are being tested on the knowledge in that domain, which includes sorting algorithms.
If I answered the exact same question by putting the file lines in a data structure and calling Sort() in someone else's interview, I might be thrown out for not giving them the actual algorithm that Sort() implements.
Or maybe you just want people calling system()/exec()/execvp() or whatever. I dunno.
A reasonable interviewer could just say "Alright, now can you do it without using the standard library?".
Best of both worlds answer for that kind of question: "In any real program, I'd normally call the standard library implementation, unless there's something wrong with it or profiling suggests that it's a bottleneck. Are you looking for how that library function would be implemented?"
That shows that you know the right real-world answer, but that you're also prepared to explain how that function works as part of the interview. The interviewer could then choose to have you write out the algorithm, or alternatively they could ask questions like "why might the standard implementation be a bottleneck?", which leads in interesting directions as well.
The question also doesn't talk about platform. Windows doesn't have the GNU suite (or BSD for that matter) by default. On the other hand, if we start programming in a language, there is at least the assumption that the language is installed and configured on said system.
Its just that I appreciate programmers who think of simpler solutions first.
He explained his solution in which he spent considerable time writing a C++ program to do this - iirc it even wrote the unique entries to a db. He seemed stunned when I explained that he could have achieved this easily with something like `sort -u a.txt b.txt > sorted.txt`. Sorted! To be fair he was inexperienced, but there is a lot of power in the command line that some developers don't seem to be aware of at all.
In other cases, some developers who do know will still grab to the new and shiny solution every time. The simplest solution is usually good enough, and the most maintainable (if that's a concern).
Ted Dziuba's 'Taco Bell Programming' nails this perspective pretty well. I'm sure it has been posted on HN many times already:
http://widgetsandshit.com/teddziuba/2010/10/taco-bell-progra...
You should probably reword your question and give a hint that a candidate can use any available tool. If it's a programming interview my first instinct would be writing a code, if it's a sysadm interview I would use available tools in the system.Context is important...
So in this case, I think if a candidate then asks something like "Are you expecting a solution in code, or can I use command line tools like grep, sort etc?" it shows something about them.
The goal is never to see if a candidate can produce a specific program, but to watch them reason and explain that reasoning.
I needed to get some work done on a remote machine. I didn't have time to download and re-install graphics drivers so I just soldiered. GNU Screen, elinks, vim, ssh, rsync, irssi, et al. I was amazed how much distraction free actual programming I could do. On an aesthetic full-screen bash console, no less. Was even have tempted to setup Gmail in pine.
Until I needed a browser to test a layout. Finally, I had reached the limits of CLI. Believing I could merely surf to amd.com, download the appropriate tarball (linux x64 supported), unpack install reboot and rejoin modern civ.
Fired up elinks, went to amd.com and was properly re-buffed. There was a javascript "system detection" routine that could not be bypassed to navigate directly to the download urls!
In the end, apt saved the day. Moral of the story: always test your http works in elinks, please ;)
Although, I do actually totally agree that the more a person knows about the CLI in general, the better they sometimes appear to be. I feel like learning to use command line tools also sort of inspires that general DRY attitude about software in general. Don't reinvent the wheel!
(I probably agree with you more than I disagree, and I'd rate "can read a man page" more important than "remembers -n for sort", I just thought the particular objection somewhat humorous)
"You have a file on your computer with 100,000 unsorted numbers, each number on a new line, Sort them and write the output into a new file.
"Many candidates will immediately start writing a program in Java or Python, if they get it right, then they will start optimizing the algorithm, some of them even start talking about big data and how they need Hadoop to solve the problem.
"I am looking for the candidate who can give me this simple command line solution [...]"
I live at the command line. I spent a year at a gig maintaining 90k lines of bash. And yet I think I stand a substantial chance of failing this test.
Not because I am incapable of trivially producing the line in question (even without recourse to the manual). But because interviewers usually aren't looking for "I would run the code someone else wrote to solve your problem". Of course, in practice, reusing code is great - and that should be the answer where it's applicable! But in an interview asking for a solution to a problem where existing code cannot be the bulk of the solution is likely to be too big a question.
Generally, programmers who are afraid of the command line aren't very good at putting textual commands into a program text file, either.
They will cling for dear life to code generators and other such facilities in an IDE. (but not the good kind of code generators that define an original source DSL to be expanded into otherwise unseen code by the build process itself, always the IDE based code generators that generate mountains of crap code that now must be read and saved in source control)
They will cling to rigid, bloated, frameworks that require that they fill in parameters in an XML file, and write (many, scattered) tiny pieces of code to fill in the blanks for that framework, but which allow little variation from the application style which the framework mandates.
Beware the illiterate, programmer, grunting at cave paintings on the wall (clicking pictures on the screen, only).
See also: Pragmatic Programmers - power of text/shells sections; Neil Stephenson - "In the Beginning was the Command Line" essay.
I do believe that a programmer ignoring the CLI would not go far, it's not a MUST know it is a HAVE TO know.
First it is about tooling, you will unlikely use a programming language that does not work first on the command-line: the compiler(s), even for non-compiled languages like JS things like grunt, gulp, closure, etc. are part of what you have to know to be efficient.
But most importantly it is about the Unix tools philosophy, the classic "do one thing, and do it well", when you do know how those different tools are unique independently but can also connect (pipe) with each others it helps tremendously to write better code in general.
Last but not least, every single languages we take for granted now (like PHP, Python, Ruby, etc.) have all started with the CLI and with CGI, the basic abstraction of standard I/O (as in stdin, stdout) is the root of many many more complex problems.
I don't see how a programmer could have a deep understanding of HTTP for example if he/she does not grasp the CLI first, sure you may not need it all the time or to know it that deep but really knowing the details of the CLI is a bit like knowing a bit of "assembler", it is a layer of tech you really HAVE TO know to become really really good opposed as to just know enough to write some code and make it works.
Now to test it like that in an interview I would go more blunt about it "do you know the CLI, give me examples how you use it (or which tools) in different daily programming tasks?", anything CLI-related that shows knowledge of the operating system, of the compilers or other programming tools, of automating tasks, etc. is imho a sign of a damn good developper, any lack of it is probably a sign that you are either a junior dev (didn't discovered the CLI yet) and certainly not senior (can't be if you don't know the CLI).
I'm not going to take the challenge as I have the opposite problem. Since I wrote software for 20 years before I had a GUI, I find myself using the CLI too much in certain cases. I've been trying to learn more of the hot-keys for the windowed tools that I do use ... and how to do some of my CLI tasks in a windowed environment.
One curious note: I could live with 8.3 file names (since I did for years) but I ditched Mac OSX because I couldn't tolerate it being case-insensitive.
The example in your article was great (sort) - what other tools can't you live without on the CLI? Here are a few of my favorites:
- unique - sed - grep - wc
Nowadays I have a half-decent machine but I still keep resource usage low where possible. The only 'GUI' application I use on a regular basis is the web browser. Media is handled by cmus/mpv.
Widescreen monitors make it easy to have a permanent tmux sidebar. So 20-30% of the screen is made up of terminals at all times, the rest can be a web browser/IDE. Or, three panes side by side with terminals at left, vim at centre, firefox at right.
I find it cathartic. It's also really easy to knock together scripts and run them with watch. For example I have one that shows me clockspeeds, battery life, uptime, etc and takes up 2 lines on the screen.
I also find hotkey based navigation easier than futzing around with the mouse - goes doubly when i'm working mobile on a laptop.
also contrast the submission with this post: http://pgbovine.net/command-line-bullshittery.htm
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.
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?
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 :-)
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.
If you know the name of the command you need, read the man page. If you don't, search for the man page using apropos. If you don't know how to use apropos, read its man page.
Although, forgoing the web browser might do more for your productivity than anything else...
/me closes HN
Maybe because one does not need to change the way he/she is interacting with machine?
Even if you never have to step outside of Windows, you might still benefit from learning Powershell, simply because it allows for a surprising amount of automation of routine workflows.
Onemonth.com is in a very similar space and the conflicting names will likely hurt you.
It stimulate creativity like nothing else.
I literally expect to see people like this writing about how they're experimenting with punch card input any day now.
