Having used APL professionally for ten years from the early 80's to early 90's I am a big fan. I used it for a wide range of applications, from business system

Having used APL professionally for ten years from the early 80's to early 90's I am a big fan. I used it for a wide range of applications, from business systems to DNA sequencing. I even published a paper at a conference eons ago. So, yeah, I am an "APL guy". And, yeah, I think it's dead. Well, not really, but, yes really at the same time. Let's start with the most glaring issue: https://www.dyalog.com/prices-and-licences.htm#devlicprice https://www.dyalog.com/prices-and-licences.htm#devlicprice Yeah, $1,600 USD for a language license? No. Thanks. Go away. In addition to this: "In addition to a current Developer Licence, a Run Time Licence is necessary if:" Yeah, no. Go away. And then... "When several users use one or more applications on a shared server, a Server Licence is required." No. Definitely no. Please, pretty please, with sugar on top...go away. I could go on. Just have a look at that page and see how you could possibly justify getting into this monster of a business case for your particular business or any other business who's financials you understand. If you are still interested after that, take a moment to go browse the source here... Oh, wait. Yeah. No. Go away. That said, I still do love APL. I love the language, the ideas, what it represents and the superpowers it gives you. It truly enables the creation of computational solutions for complex problems at the speed of thought once you learn to think in APL (which likely takes about a year to fully internalize). During the 80's I often dreamed of designing a purpose built computational engine (hardware) specifically designed to execute APL commands in one clock cycle. Hey, I was young and stupid. While I was using APL I was also coding embedded systems in C and assembler. I would often wonder "wouldn't it be amazing to be able to execute this APL statement in one clock cycle, like some of these assembler instructions on this tiny little MCU?". Anyhow, let's end this on a positive note. Here's a list of language improvements I authored a long time ago. This list isn't exhaustive (it was a five minute stream of consciousness exercise). Also, some of what's on this list might already exist in modern variants of the language. Feel free to criticize, no problem, and comment. Understand I am issuing advance notice that this is not a perfect list or even a current one. APL should go FOSS or adoption will forever be limited to esoteric high-ROI applications where it might make sense or legacy APL code already exists. The option for compilation would be very interesting. Within a function, variables are global by default. Huge pain in the ass. Objects. Yet be careful to avoid the mess OOP can (and often does) become. A language-defined interface to C (or some other suitable language) for when you need to speed things up. Inline C or Python, or both, as a first class citizen. Make it first hybrid high level language. An extension to nested arrays that allows you to create C-like structures. I am going after the self-documenting nature of having structure members have name-based access. An extension to function definition to allow for more than two arguments. This would require a little language re-thinking. I would also look into making a hybrid that includes some C-like syntax with an APL core. C/C++ -like comments and conditionals with bracketed groupings of APL code would go far in making code easier to read and organize. Native C-like switch() primitive with APL-inspired extensions. For example, switch could take a vector argument. APL-run-time-definable comparison operator. Sometimes I want to apply a complex evaluation function to data rather than the simple equal, not equal, grater/less than, etc. operators. The ability to enforce data types if desired. A means of telling the compiler/interpreter to optimize code --at the statement level-- for speed or resource (memory footprint) and other criteria. Certain operations can explode into huge multidimensional memory-sucking arrays which isn't always the best idea. Real-time extensions integrated into the language. Ability to use and request GPU resources for computation. Ability to use and request CPU cores for computation. A simple-minded example of the above two would be wrapping a code section with "CPUn{}" or "GPUn{}, where "n" is the core or GPU number. Standard interface for custom hardware-based acceleration (read: custom FPGA boards). FPGA's are amazing, make them first class cititzens. True binary vectors and arrays. More flexibility in multidimensional array indexing. A rethinking of the workspace model to better support multi-developer environments. Genetic and Evolutionary computing primitives built into the language. Neural Network primitives built into the language. Language native image processing (think OpenCV integrated right into the language as a first class citizen) Same with NumPy. APL should be able to do all of this and more. Built in primitives for multi-threaded/multitasked computing. Built in primitives for network access and processing. Built in primitives for multi-core and distributed computing. Built-in primitives for data exchange. For example, ingest or output nested array data from/to JSON, SQL, XML or other modern data formats. Better pattern-matching primitives. I'm thinking at least regular expressions. A general cleanup of the notation to remove lame text-based "fixes" from an era when rendering non-ascii characters required custom ROMs on the graphics card. All APL notation should be symbolic. ASCII should be limited to strings, function, variable, object and other constructs that require text. I'm talking about a lot of the quad stuff, etc. Make it open source and make the open source version far superior to any available commercial version. I'll end with a slightly edited portion of one of my HN posts from about seven years ago: One of the reasons I abandoned languages such as APL, Forth and LISP, languages that I used extensively for many, many years is that they became less and less practical and relevant. I can apply C to nearly everything from embedded to workstations/servers and even in modern hybrids where FPGA's are integrated with capable microprocessors. I can hire people, even entire teams, both locally and around the world to work on anything from embedded to web projects in many of the the C-like languages. Trying to do the same with APL, Forth or LISP is very close to impossible (and the quality and capability choices you have are much reduced). On the hardware front languages like Verilog are very reminiscent of C and, as long as you understand that you are actually describing hardware and not writing software, are easy to pick-up with the appropriate background. You move up to languages such as C++ and other layers open up. PHP, Python, Objective-C when I absolutely must and Java if I have no choice. All of these are very flexible and relevant tools that have, for the most part remained relevant and useful for years. This range of applicability will never be achieved with something like APL. If an APL-like language is going to come to the forefront it will be for very specialized applications where it makes sense. It will not be to run a shopping cart on a website or control a servo on a robot. That's just reality. I love APL. I devoted a huge chunk of my professional life to it. I can't see using it or the wanna-be variants for anything today. Sorry.