I think that when you see enough of it, these things are pattern matched idioms in your head. You hardly even consciously think about it. You have x, you y and you need it transformed to z; you did something like that 1000 times before and because the language is so terse, you remember the snippets of incantations to do it without looking anything up.

When I programmed Pascal decades ago, I had my own lib, which was huge, it was just a massive collection of functions pulled from projects which I all wrote myself and all remembered (and still remember). When I had to build something, it was mostly cobbling together those functions. Worked a lot faster (with more stable results) than Google->SO or npm search and install.

APL(/j/k) have that but with the added benefit that you don’t have to write or download a library; everything is composable, so instead of remembering/searching the functions I (or someone else wrote) remember the actual implementation... Which, in those languages, is usually the same amount of chars as the function name and usually smaller than the function name with params.

In my experience, existing programmers struggle the most in learning APL because they struggle to internalize the Array Model and how to talk about things as Arrays. The results are, in essence, very poorly typed data, which then requires tons of mangling to make work.

It's the same thing as when you learn various other languages and you start to not appreciate how to appropriately model data in that language, which leads to excessively complex or inadequate types.

IMO, the elegance of a notation is not defined by its ability to prevent people from writing bad expressions, but by the capacity for good expressions to be practically and usefully leveraged. A good notation is about empowerment and clarity, rather than about prevention.

'arcfide is definitely right; don't think of it as the same as the rest of the programming languages in your arsenal. Fortran and ALGOL (which C, Java, Go, Rust, SMALLTALK, etc. are all derivative from) have almost entirely different approaches, and very little valuable carries over.

Approaching it sort of like you would a small Lisp isn't ideal/is a flawed approach but may get you closer: acknowledging it as a separate, distinct paradigm is pretty much necessary to get a feel for it. I think the easiest way to bridge the gap right now is probably learning a concatenative language, just because the resources for teaching those are so far ahead of what APL has right now (the best way I can think of to learn to use notation effectively is by reading one of Iverson's books that use J as notation or doing one of Iverson's J labs) yet still give you a feel for where the paradigm is headed.

Summary: give J's labs a try, they might help you get a hang of the paradigm better; KEI was a fantastic teacher, and Chris Burke, Roger Hui and Eric Iverson have done a great job in maintaining the old & making new labs, and if that doesn't work, try learning a concatenative language first and carrying it over.

Not too far from my personal experience, but it seems to me that all these mismatch scenarios arise when you are programming in the large, either directly or indirectly, i.e., by using third-party libraries, code snippets or even RESTful APIs. In a sense, programming in the large with an APL-like language reminds me of Perl in its best and worse. But things fit pretty well in the small.

I had this feeling exactly listening (great, as everything Aaron does) presentation about manipulation and transformation of trees in APL, https://www.youtube.com/watch?v=hzPd3umu78g