> Linear, word based thinking is not the best for everyone, and for those averse to it, there's APL.

1000x this. My visual memory is better than my memory for sounds (words). That's why I'm compelled to APL and derivates, Haskell or even Coffeescript.. it's way easier to have a macro understanding of the code.

For problems that are about transforming different shapes of information, APL makes sense. However, it isn’t so much about the programmer, but the problem domain.

What problems are not about that?

Plenty of programming problems are non-transformative, anything interactive for one. If you want to see attempts to make it transformative, there is pure FRP (not the fake kind, see Antony's Courtney's dissertation as a good example of how weird this looks at an extreme) and lenses. In either case, it feels like trying to shoe horn one solution to a problem into the wrong kind of abstraction. Much of the today's web work is also non-transformative.

> anything interactive for one

I feel there's a misunderstanding in how you use "non-transformative" versus how I interpret it. E.g. aren't interactive charts mostly about transformations? (data => aggregation => affine transforms => render the graphics)

Mostly? Maybe, maybe not. Every program has transformational elements, but they may or may not dominate. A rendering pipeline is, but if you are implementing a text editor, you might not be doing many transformations at all.