After years of looking at APL as some sort of magic I spent sometime earlier this year to learn it. It is amazing how much code you can fit into a tweet using APL. Fun but hard for me to write.
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.)
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.
I don't know APL, but that has been my thought as well - if APL does not offer much over numpy, I'd argue that the I'd argue that later is much easier to read and reason through.
If you acquire fluency in APL -- which granted takes more time than acquiring fluency in numpy -- numpy will feel bloated and ungainly. With that said, it's mostly an aesthetic difference and there are plenty of practical advantages to numpy (the main one being there is no barrier to entry, and pretty much everyone already knows python).
I thought that too, but after a while the symbols becomes recognizable (just like math symbols) and then it's a pleasure to write if you have completion based on their name (Uiua developer experience with Emacs). The issue with numpy is the intermediate variables you have to use due to using Python.
>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".
> 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.
