It's not as extreme but I feel similarly every time I write dense numpy code. Afterwards I almost invariably have the thought "it took me how long to write just that?" and start thinking I ought to have used a different tool.

For some reason the reality is unintuitive to me - that the other tools would have taken me far longer. All the stuff that feels difficult and like it's just eating up time is actually me being forced to work out the problem specification in a more condensed manner.

I think it's like climbing a steeper but much shorter path. It feels like more work but it's actually less. (The point of my rambling here is that I probably ought to learn APL and use it instead.)

>Afterwards I almost invariably have the thought "it took me how long to write just that?" and start thinking I ought to have used a different tool.

I think there is also a psychological bias, we feel more "productive" in a more verbose language. Subconsciously at least, we think "programmers produce code" instead of thinking "programmers build systems".

Should you ever decide to take that leap, maybe start here:

https://xpqz.github.io/learnapl

(disclosure: author)

Indeed numpy is essentially just an APL/J with more verbose and less elegant syntax. The core paradigm is very similar, and numpy was directly inspired by the APLs.

> It's not as extreme but I feel similarly every time I write dense numpy code.

https://analyzethedatanotthedrivel.org/2018/03/31/numpy-anot...

> All the stuff that feels difficult and like it's just eating up time is actually me being forced to work out the problem specification in a more condensed manner.

Very well put!

Your experience aligns with mine as well. In APL, the sheer austerity of architecture means we can't spend time on boilerplate and are forced to immediately confront core domain concerns.

Working that way has gotten me to see code as a direct extension of business, organizational, and market issues. I feel like this has made me much more valuable at work.