4 ms·

I knew Ruby copied a lot from Perl, but I wasn't prepared for just how much these are exactly how you would do the same thing in perl, just with the the order o

I knew Ruby copied a lot from Perl, but I wasn't prepared for just how much these are exactly how you would do the same thing in perl, just with the the order of passing lists reversed. The command line switches are the same, the BEGIN/END block stuff is the same, the $F auto-splitting is the same. Good on Ruby, that's the stuff that makes Perl one-liners actually worth coming back to again and again.

faitswulff 7y ago
What is that BEGIN{...} and END{...} syntax? I've seen a good amount of Ruby, but haven't encountered that yet.
- jhbadger 7y ago
  It's basically there to make Ruby an equivalent to AWK. It only makes sense if you are looping over the lines with -n. The BEGIN block runs at the start of the run, and the END block at the end. They are useful for things like initializing a sum variable to zero at the start and printing it out at the end.
- emmelaich 7y ago
  What really baked my noodle is that there is another "end" called __END__ used like this $ cat data.rb DATA.each_line { |ln|puts ln } __END__ fish cat dog $ ruby data.rb fish cat dog
- masklinn 7y ago
  It's from awk: the BEGIN and END patterns match the start and end of a file/stream being processed, while normal patterns are checked on each line (and no pattern matches every line). This is very useful to script a setup -> for reach line -> summary of a file e.g. initialise a map in BEGIN, fill the map for each line, and print the map in END.
pmontra 7y ago
That kind of Ruby is pretty different from the Ruby one use to write applications like Rails. For example, after 14 years of Ruby I have no idea of what $F is. I have to google it, and I did at least 10 years of Perl before that. I use Ruby for text processing now, because it's easier to read than Perl, but I loop on stdin with IO.readlines, each and split. It could be less efficient but I'm not parsing billions of records. I value readability more than one liners.
- kbenson 7y ago
  > That kind of Ruby is pretty different from the Ruby one use to write applications like Rails. That's fair. That kind of Perl is also very different than the kind of Perl you would use to write Mojolicious applications, or system utils, or daemons. Those features are very specifically for quick one-liners[1], and in some cases don't even make sense outside of that. > I use Ruby for text processing now, because it's easier to read than Perl, but I loop on stdin with IO.readlines, each and split. In a one-liner, or as a small source file? Doing that in a small source file is also common in Perl, but if you're doing that as a one-liner, I think you're not making it more readable, you're making it less so, as the executable/language specifically support features to make that easier to do which you're ignoring, obfuscating the important parts of the code with verbose obvious bits. It's sort of like making sure to spell out et cetera instead of using etc even when texting or using Twitter. 1: BEGIN actually has some important uses in Perl, but under the covers for most people, so they never have to deal with it.
  - pmontra 7y ago
    Small source files. I don't write one liners, they are hard to maintain.
    - kbenson 7y ago
      Well, I don't write one-liners that are meant to be maintained either, but I don't put my piped commands of grep, but, sort and uniq into small source files either. They're meant for different things. There is conceivably a case for small one-off programs just like a chained shell statement, and that's what a one-liner is for. For a really simple case, leveraging a module in the language to do the heavy lifting and do something per line. If I want robust CSV conversion for a TSV, loading up a CSV module in Perl or Ruby and letting it act on each line (after appropriately split on tab, and with the newline removed from each line, both a single command line switch away) is a very small one liner that's appropriately leveraging the language to do something that's hard with common shell utils. There's a whole world of ways to leverage a powerful ecosystem with the built in one-liner features of Perl and Ruby. If you don't often find yourself doing a lot in the shell, then I can understand having a hard time imagining a case where it's not always better for a small source file, but for anyone whose responsibilities also entail a fair amount of system administration tasks, it can be extremely helpful. If for nothing else, the number of times I've used autosplit or a nice regex to parse a complex line into an appropriate SQL statement I can output to another file, check, and then run is quite large. These often amount to a single regex and print per line, and are on some other log portion I've already grepped out, so generating the boilerplate for the line looping is actually more code than the actual statements that need to run. Add to that the times that there's no maintenance needed because the scripts are used to fix a one-off problem, and there are specific use cases where one-liners make sense. For a lot of people's workload, that might not be the case, but I definitely see the cases where it is.
pizza234 7y ago
I don't trust Ruby for text processing anymore. The removal of the flip-flop operator, which is a fundamental tool in text processing, sent a very clear signal about the Ruby direction (that is, to be "The Rails language" and nothing else). How can one be sure now, that all the functionality you've mentioned (and more) won't be removed as well? Perl can be ugly, but its foundation in text processing are established.
- byroot 7y ago
  > The removal of the flip-flop operator Well that never happened. It was deprecated with the intention to remove it, but they backtracked: https://bugs.ruby-lang.org/issues/5400#note-25 https://bugs.ruby-lang.org/issues/5400#note-25
  - pizza234 7y ago
    Interesting. The discussion, although minimal, lasted years, then closed pretty quickly. Good for Ruby :-)
  - faitswulff 7y ago
    I'm glad Ruby takes community feedback seriously, for the most part - most recently the pipeline operator and the named block parameters, for instance.
  - cutler 7y ago
    I heard Matz is going to remove the Perl special variables in Ruby 3.0. Can't think what the fuss is all about. They're pretty useful in command-line Ruby. I moved from Perl to Ruby so I will be sad to see this bit of Perl heritage removed from Ruby. I mean for what gain?
    - byroot 7y ago
      Only a very small subset of them: https://bugs.ruby-lang.org/issues/14240 https://bugs.ruby-lang.org/issues/14240 $/ input record separator (default argument for "gets") $\ output record separator ("print" prints it at last) $, default separator for Array#join and print $; default separator for String#split As for the gain it's because these variables globally change the behavior of important core methods. They really aren't that useful, but can easily cause havoc.

