Thanks for the comment. I'll look into the items you suggested and see what I can learn. My perspective on APL going forward is that it must retain symbolic n

Thanks for the comment. I'll look into the items you suggested and see what I can learn. My perspective on APL going forward is that it must retain symbolic notation. This is a very important element of the value delivered by this language and one of the aspects that tends to be difficult for non-APL-ers to understand (the value) from what amounts to casual contact with the language. You have to live APL for a while before the "tool for though" realization --and the importance of the symbols-- can be understood. In the '90's Iverson developed J to get around the difficulties technology of the era had with symbols. This was a huge mistake and something that went exactly opposite the "Notation as a tool for thought" idea he promoted for years when describing APL. I watched him give this lecture in person at one of the APL conferences in the mid 80's. The problem with any language --APL being no exception-- is that a business case must exist for wide adoption. Engineers tend to get lost in the technical minutiae, which is important when you are doing the job but it isn't a requirement for the job to be done. Or put more precisely: IF there is no quantifiable need for APL and a mechanism for better ROI, it is hard to justify shifting entire teams to this, or any other language, simply because we like the technical aspects of it. At the end of the day things are simple: It either makes sense or it does not. I would LOVE for APL to become relevant again and for it to find mass adoption. I love the language. And yet I understand business and know the probability of this happening is so close to zero it might as well be zero. Sadly.