Live data from Hacker News

One month command line challenge

blog.expertinamonth.com

21–30 of 48 posts

Re: One month command line challenge

#21
post #9

Earlier quoted context omitted.

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…

> 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…

>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

Re: One month command line challenge

#22
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.

Re: One month command line challenge

#23
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.

Re: One month command line challenge

#24
post #7

>Many candidates will immediately start writing a program in Java or Python, if they get it right, then they will start optimizing the algorithm > 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 a…

> 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.

Re: One month command line challenge

#25
post #3

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

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.

Re: One month command line challenge

#26
post #21

Earlier quoted context omitted.

> 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…

>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.

Re: One month command line challenge

#27
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.

Re: One month command line challenge

#28
post #27

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 no…

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.

Re: One month command line challenge

#29
post #27

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 no…

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.

Re: One month command line challenge

#30
post #28
post #27

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 no…

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

Post reply on HN