Expanding and explaning the cherry-picked lines of Red/System code referenced above:

    return old-gradient-pen DC cmds start tail cmd sym catch?
    OS-draw-brush-pattern DC size crop-1 crop-2 word as red-block! cmd sym = fill-pen
    _read opfd hash alg-digest-size type

Let's take the first line (coming from the low-level implementation of our Draw DSL), when a few surrounding lines are pulled with it, it looks like this:

    either grad? [                              ;-- gradient pen
        count: 0
        stops: cmd + 1
        if TYPE_OF(stops) = TYPE_PAIR [
            return old-gradient-pen DC cmds start tail cmd sym catch?
        ]
        loop 2 [                                ;-- at least two stops required
            DRAW_FETCH_VALUE_2(TYPE_TUPLE TYPE_WORD)
            DRAW_FETCH_OPT_VALUE(TYPE_FLOAT)
            count: count + 1
        ]
        _start: cmd
        while [ cmd < tail ][                   ;-- optional more stops

`old-gradient-pen` is a function call (defined in the same file), taking 7 arguments. The naming of that function is not complying with our coding guidelines, as we require function names to start with a verb, so this could have been made a little more readable, that's granted. But look at that, 3 comments there! (they start with a ; character)... so much for the "with no comments"...

For the second line, the surrounding code is:

    case [
        mode = _pattern [
            DRAW_FETCH_VALUE(TYPE_PAIR)
            size: as red-pair! cmd
            word:   null
            crop-1: null
            crop-2: null
            DRAW_FETCH_OPT_VALUE(TYPE_PAIR)
            if cmd = pos [ crop-1: as red-pair! cmd ]
            DRAW_FETCH_OPT_VALUE(TYPE_PAIR)
            if cmd = pos [ crop-2: as red-pair! cmd ]
            DRAW_FETCH_OPT_VALUE(TYPE_WORD)
            if pos = cmd [
                word: as red-word! cmd
                type: symbol/resolve word/symbol
                unless any [
                    type = tile
                    type = flip-x
                    type = flip-y
                    type = flip-xy
                    type = clamp
                ][ cmd: cmd - 1 word: null ]
            ]
            DRAW_FETCH_VALUE(TYPE_BLOCK)
            OS-draw-brush-pattern DC size crop-1 crop-2 word as red-block! cmd sym = fill-pen
        ]

This code is coming from our Draw DSL interpreter. The `DRAW_FETCH_*` macros are there to help process the DSL commands and the code organization around them is consistent across all the file. This particular snippet is from the `check-pen` function, so the `pen` command in `pattern` mode as implied by the `mode = _pattern`. The syntax of that command is documented here [8]. Using it, reading this code snippet becomes straightforward for any Red/System developer.

Now about the specific line you have pointed out, `OS-draw-brush-pattern` is a function call, taking 7 arguments too. Those functions are cross-platform wrappers over 2D-vector drawing API, that are notoriously heavy on parameters. The `= fill-pen` part is adding an inline comparison (`=` is a comparison operator, while `:` denotes assignement in Red and Red/System) with the result of the left function call, and returning the resulting logic value to the calling expression. An intermediary variable could have been used, or parens wrapping the left function call, but that's up to the maintainer of that code part to decide. This is nit-picking anyway, as all the Red contributors working with Red/System will have no issue reading that code on first look.

Now let's look at the last line you've cherry-picked (with some context):

    fd: socket AF_ALG SOCK_SEQPACKET 0
    sock-bind fd sa 88
    opfd: accept fd null null
    _write opfd as c-string! data len
    _read opfd hash alg-digest-size type
    _close opfd
    _close fd

It is coming from the Windows platform-specific `get-digest` function in `runtime/crypto.reds` file. It is a very low-level function compared to the rest of the runtime stack. `_read` is just an OS API import with 3 arguments. `alg-digest-size` is a function call taking 1 argument, and with a bad naming again. It should have started with a verb, or at least use a tail `?` character to denote a property retrieval. Also `opfd` is not very well named... So this is not the best example of nicely crafted code in the Red runtime library, I agree with that. Though, using that to mislead readers into thinking that the whole source code is unreadable is, once again, dishonest.