faitswulff 7y ago

What is that BEGIN{...} and END{...} syntax? I've seen a good amount of Ruby, but haven't encountered that yet.

jhbadger 7y ago
It's basically there to make Ruby an equivalent to AWK. It only makes sense if you are looping over the lines with -n. The BEGIN block runs at the start of the run, and the END block at the end. They are useful for things like initializing a sum variable to zero at the start and printing it out at the end.
emmelaich 7y ago
What really baked my noodle is that there is another "end" called __END__ used like this $ cat data.rb DATA.each_line { |ln|puts ln } __END__ fish cat dog $ ruby data.rb fish cat dog
masklinn 7y ago
It's from awk: the BEGIN and END patterns match the start and end of a file/stream being processed, while normal patterns are checked on each line (and no pattern matches every line). This is very useful to script a setup -> for reach line -> summary of a file e.g. initialise a map in BEGIN, fill the map for each line, and print the map in END.

pmontra 7y ago

That kind of Ruby is pretty different from the Ruby one use to write applications like Rails. For example, after 14 years of Ruby I have no idea of what $F is. I have to google it, and I did at least 10 years of Perl before that. I use Ruby for text processing now, because it's easier to read than Perl, but I loop on stdin with IO.readlines, each and split. It could be less efficient but I'm not parsing billions of records. I value readability more than one liners.

kbenson 7y ago
> That kind of Ruby is pretty different from the Ruby one use to write applications like Rails. That's fair. That kind of Perl is also very different than the kind of Perl you would use to write Mojolicious applications, or system utils, or daemons. Those features are very specifically for quick one-liners[1], and in some cases don't even make sense outside of that. > I use Ruby for text processing now, because it's easier to read than Perl, but I loop on stdin with IO.readlines, each and split. In a one-liner, or as a small source file? Doing that in a small source file is also common in Perl, but if you're doing that as a one-liner, I think you're not making it more readable, you're making it less so, as the executable/language specifically support features to make that easier to do which you're ignoring, obfuscating the important parts of the code with verbose obvious bits. It's sort of like making sure to spell out et cetera instead of using etc even when texting or using Twitter. 1: BEGIN actually has some important uses in Perl, but under the covers for most people, so they never have to deal with it.
- pmontra 7y ago
  Small source files. I don't write one liners, they are hard to maintain.
  - kbenson 7y ago
    Well, I don't write one-liners that are meant to be maintained either, but I don't put my piped commands of grep, but, sort and uniq into small source files either. They're meant for different things. There is conceivably a case for small one-off programs just like a chained shell statement, and that's what a one-liner is for. For a really simple case, leveraging a module in the language to do the heavy lifting and do something per line. If I want robust CSV conversion for a TSV, loading up a CSV module in Perl or Ruby and letting it act on each line (after appropriately split on tab, and with the newline removed from each line, both a single command line switch away) is a very small one liner that's appropriately leveraging the language to do something that's hard with common shell utils. There's a whole world of ways to leverage a powerful ecosystem with the built in one-liner features of Perl and Ruby. If you don't often find yourself doing a lot in the shell, then I can understand having a hard time imagining a case where it's not always better for a small source file, but for anyone whose responsibilities also entail a fair amount of system administration tasks, it can be extremely helpful. If for nothing else, the number of times I've used autosplit or a nice regex to parse a complex line into an appropriate SQL statement I can output to another file, check, and then run is quite large. These often amount to a single regex and print per line, and are on some other log portion I've already grepped out, so generating the boilerplate for the line looping is actually more code than the actual statements that need to run. Add to that the times that there's no maintenance needed because the scripts are used to fix a one-off problem, and there are specific use cases where one-liners make sense. For a lot of people's workload, that might not be the case, but I definitely see the cases where it is.

pizza234 7y ago

I don't trust Ruby for text processing anymore. The removal of the flip-flop operator, which is a fundamental tool in text processing, sent a very clear signal about the Ruby direction (that is, to be "The Rails language" and nothing else). How can one be sure now, that all the functionality you've mentioned (and more) won't be removed as well? Perl can be ugly, but its foundation in text processing are established.

byroot 7y ago
> The removal of the flip-flop operator Well that never happened. It was deprecated with the intention to remove it, but they backtracked: https://bugs.ruby-lang.org/issues/5400#note-25 https://bugs.ruby-lang.org/issues/5400#note-25
- pizza234 7y ago
  Interesting. The discussion, although minimal, lasted years, then closed pretty quickly. Good for Ruby :-)
- faitswulff 7y ago
  I'm glad Ruby takes community feedback seriously, for the most part - most recently the pipeline operator and the named block parameters, for instance.
- cutler 7y ago
  I heard Matz is going to remove the Perl special variables in Ruby 3.0. Can't think what the fuss is all about. They're pretty useful in command-line Ruby. I moved from Perl to Ruby so I will be sad to see this bit of Perl heritage removed from Ruby. I mean for what gain?
  - byroot 7y ago
    Only a very small subset of them: https://bugs.ruby-lang.org/issues/14240 https://bugs.ruby-lang.org/issues/14240 $/ input record separator (default argument for "gets") $\ output record separator ("print" prints it at last) $, default separator for Array#join and print $; default separator for String#split As for the gain it's because these variables globally change the behavior of important core methods. They really aren't that useful, but can easily cause havoc.