I struggle with code like this (also, complicated piped shell statements). How do you debug/reason about this? I know this specific example may be an exercise, but still.
The yield is probably the most complicated part of it, but it is extremely useful for hiding complexity. Once you understand yield, there is very little magic to what ruby is doing.
I prefer python to ruby, but the concept is the same:
https://realpython.com/introduction-to-python-generators/
As for understanding the command line/reasoning about it, they are usually generated iteratively.
Look at a file to see what you have to work with:
$ cat $file | head -n 5
Decide commas aren't useful and remove them
$ cat $file | sed 's/,//g' | head -n 5
Decide you want a tab between every 4 characters on any given line
$ cat $file | sed 's/,//g' | sed 's/\(....\)/\1\t/g' | head -n 5
Everything else is just being aware of what tools you can use (sed/awk/grep/xargs/etc) and the limits of the data you work with.
GP may have done something like popping the ruby repl, irb, and then:
File.read('input6.txt').chars
File.read('input6.txt').chars.each_cons(4).to_a
File.read('input6.txt').chars.each_cons(4).find_index { _1.uniq == _1 } + 4Second, the solution is optimized for speed of writing (you get more points in AOC the quicker you submit the solution), not for readability. I try to get the chain of calls in my Ruby REPL as soon as the challenge drops.
Third, if you so wish to debug this chain of calls, you can insert a breakpoint and get a REPL anywhere in it with Object#tap:
foo.bar(3).tap { |chain| binding.irb }.baz { |larodi| larodi + 5 }
Debug? You don’t. You have to break your sexy chained-functional-style 1-liner into a “boring” multi-line loop to actually set meaningful breakpoints and work through any problems that may arise. Which is why I dislike this style of code — once something goes wrong, it’s WAY more cumbersome to debug and almost always makes you “unroll” it into its boring, “classic” form. And, of course, once you do that, you’re now debugging something DIFFERENT than what’s shipping in production! And you have to be extra careful to ensure that all of the logic has been kept the same, lest you ship a patch that doesn’t actually fix the bug! This is my prototypical “what programming is NEVER about” example: programming is never about how pretty the code is. Programming is about shipping features, and then being able to diagnose and fix problems with what you shipped.
If I'm at the point where I need to debug a production process with breakpoints, I'd rather just find a new job than worry about my coworker's coding style.
If by “debug” you mean “step through with a debugger” (at least Ruby’s standard debugger), sure (except at the steps with blocks, which you can easily insert as noops as needed with #tap). But, honestly, I almost never resort to using a debugger in practice, so minor variations in where breakpoints can be set aren’t something I see as a big deal.
> and almost always makes you “unroll” it into its boring, “classic” form.
No, it never makes you unroll it in Ruby.
The concept is (generally) called functional composition.
The way one reasons about it, is to mentally split the statement at each function, and think about each step separately. The readability of functional composition comes from the fact there is interrelation exclusively between each adjancent couple of functions - in practice, the reader needs to keep only one result in mind at a time.
Functionally composed statements read like a sequence of statements, rather than a single one. The advantage is that they avoid having to use throwaway temporary variables for each step.
Shell pipes work the same. Even if they're long, assuming that they don't obscure features or use complex intermediate results, they're interpreted the same way - one transformation at a time.
Back to the example. It's not good for a few reasons:
1. it's not properly formatted
2. it uses an uncommon feature (named block variable, `_1`)
3. the sum at the end of the statement breaks the flow.
One would typically write the example like:
index_found = File
.read('input6.txt')
.chars
.each_cons(4)
.find_index { |sequence| sequence.uniq == sequence }
index_found + 4
Regarding debugging: you can split the statement as convenient, and recompose it once you're done with debugging. Depending on the given statement, one can also put breakpoints inside the blocks.