Skip to content

CaC Compare and contrast

Bruce Gray edited this page Jun 10, 2021 · 1 revision

This is (intended to be) the root page for a series of Comparison and Contrast pages, all starting with Cac - .

CaC pages are for discussion of TIMTOWTDI, and developing recommendations on use cases for close alternatives.

The ultimate goal is to provide guidance to Raku users about "close alternatives" (TIMTOWTDI; there is more than one way to do it). The blocker to that goal is that the global amount of production Raku code is too small for "best practices"[1] to have naturally evolved. These "Compare and contrast" discussions should accelerate that evolution.

[1](as opposed to the "best practices" that have formed in the mind of any single contributor, which feel quite clear and worthy of universal adoption, until anyone with a slightly different perspective is forced to adopt it.)

It is closely related to discussions of Idiomatic Raku, but is not identical. The inspiration was the C2 wiki on Patterns. It is intended to be distinct from documentation discussions.

For example (just made-up by @Util):

  • Andy: I always use .rotor, because it does everything I want. I add :partial where needed, and when reviewing my code, I know to question everywhere :partial is missing, to make sure that either I want truncation, or I checked in the previous line with something like warn unless @a %% $batch_size;
  • Bob: I always use .batch, because it works just like .rotor(:partial). I left :partial out of .rotor once, and the resulting bug was hard to pin down. I have no use for .rotor's back-skipping options, so it is no loss to me to ignore .rotor.
  • Cindy: Well, I prefer .batch over .rotor for the reasons you listed, but I find the back-skip in .rotor to be too valuable to ignore. for @a.rotor(2 => -1) -> ($left, $right) { say "$left is adjacent to $right" }
  • Bob: Oh! I didn't know about that! I will add .rotor for that use case (which means I am softening my prior statement).
  • Donna: I would use this instead: for ( @a Z @a.skip ) -> ($left, $right) { say "$left is adjacent to $right" }
  • Erzabet: That does soften the most common use case for .rotor's back-skip, but any more of that comparison should be on its own page. Creating new page CaC-rotor-back-vs-Z-skip.

Only after something close to "best practice" is identified, then a ticket might be opened on how to communicate it. We might:

  • add "see also" cross-references to the docs of the alternatives, or:
  • (as I am doing with the Guide to Sorting) have a doc that lays out all the variations with guidance on when to use which variant, and add Guide pointer to all the related docs. Or:
  • add a entry to the "Traps" doc.
  • add a entry to the "FAQ" doc.
  • Write a book chapter on the topic.
  • etc...