Hacker News Reader

Comment by l_t | Hacker News Reader

I like the "everything is text" mentality, but really, the "hard part" of the GNU/Linux CLI is getting things done when you don't already know how.

If you've memorized the hundreds of different invocation arguments for find, sed, grep, tr, sort, uniq, cat, xargs, etc. -- then yes, you can be very fast. If not -- be prepared to RTFM for about 4 different programs to get your job done.

That's an incredible hurdle and it really only makes sense if you are using these tools daily/weekly. I'm still not completely convinced that its "worth it" to master these tools, when general-purpose scripting languages are almost as succinct and obviously way more powerful. That's speaking as someone who's written a fair amount of Bash.

In contrast, I think tools with higher discoverability and self-documenting nature (arguably, Excel) usually offer a more user-friendly way of doing the same thing, unless you are doing it a lot.

View on HN

Yes, most of us would probably have to check the manpage for three or four of these utility programs to put together something like Rob McIlroy's one-liner from the article. I think this is clearly still more efficient than writing 17 pages worth of code in a general purpose language, which is what it's being pitted against. I also don't think it's really a very high hurdle -- if I were writing the same thing in a Python or Perl script I bet I would end up also consulting the documentation to check exactly how to do things or what some detail of syntax is. If you happen to write Python all day every day then sure, you'll find it much faster to just write a quick Python script for this sort of thing. If your day job is C or Java or some other non-scripting language and this is a once-a-month-or-so task then I think the time required to do this sort of small utility task in shell-and-utility-tools is not really any different to remembering how to write Perl scripts.

The 17 pages comment gets me. Literate programming is verbose by design. I'd be surprised if the Ruby version of that script was much longer than the command line version.

I do see what they're saying though. I've used Linux for the most part of 20 years. My primary job has hopped between Perl, Python, and a bunch of other languages, but bash/csh has been fairly consistent. I took a job using Windows for a year or two and tried really hard to get familiar and proficient in PowerShell. Since my job was primarily in Python, learning PowerShell had a steep learning curve with a lot of time between uses. I clung to Python. I jumped to WSL/Ubuntu (and honestly sshed into Linux vms before that) because I was so familiar with it. If I stayed at that job (or another Windows job) I probably would have eventually picked up PowerShell, but that would probably have taken 5 years.

And, it's also faster/easier to copy and paste a command from the internet than to download, install, and run a standard program. Probably not the most security-conscious thing, but it gets the job done.

Furthermore, it's often quite easy to slightly tweak a command I found online, even if I don't understand much of it.

As a Windows user (embedded programming and gaming keeps me stuck to Windows) who has dabbled a bit in Linux over the last 10 years, the fact that GNU/Linux "assumes you know what you're doing" is constantly frustrating. I've overcome this somewhat by stopping my current linux install from automatically starting the xwindow system. That way I have to use the terminal for some things. This has worked somewhat, but seems only to highlight how terrible interface is for those of us who aren't wizards.

I like to phrase it as "Linux assumes you know what you're doing. Windows assumes you don't know what you're doing. Mac assumes you don't want to know what you're doing." Working in an interface that doesn't hold your hand can be liberating when you understand how that system works, but there must be a way we can step back.

Maybe it would be worth adding something similar to the drop-down auto-completion boxes I see in so many modern IDEs. That way instead of reading the man page of every single command and program, I can (for example) get a list of possible arguments, and each of those arguments provides a summary of its function when highlighted. This could all be done in text, so that it would be available outside of the window system. Maybe it has already been done.

Obviously such a system would be laborious to implement and obnoxious to seasoned bash users (though it should be easy to disable), but it would be extremely handy to those who (like me) only occasionally use Linux. In any case, something should be done that makes the system a little more welcoming to casual users.

FWIW I was in the same boat for many years, first on Windows then OS X. I'd learn a Linux trick or two then lose momentum and more importantly lose confidence that I could get around the CLI (and just as important, the maze of config files).

What made a huge difference for me was setting up Arch Linux on my XPS 15 laptop. Following the install guide[1] forced me to go through the process of standing up a functioning Linux desktop from a much lower level starting point than I'd ever done with Ubuntu or CentOS or even Slackware. The whole experience reminded me of the first few times I built PCs as a kid: At first they were intimidating boxes full of complex circuit boards and imposing nests of ribbon cable, but putting a few together demystified all that in a hurry. Setting up my Arch laptop had the same result as it relates to Linux configuration in general and command line operations in particular.

[1](https://wiki.archlinux.org/index.php/Installation_guide)

Both Windows and OSX are "GUI first" OS's, and Linux simply is not. The majority of the Linux systems out-there is headless - and it shows. I drop down to a terminal immediately on any Linux system for everything - GUI or not. On both Windows and OSX, I will most likely do things "the GUI" way first, especially file management with the finder or explorer - although on both these platforms, there are very viable or even excellent CLI environments.

But I get what you're saying - even when looking at the PowerShell design, script documentation is a first class citizen there. As a scripting language I'm pretty impressed with it, but as a shell I find it an annoying place to be in. OSX on the other hand simply has a unix shell, with a respectable amount of CLI tools available to interact with the desktop. Sadly, Apple scripting has been a bit neglected in the last few releases and is not really supported anymore by all applications.

disclaimer: I do not like Linux on desktop. My daily driver is a MBP with OSX, and I used to work on Windows (but still have a gaming box), and all my linux boxes are servers.

> As a scripting language I'm pretty impressed with it, but as a shell I find it an annoying place to be in.

Couldn't agree more. The syntax is fantastic for scripting as it has good support for objects, but it is not good as a shell due to the different return types and polymorphic behavior of some functions based on the type they are operating on. In *nix land this isn't a problem as everything is text.

There are such friendly shells, such as https://fishshell.com/ with auto completion and nifty features.

I agree. I think a REPL (which I consider the command line to be one of) and something like Excel to be immensely useful no matter what the language or proficiency. I think code is much sturdier and I'm more likely to experiment if I can iterate over code after typing every few words instead of (even in a language I'm proficient at) writing a whole page of code, then running it to correct my typos and errors.

