If you mean this to be a direct reply to me then you're putting quite a lot of words in my mouth (leephillips is much closer to the position you're arguing agai

If you mean this to be a direct reply to me then you're putting quite a lot of words in my mouth (leephillips is much closer to the position you're arguing against). I don't think the APL language or environment is ideally productive, and I think there are large barriers to adoption and probably wouldn't choose an array language for a commercial project. I made the narrow point that symbols have significant advantages over words—and if you'll go to link I posted you'll find that I also argued that symbols have significant disadvantages as well and shouldn't be used for everything. If I was to consider anything ideally productive it would be my own array language, BQN. Obviously if APL was so good there would be no need to make such a language. Nonetheless I think BQN is far from a perfect array language[0], and that the array paradigm is not a good fit for everything. The feature I miss most is algebraic datatypes or even tagged unions, so there are many contexts where I'd choose a statically-typed language. BQN also (intentionally) makes dictionaries and mutable data harder to work with than other languages, which isn't always a good thing. It's hard to even figure out where to begin with barriers to APL's adoption. Proprietary implementations, storing source code in binary format, lack of publically-accessible documentation? Do note that APL grew rapidly in the late 1970s and by the 80s was close to mainstream. Personally I don't think it has what it takes to become mainstream in the future, but I'm glad that Julia is doing well. There are a few barriers that have largely gone away, which include the total embarrasment of only beginning to switch from Goto to control structures in 1996[1], text encoding problems (there are still some font issues), and difficulty in trying or obtaining Dyalog APL (GNU is not a good substitute: it, uh, doesn't have control structures). In case it's not clear I still think the APL situation is quite a mess, which is why I'm working on BQN. As you've noted, APL is a niche language. Why the need to smack it down? If you're not interested there's no need for you to try it. I advise you to stay away. If you want me to make you interested, I can't. If you're worried APL will take over and force you to use it… well, it won't. [0] https://mlochbaum.github.io/BQN/commentary/problems.html https://mlochbaum.github.io/BQN/commentary/problems.html [1] https://aplwiki.com/wiki/Control_structure#History https://aplwiki.com/wiki/Control_structure#History