Stages of denial in encountering K

Beyond a point however, I cannot read my own regex's after a month's absence. Which is why I use perl's /x modifier extensively to split up regex components onto multiple lines and to document them thoroughly, even if they are for throwaway scripts, because I don't always throw them away!.

For example:

    $_ =~ m/^                         # anchor at beginning of line
            The\ quick\ (\w+)\ fox    # fox adjective
            \ (\w+)\ over             # fox action verb
            \ the\ (\w+) dog          # dog adjective
            (?:                       # whitespace-trimmed  comment:
              \s* \# \s*              #   whitespace and comment token
              (.*?)                   #   captured comment text; non-greedy!
              \s*                     #   any trailing whitespace
            )?                        # this is all optional
            $                         # end of line anchor
           /x;                        # allow whitespace

This is where K fails me. It may not be a fault of the language, but everyone in the community has bought into this strange idiomatic style. I can't imagine debugging it, or checking it for correctness, or foisting it on a less experienced developer. Here's a canonical example an xml parser, on their website.

https://a.kx.com/a/k/examples/xml.k

Where's the pedagogy? Where are the comments? Why is this line noise considered acceptable?

> If you wanted to fix a bug in a function you would have to write a new copy and explicitly update callers to use the new version.

Finding all callers is the hard part though! And in modern languages, that need to be addressed both at compile (or "compile") and run time.

Assuming you've got all the call sites with what constraints you were given and have imposed, the second part, where you call a specific version of a function, is where it gets tricky.

Is the bug in the calling code or the called code? because huge software maintenance is obtuse. The original programmers have all long since left, so what we're left with is a smattering of random specific version calls, with only the tiniest of tidbits of history, locked away in someone's email, and saved in the previous ticketing system.

So it sounds interesting, but I worry (though I worry about a great many things), that the programmer three years later, ends up coming across calls to three different versions of some code, with no guidance on which ones can be upgraded, should be upgraded, and must not be upgraded. I can't say which one would involve digging up more ancient history though.

Look at the kind of replies you get on every hn thread on APL/J/K - the majority of the negative comments around readability are emotional/gut level responses.

People aren’t trying to understand K examples for a couple of hours and failing... they are making snap judgements based on their experiences in other languages.

That is hard to overcome.

A mathematical paper introducing some meaningful worker function uses English because mathematical notation is insufficient for describing computation. That's one of the important goals of Iverson's notation.

> We have this style in the programming world. It's called Literate Programming. How many K programmers write in that style?

Quite a few! I would actually suggest there are more literate K programmers than there are literate C programmers! Every 4-5 lines of code probably has 2-3 lines of prose in a large application that I work on, but in another language that might be something like 500 lines of code for 2-3 lines of prose which puts the prose offscreen for most of the code it's describing.

Some C programs will try to keep the prose-to-code density higher than that, but even amongst Knuth's code that's rare.

Now do the same with well-written, verbose C-style or Python code (no shorthand/abbreviations, no lambdas, no ternary notation, etc.).

Shorthand code in any language is bad in the long run because it's unmaintainable except by people who work with it on a regular basis. You are making the same arguments as Perl fanatics who used every possible abbreviation in their language 25 years ago. How much of that is even comprehensible now without a major reverse-engineering effort?