4 ms·
Some of these are cool, but I don't understand the preference for command line tools over writing, say, a short python script in vim and then executing it. I se
by the_cat_kittles 13y ago
Some of these are cool, but I don't understand the preference for command line tools over writing, say, a short python script in vim and then executing it. I see the two methods achieving the same results with about the same amount of text, except with a script, its savable and much easier to type.
- TeMPOraL 13y agoIt's equivalent if you look at the command line as a (very popular) REPL, and at the tools as functions.
- gnaritas 13y ago> except with a script, its savable and much easier to type. That's an odd thing to say as Python scripts are no more savable than shell scripts. Nor are Python scripts any easier to type than shell scripts. Also, as shell scripts tend to pipe commands together, it's multiple process and thus multiple core by default, unlike Python.
- the_cat_kittles 13y agoI wasn't thinking of making them a shell script, I was thinking of using them directly from the prompt- that makes sense. Come to think of it, I should be writing more shell scripts instead of retyping stuff into the prompt.
- goldfeld 13y agoYeah, that's like saying Python sucks for scripting because all your work in the REPL won't be saved. Goes both ways.
- zokier 13y agoThat's why ipython is so nice :)
- williamcotton 13y agoOr better yet, use make.
- reustle 13y agoI could be wrong, but doesn't each piped command wait for the previous one to finish (not multi-core)?
- buerkle 13y agoNo, try this in a command line: sleep 2 | echo hi
- gnaritas 13y agoNo, a pipe ties the output stream of one command to the input stream of another. That means each line of data travels through the pipe separately allowing all processes to run concurrently.
- gizmo686 13y agoNo, both commands run at the same time. What pipe does is pipe the stdout of one command into the stdin of the other command. Occasionally buffering gives the impression of waiting, as many commands will detect that they are being piped (as opposed to outputting straight to a terminal), and not actually send anything to stdout until either they are finished, or they fill the buffer.
- darksaints 13y agoThere are two reasons I prefer command line tools over python/R scripts: 1) Most of the time, I don't need to save anything at all, as they are one-off data manipulations 2) IO and control flow are already taken care of. No specifying that you want to read from stdin, no looping, no specifying how you want to print out. For a one-liner action, that is a ton of boilerplate.
- zokier 13y agoIterative development. It's so easy to press up, add another component to the pipeline, press enter and see the results. Lather, rinse, repeat. LightTable seems interesting development in that regards, it has the possibility to bring similar iterative process to "real" programming languages.
- the_cat_kittles 13y agoyou can do that with vim easily, just map something to ! python % ...but yes, i understand what you are saying
- zmmmmm 13y ago> I see the two methods achieving the same results with about the same amount of text, except with a script, its savable and much easier to type If I wrote a script for every command I executed to manipulate data I would have about a million small files lying around full of one off commands. Frequently I am just debugging or exploring data and I never want to see the command again - but if I do, it will be in my bash history. One of Python's annoyances (which are few) is that it doesn't put enough in the default namespace to be convenient from the command line.