I work in visual effects. Most of our software has a build-in Python interpreter. I was talking to a tech savvy junior who was interested in becoming a full time modeler/artist. He was asking if he should learn programming/Python and I advised against it (unless it scratched his particular itch). I felt his efforts were best put towards getting better at modeling. Most large places I've worked at the artist can get by with a sticky note of common commands. There's usually someone they can ask for advice or small scripts when things get hairy. Smaller places you're more on your own. But it is surprising when you have 100+ items, you need to be sure they all have 2 sets of UVs. The manual way is to click on each one and pull a drop-down menu or with Python you can write a one-line foreach to test and print. It's all about knowing which screw to turn[1]

I often challenge myself in doing something in a single line just to scratch my own itch. Often when tackling daunting tasks (do this thing 20-50x) I weigh the benefit of doing it manually, but bias a tad toward automating even if I'm throwing the code away. But I don't think it's worth most people's time.

The biggest benefit of working the same place a long time is knowing who to ask about things. Second is knowing the history of things. Third is having a junk drawer of scripts that don't quite work out of the box, but they have idioms I can grab when I need to hammer something out.

[1] https://calvincorreli.com/blog/1397-knowing-which-screw-to-t...

I do a lot of 3d stuff (not a pro) and I've found a passing knowledge of programming is quite useful when you're doing something a little bit more unusual or complex. I did some pretty big cityscapes made out of modular components, and it was nice to have python for stuff like twisting 300 TV aerials so they're all a little bit differently wonky, or making lines of washing.

I'm also a big believer in mastering your tools. An artist is limited by their imagination - and imagination is largely structured by your knowledge of materials and the capabilities of tools. If you're working with 3d models, and you plan on mastering it, having an idea of what you can do with An artist is limited by their imagination - and imagination is largely structured by your knowledge of materials and the capabilities of tools. It spurs you on to try new and ambitious stuff, new styles, new forms.

As passing knowledge is great, but focus and mastery just requires too much time (and time to maintain). Something as large as Maya or computer graphics you have to pick your battles. If you're completely independent or at a very small studio you have to be scrappy, but I think that means more of having a wide toolset, a lot of copy/paste and experimenting. You just don't have the time to master and maintain that mastery.

My career has let me focus on the backend and internals. I know people way more proficient than I am with Maya, but they know little to nothing about Python or the DG (or maybe MEL). I know a few vfx sups who can cobble together a basic shell command, but aren't masters and don't know a bit of Python. It's much easier to interact with them (especially over chat/email--I can send them a command and trust them to modify paths and run it), but it's not worth their time to invest in honing those things. It's probably cheaper to fly someone from a different state to do these things for them than it is for them to spend half a day writing something to parse and edl to rename some Quicktime files or troubleshoot a bad power supply in their workstation. I've also noticed that the more technical they are, the deeper the hole they're in before they ask for help. Hopefully that means they're more productive (and are more ambitious), but it usually means I have to ask them what their original problem was, then what was the first thing they did, then the second, and unwind the situation.

For the situation you described of turning buildings there are probably 5-10 completely different approaches you could take (apart from manually placing them), only a few use Python. At a moderately sized studio (on a moderately sized project), I'd reach for something like Houdini to do what you're asking and you would be hard-pressed to find someone who would use Python for this kind of thing in Houdini. On the flip side I was handed a project at a small place that was well suited for Houdini. We didn't have a license so I cobbled something together in Maya. The producers were telling me in their experience they'd hire someone who would do a project in Houdini, but later when they needed changes and that person wasn't available they'd have to hire someone to redo it in Maya. Reality is hard.

My thoughts about this really clicked with photography. A lot of photographers are just technical enough. Most of the process is a black box, but they've had their camera for years, tested enough inputs and outputs that they can trust their tools to do what they want. Other photographers dig into the tech. They can't, by definition, have as much time in the field. They can tell you a lot more "why" and might be equally good or better in many respects, but it can be really easy to get lost in the tech and miss out on the practice.

I guess I'm interested in 3D stuff because I feel like I'm living in the birth of a new medium, like when people discovered painting, or dance. Most people doing 3d are doing stuff you could do in another medium, like film but cheaper, or interactive.

On the one hand, you're absolutely right when you say that it's largely unproductive to work outside of your speciality. On the other, I think it's a bit like painters learning to make their own frames and mix their own paints. It's not strictly necessary, but it deepens the understanding, and it opens the door to loads of stylistic discoveries.

I think the thing I like about python, or programming in general as a creative technique, is the combination of amazing fine-grain control, with absurd expressiveness. The kind of techniques you learn as an artist are usually strong on one or the other. Crosshatch gives you a lot of control over light and shade, but it's a time-consuming, boilerplate kinda technique. Most traditional techniques are like that, or, like throwing paint at a wall - very expressive, but no control.

Programming the creation of sculptures and images is the kind of amazing opportunity that it feels sort of crazy to pass up. I've spent an inordinate amount of time refining my ability to draw nice gradients with a set of pencils - and now I have a machine that can give me a perfect gradient with a couple of lines of code!

Reply on news.ycombinator.com