> While the language is wonderful I would not use it for production systems today. It is my opinion that the language came to be too early and, as a result, has not seen innovation for decades.
What APL need that only more modern languages have?
What APL need that only more modern languages have?
Let me preface this by saying that I've been away from regular use of APL for years. I've forgotten a lot of the details but I'll throw out o few seat of the pants thoughts on this.
In no particular order (and not specifically related to modern languages):
The option for compilation would be very interesting.
Within a function, variables are global by default. Huge pain in the ass.
Objects.
A language-defined interface to C (or some other suitable language) for
when you need to speed things up.
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
arrays which isn't always the best idea.
Real-time extensions integrated into the language.
Ability to use GPU resources for computation.
Standard interface for custom hardware-based acceleration (read: custom
FPGA boards).
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.
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.
Make it open source and make the open source version far superior to
any available commercial version.
K4 is a much simpler and smaller language than APL - and yet the programs come out simpler and shorter, and usually much faster. Unlike APL, it can be tokenized and parsed in advance -- meaning that, at least theoretically, a compiler can be written. Arthur's implementation is a bytecode virtual machine, but AFAIK there is no type inference there.
e.g. there are only 3 conceptual data types in K4: atom, list=array=vector, and dict. A matrix is a vector of vectors (what APL would call a nested vector), vastly simplifying APLs nested and axis operators.
A quick comparison of the code necessary to calculate all primes up to a limit in K and APL:
(!R)@&{&/x!/:2_!x}'!R
(2=+⌿0=(⍳X)∘.|⍳X)/⍳X
I feel the same way about languages such as ObjectiveC. Another abomination. There was no reason to do that. Nothing whatsoever was gained by saying: "Hey, let's do the same thing but come up with a different way to write it." Sure, O-C has a few nice things here and there but it did not advance computing in any appreciable way as far as I can identify.
As for the other extensions you listed come with K, that's probably great. I'd have to dive deeper into the language in order to offer even a superficial opinion on that.
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 system work and even in modern hybrids where FPGA's are integrated with capable microprocessors. 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. That 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 my 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.
e.g., the first element operator is unary asterisk e.g. "x", which is like C's pointer dereference (which gets the first element ..). There is no symbol for "last element" - instead you use "|x" meaning "first of reverse of x". Similarly, there are no compress/expand operators; Instead, there's a "replicate" operator which unifies and simplifies both (and has other uses to boot).
In fact, it looks like Arthur used the number of ascii symbols as a constraint for the number of primitives - which are all single characters. (They can be postfixed with a colon to force monadic comprehension, but that's not part of the operator). As a result, K is as much notation as APL is. The domain is "writing real world programs" instead of "expressing algorithms", and it shows, but it's still notation that -- once acquired -- reads like math or APL.
> 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 suspecting it's going to make a come-back. The APL / J / K computation model is much easier to apply to GPUs. But prediction of trends is very hard -- doubly so when it is about the future :)