One month command line challenge(blog.expertinamonth.com)
blog.expertinamonth.com
One month command line challenge
http://blog.expertinamonth.com/post/110437403117/learning-to-love-the-command-line
18 comments
Heh, I got rejected once, a long time ago, for almost exactly this. I was asked to whiteboard a C function to convert an ascii character to an integer, and I wrote one that just returned the result of atoi(). I thought it showed knowledge of the best way to get the job done, but I guess they disagreed.
How does a rejection like that work in practice? Was that the question the interview hinged on?
A reasonable interviewer could just say "Alright, now can you do it without using the standard library?".
A reasonable interviewer could just say "Alright, now can you do it without using the standard library?".
I should be clearer. They didn't specifically reject me for that. There was just a sense that the interview wasn't going well from that point forward. They may just have felt that their request was clear and my response was smart-assed, and in truth that is probably fair.
> 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.
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.
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.
Came here to say exactly this. When someone asks you to "transform this data" in a programming interview, then you assume it's to test your programming skills, so you start to showcase them.
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.
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.
Hi OP here, I am sorry! I should have added more context to the post. I have never rejected candidates solely on this basis.
Its just that I appreciate programmers who think of simpler solutions first.
Its just that I appreciate programmers who think of simpler solutions first.
I can appreciate this also. Your `sort` question reminds me of an interview where I asked the candidate to give me an example of where he used his general coding knowledge to solve a problem. He told me how he had two long lists of email addresses with duplicates that he needed to sort and merge into one unique list.
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...
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...
Have you asked them why they are started to writing a code in first place? Maybe, since it's a programming interview, they thought you are trying to measure their theoretical knowledge than their practical day to day knowledge.
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...
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...
You definitely have a point, but parts of the expectations from candidates at an interview is to ask questions about the problem domain, the available solution space etc.
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.
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.
This should be a perfectly fine answer and any interviewer who knows what they're doing should be prepared to roll with it. (by, for instance, pointing at the Sort() function and asking how it works)
The goal is never to see if a candidate can produce a specific program, but to watch them reason and explain that reasoning.
The goal is never to see if a candidate can produce a specific program, but to watch them reason and explain that reasoning.
I was asked a variant of this sorting question (with the same expected answer) a while back. I think it's utter horseshit, just on principle that in 99% of cases the interviewer will be pissed at the answer "call the standard library's implementation that solves this problem". Why is this some exception?
I agree, it's really important to set the context for the question correctly so they don't think you are trying to ask them a question to showcase their programming abilities.
Once, Ubuntu Desktop issued an update that hosed my fglxr drivers.
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 ;)
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 ;)
I'm not sure how I feel about the sort question being a super simple "fizzbuzz" type command line question in an interview. The problem with some of the CLI stuff is that its really a simple yes/no "do you remember that command name" type thing. For something like grep that makes sense. But as somebody who also lives in the terminal, I have mixed feelings about expecting things like wc, sort, xargs, etc out of a potential candidate.
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!
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!
Yeah, "sort" is a super esoteric name...
(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)
(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)
Exactly my point, as I said before I have never rejected candidates based on whether they can answer the question, but it does add a point for those who can.
"I would ask the candidate a simple sounding question
"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.
"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.
WORD!
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.
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.
Good and sound advice but imho poorly illustrated.
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 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 agree that knowing the CLI (of whatever OS you use) is a good idea but ...
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.
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.
I'm curious why the case-insensitivity bothered you. Do you often write files that differ only in case? Since all of the shells' tab completion remains case-sensitive, many CLI-centric programmers don't even notice that OS X is case-insensitive.
Maybe you should take the "One month GUI challenge" :), I wrote this for folks who are just getting started I believe that once knlowing the CLI gives you some confidence about uour computer and sets you up for easier learning in the future.
A "one month GUI challenge" would be interesting ... I'm not sure I could do it though. Would we exclude interactions with remote servers? If I use a GUI editor to create Ansible playbooks that are run against a server farm, that feels a bit like cheating.
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
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
I usually get a lot of this, can you find me number of x from this file and y that DB table for December .
I find myself using 'join' a lot.
I find myself using 'join' a lot.
I have used CLI based interfaces with fluxbox and urxvt wherever possible for a long time now. It started when I found myself with only a laptop with low resources.
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.
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.
but that isn't the command line, that's unix... windows has its own sort utility but the flags are different...
also contrast the submission with this post: http://pgbovine.net/command-line-bullshittery.htm
also contrast the submission with this post: http://pgbovine.net/command-line-bullshittery.htm
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.
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?
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
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).
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).
This is the reason I used the qualifier "hardly". Unfortunately I quite a few Java developers who can't cd their way out of their home directory.
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 :-)
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.
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.
Meh. It's useful, but the "no true scotsman" argument is just wrong. Coding solutions is usually better in the long-term. It's why Perl was invented. Command-line is all about learning thousands of arcane details that anyone can just google the answer to.
I tend to agree. There have been approximately zero times I've been given a file with 100,000 numbers that needed to be sorted. Similar tasks are honestly rare enough that my intermediate command line skill has gotten me by just fine. Every once in a while a complex task pops up but I just google it and figure it out fairly quickly.
"If you don’t know how to do a certain task with the command line, you can look up the man pages or look it up online."
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.
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.
"Of course, you can use your browser and media player etc, but for all other tasks such are writing and editing files, copying files, launching programs etc, you must use the CLI exclusively."
Although, forgoing the web browser might do more for your productivity than anything else...
/me closes HN
Although, forgoing the web browser might do more for your productivity than anything else...
/me closes HN
> After one month, you will be surprised at how inferior and cumbersome the graphical interface seems compared to the command line.
Maybe because one does not need to change the way he/she is interacting with machine?
Maybe because one does not need to change the way he/she is interacting with machine?
Depends on your goals. If you're ever asked to debug a problem on a remote Linux machine with no X, you'll be lost if all you know is the GUI.
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.
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.
You may want to consider a new name, especially since you just registered this one in Jan.
Onemonth.com is in a very similar space and the conflicting names will likely hurt you.
Onemonth.com is in a very similar space and the conflicting names will likely hurt you.
Reminds me a bit of "Learn X in 21 days" - but then, the way we learn might got more effective.
It is always a good exercise to try to accomplish more with less.
It stimulate creativity like nothing else.
It stimulate creativity like nothing else.
This is the perfect example of the whole hipster culture making it's way into web and software development.
I literally expect to see people like this writing about how they're experimenting with punch card input any day now.
I literally expect to see people like this writing about how they're experimenting with punch card input any day now.
What exactly is hipster culture in this context? The challenge seems like a good way for some people to learn something new. If you are familiar with the UNIX tools you can solve some problems faster than without them.
precisely. any good ide has an embedded console/shell interface anyway. falling back to the command line is necessary/useful occasionally. but abstaining from visual interfaces for a month seems pointless.
> 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.