Well, that's a twist in the conversation! :) They are both very interesting attempts in support of the idea that notation can be important, or, as Iverson put

Well, that's a twist in the conversation! :) They are both very interesting attempts in support of the idea that notation can be important, or, as Iverson put it, a tool for thought. That said, BQN is the language that, I think, could be said to be the more direct descendant of APL in every sense. It fixes some of APL's problems and expands functionality. UIUA, for example, is stack based, something that I am not sure is the right approach and certainly not the way APL operates. As for the future, well, this is uncertain. Software engineers these days are not generally exposed to non-C-like languages in school. Languages such as Forth, APL and LISP are so rare to them that most have never heard of them. This, I think, is really unfortunate. Learning to think about solving problems computationally using different approaches is, in my opinion, invaluable. For example, if you studied APL, NumPy instantly makes sense and is easy to learn. My guess is that lack of familiarity and closed minds (due to lack of exposure to diverse ideas) will always get in the way of adoption of notation-based computing. There's another argument that is just as valid: If what we have today works well, there is little motivation to change. In other words, shifting to a notation-based system would have to deliver an unquestionable delta in value for it to make sense. And then there's the age of AI-based programming. In an age when writing code might come down to writing specifications, the output language might be of little consequence outside of platform, performance and other metrics. Want performance? As the AI to deliver optimized C code. Want compatibility with a set of libraries/ecosystem at the expense of performance? You might ask for Python. Etc.