I would like to see something about "Why Python is worth knowing" from someone who knows APL. For whatever reason I can spend time playing around APL but I cannot force myself to spend time playing around with Python.
My first language was J, and I also struggled to work with Python at first. However, I'm glad I did have to work with Python and particularly Javascript. The big things I think an APLer can benefit from are first-class functions, code organized in namespaces (possible but not common in Dyalog), and mutable data structures, objects and dicts in particular. Interestingly you can now encounter these in the APL family. I developed BQN largely to incorporate these modern ideas, and compared it with APL at [0]. It's still missing dicts, which are incorporated well in the K language. I don't know if you'd end up learning the concepts as deeply though. Particularly objects are somewhat peripheral in BQN, while they're more central in Python.
APLers have some tendency to be indifferent or even hostile towards abstraction. By abstraction I mean that you write a portion of your program, remember what it does, forget about how it does it, and go on to write other parts. Making a clean "what it does" interface introduces some overhead (in lines of code, thinking, and performance), and languages like Java or Haskell make it easy to go overboard and waste more time on building your abstractions than writing the program. However, the idea that you should avoid abstraction entirely is a huge mistake in my opinion, and I think APL programmers that do this could improve their programs a lot by breaking off a few pieces. Features like objects make abstraction a lot easier and can teach you intuition for where the program naturally splits apart.
(You might be thinking "but I already know this!" The NumPy programmers think this about arrays too. You probably don't know it as well as you could.)
I am very wary of taking too much from (python, js, et al). Referential transparency is of great value, and it is a shame to lose it. As a colleague is fond of saying, mutation (et al) is an implementation issue, not a language issue.
Also: python does not scale well. If you pursue python (or its ilk), you will converge on common lisp (or similar), which is, ideologically, diametrically opposed to apl. The conflict should be clear. Conceptual integrity and coherence will be lost at any point in between (this is not to imply that common lisp is a bad thing).
And, by nature, common lisp can subsume apl (see april), but the reverse is not true.
Hopefully this won't be seen as too combative, but I feel like there are a few people in the array community giving me some pretty strong conclusions that they don't really have the experience to back up (Aaron wrote[0] 17 lines of array compiler, and says the low-abstraction approach he used is the only way to develop sustainably. Cool. I wrote[1] 350 lines of array compiler following his style, and I disagree[2]). At the same time, my experience only goes so far (there's no way I would have invented the array style compiler!), and clearly you arrived at these conclusions somehow. So is there a chance you'd share the observations that led you that way?
On my end, I was actually introduced to a little object-oriented programming in J when Henry suggested using it for a simulation project. I used it, but I don't think I really got it—just a weird way to organize data. And then in college I had to learn objects-only Java. Not good. But later I worked some with Node.js, and its module system was pretty nice: no name conflicts, easy to share code! Some way into BQN development, I figured out (with some help from a Common Lisp programmer) a way to add modules with an APL-y syntax, and something magic happened. I got objects[3] too! I think I've done about as much OOP in BQN as anywhere else, and I feel like I understand it a lot better now.
So, this is my experience with Lisp-family features and APL. Fits like a glove, programming is easier and more fun. I mix and match array, functional, and object-oriented styles however I want. Did I lose coherence? When I translate my old J code it comes out shorter and cleaner and without exec (".) everywhere. But I still don't get why I should want the language I use to not support mutability rather than just default to immutability. Did I fail to understand something in J when I had the chance?
For many of us who learned J, it was a sixth or maybe a sixteenth language: an interesting rabbit-hole, among many explored rabbit-holes. :) I'm sincerely interested in knowing how you came into programming with J as your first language!
I learned it from a teacher at my high school, Henry Rich, who was an APL programmer for a while and a J early adopter: https://aplwiki.com/wiki/Henry_Rich
Yeah, but that only works for small code fragments. There's a lot in Python that doesn't hit that sweet spot. Anything with double underscores or list comprehensions, for example, which is any complex Python program. Arguably anytime you have to `import` anything.
edit: I suspect the poster was asking from the perspective of someone who does APL and wants to know what benefits Python would have in that space.
I'd argue that this is quite tunnel visioned since here are large Python codebases that are busy printing money for these huge SaaS companies while I'm writing this comment.
Whether we like it or not Javascript and Python have won the game with all of their warts and no amount of WASM is going to change the fact in the foreseeable future.
Maybe the advantages of a ubiquitous, conventional language that doesn't require its own bespoke input system become more clear when you're not just playing around.
MicroPython exists, I'm not sure why that isn't used more. A lot of C programs could be replaced with MP+Py to keep everything small enough to statically link.
But outside of embedded or initramfs(Or static bundles) I don't see how the size matters much.
Using microPython I could probably replace the use of shell for many tasks. I doubt I would get any speed gains but maybe I could learn Python in the process. It's an idea.
A reason I am interested in learning Python is, of course, to understand and edit certain Python programs written by others. That reason has just not been compelling enough to get me to learn it. I spend more time on C. I need to have a C compiler for various reasons, like compiling kernels, so that provides an excuse to learn it. However I can get by without Python. Hence I am better with C than with Python. That later just is not "essential" for me, or interesting enough, like APL.
I do stuff that is like embedded and intramfs, custom static multicall binaries, on older and small form factor computers, so the size does matter.
One easy and pragmatic answer is that there are thousands of jobs paying over $500k USD per year to people who write python. I don't have firsthand knowledge but I would guess there are ~0 high paying jobs for APL programmers.
