In any case, I wonder if the OP's motives were good or if this was just some SEO game... we have enough of the latter on the internet.

So not necessarily written by Matz, but part of the body of work that eventually saw a `git init`, and early enough that much of the modern standard Ruby formatting was still emerging. Doesn't seem all that surprising to me in the context of when it was written.

Not really Python like at all - apart from the one line with for. Python doesn't have a case or when statement, or syntax level regex, doesn't open or close directories, and for files it would idiomatically would use the context manager for file access rather than closing it.

But it also doesn't look like any Ruby I've seen or written either :)

I just finished a class that was taught with Ruby. It seems like an absolutely delightful language, but I could not find docs pertaining to several projects that I had conceptualized as my 'final project'. Microsoft Graph API has no docs available for Ruby.

  Dir.open('.') do |dirp|
    dirp.each do |f|
      puts f if f.match?(/\.rb\z/)
    end
  end

There are a few ruby stdlib classes like Tempfile that use the finalizer trick you mention to free resources on GC but Dir isn’t one of them. Here’s it’s implementation:

https://github.com/ruby/ruby/blob/1a24442193fe437e761e941d1a...

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 } + 4

Second, 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.

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.

I agree with the top post - I have a very different idea about what "built-in" means than the author of this article.

Alas, logs aren't easily accessible in the element android app (which is what i've got).

If you're making a new programming language today, the standard library is a place where you should think very carefully about everything you add. Every programmer learning the language will have to be familiar with the standard library, so keeping it small is good. But too small, and programmers will always have to reach for third-party packages without maintenance or stability guarantees. For example, you don't want to have to choose among 5 different libraries to write and run unit tests; the language should define that and it should meet everyone's needs (or be extensible with a small third-party library).

I think the Rubys and the Perls of the world probably choose too much to add to the standard library, and that's where the comment you're replying to comes from. But, while it's easy to overdo the standard library, it's also bad if you underdo the standard library. Tough and sometimes under-considered aspect of language design.