[deleted]
Show HN: Rb – Turns Ruby into a command line utility
71–79 of 79 posts
Re: Show HN: Rb – Turns Ruby into a command line utility
#72Smoking causes cancer
Re: Show HN: Rb – Turns Ruby into a command line utility
#73Earlier quoted context omitted.
but the ruby code is much more intuitively readable
It is if you know ruby. Me, I know perl and honestly I do not grok most of the ruby examples given here. I am quite sure that I could learn them about as fast as somebody not knowing perl and knowing ruby could learn perl.
I know both languages; the ruby version is better IMO. The verbiage is English... the syntax is a bit odd but so is the perl version's
Re: Show HN: Rb – Turns Ruby into a command line utility
#74Earlier quoted context omitted.
Why the hell would anybody want to replace AWK? It’s super fast, extremely light on resources, doesn’t have any dependencies, does auto memory management and type inference, and is extremely powerful for large dataset processing, not to mention easy to learn and program.
> easy to learn and program I think that's relative and it certainly hasn't been my experience. If I program in Ruby, Node, Python, etc for 8 hours of every day, it makes sense that I would reach for that over a command line tool with a syntax that looks a bit arcane. The best tool for the job sometimes is the tool you know best.
It’s arcane only if you don’t know C. If you’re on a UNIX-like or a true UNIX system, not knowing C will come to haunt you with a vengeance sooner or later.
Re: Show HN: Rb – Turns Ruby into a command line utility
#75I'd love this for python as I'm not a big fan of Ruby. Does such a thing exist?
[deleted]
Re: Show HN: Rb – Turns Ruby into a command line utility
#76Earlier quoted context omitted.
Except that in your example, the first line is coherent English, and the second line is just... well... code.
Personally, when I write shell commands, they tend to be write-only code, because the shell isn't really suitable for anything more complex. So it's easier to think in code than it is to add the extra step of translating to English if it's something nobody's gonna see again anyway.
My counter to this would be - if I'm doing a thing, and I need to look back through my shell history a few days or weeks later to figure out how I did it (especially if something went wrong), seeing a more readable version is going to help me figure it out faster.
Granted, anything really nontrivial I'll usually just write a Python script for, but the point stands.
Re: Show HN: Rb – Turns Ruby into a command line utility
#77A bashtardization:
rb () {
[[ $1 == -l ]] && shift
case $? in
0 ) ruby -e "STDIN.each_line { |l| puts l.chomp.instance_eval(&eval('Proc.new { $* }')) }";;
* ) ruby -e "puts STDIN.each_line.instance_eval(&eval('Proc.new { $* }'))";;
esac
}Re: Show HN: Rb – Turns Ruby into a command line utility
#78The second I start wanting a bash pipeline, probably around the third pipe, I scrap it immediately and move to using a text editor to write a script. Because if I'm wanting a pipeline, I'm also going to want to store it, and transmit it over the network, and manage it, and put it down and come back to it later. All things perfectly manageable inside a PORO. Bundler even has an inline mode, so you can put everything i…
> Because if I'm wanting a pipeline, I'm also going to want to store it, and transmit it over the network, and manage it, and put it down and come back to it later.
Not my experience. More often than not, if I'm writing a pipeline (in a shell or in a REPL), it's because someone handed me a file they made in a one-off effort that has nonsensical nonstandard formatting, and I'm trying to normalize it.
If they made another file, it'd have different nonsensical nonstandard formatting, so there's no reuse here.
Meanwhile, writing a pipeline at a REPL (or shell) enables me to just work on it expression by expression, keeping a variable-assignment at the beginning of the expression so that I can then work on the intermediate created data to figure out how to munge it just a little bit more, and then add that back to the pipeline once it's right.
If there was a way to edit a Ruby script such that, each time I save it, my existing REPL session re-runs the script and loads the bindings from it into my existing session—without destroying any other bindings I've made—then I'd be happy to use that. But that's less like "using files", and much closer to using something like a Jupyter notebook.
Re: Show HN: Rb – Turns Ruby into a command line utility
#79The second I start wanting a bash pipeline, probably around the third pipe, I scrap it immediately and move to using a text editor to write a script. Because if I'm wanting a pipeline, I'm also going to want to store it, and transmit it over the network, and manage it, and put it down and come back to it later. All things perfectly manageable inside a PORO. Bundler even has an inline mode, so you can put everything i…
xargs -P and other ad-hoc parallelism tools usually stop me from leaving the command line too quickly (e.g. The other thing that keeps me back is scale. If everything fits in memory, cool, but sometimes I need to sort or uniq something that won't.
sort(1) is a merge sort (specifically, an "external R-way merge")—and, as a merge sort, it actually isn't constrained by memory. It spills its sorted intermediates to disk as temp files! (And, in fact, it even compresses each intermediate, for the same reason a column store like Cassandra does.) It's pretty optimal!
If you're wondering how this is at-all fast (and it is), in Linux at least /tmp is a tmpfs, meaning that these tempfiles are actually ending up as memory after all. They get "spilled to disk" in the sense that the memory associated with the files spills to swap; but, importantly, tmpfs pages know that they're from files, so they have much better swapping semantics than regular memory for the case where you're writing the file as a stream, and then reading it as a stream. (Basically, juggling streams under a tmpfs is equivalent in overhead to managing memory when you've got it, and managing files when you don't, but without any of the dev-time overhead of having to write code for both cases.)