4 ms·

> 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

by jdc 13y ago

> 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?

robomartin 13y ago
> 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. Like I said, I've been away from APL for a while. I am sure there are a lot more important enhancements I could suggest if I spent a year seriously getting back into the game. Today I have very little use for APL outside of using it as an advanced calculator of sorts, mostly when I do hardware design. Even then, sometimes it is more convenient to use Excel for that purpose because of the value in being able to communicate with others.
- beagle3 13y ago
  K answers quite a few of these (multiple args, multithreading, network built into the language, and automatic SSE/AVX use to name a few). 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.
  - robomartin 13y ago
    I'll look up the language. I never spent any time on it. I have to say that I am somewhat of a purist when it comes to the idea (and real power) of notation. If we are going to evolve computing we need to try to move away from trying to fit everything into some mutation of an ASCII bag. I am not proposing graphical programming, been there, done that, it blows. However, a carefully done true language (meaning something with a unique and concise notation with which to express ideas) could be incredibly powerful and evolutionary. 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 This tells me that K was written to fit APL functionality into and ASCII character set. I get it. I understand where some of that came from around that time. As I said before, it was hard to display and generally deal with non-ASCII character sets. K was created around the time of Windows 3.0. It was still the wild west. I can totally see wanting to have the same level of abstraction with easy-to-deal-with ASCII transliterations. The problem is that this is absolutely going in the wrong direction. Notation (symbols, icons) are incredibly powerful and are at the core of some of APL's ability to become a tool for thought. 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.

by jdc 13y ago

robomartin 13y ago

> 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. Like I said, I've been away from APL for a while. I am sure there are a lot more important enhancements I could suggest if I spent a year seriously getting back into the game. Today I have very little use for APL outside of using it as an advanced calculator of sorts, mostly when I do hardware design. Even then, sometimes it is more convenient to use Excel for that purpose because of the value in being able to communicate with others.

beagle3 13y ago
K answers quite a few of these (multiple args, multithreading, network built into the language, and automatic SSE/AVX use to name a few). 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.
- robomartin 13y ago
  I'll look up the language. I never spent any time on it. I have to say that I am somewhat of a purist when it comes to the idea (and real power) of notation. If we are going to evolve computing we need to try to move away from trying to fit everything into some mutation of an ASCII bag. I am not proposing graphical programming, been there, done that, it blows. However, a carefully done true language (meaning something with a unique and concise notation with which to express ideas) could be incredibly powerful and evolutionary. 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 This tells me that K was written to fit APL functionality into and ASCII character set. I get it. I understand where some of that came from around that time. As I said before, it was hard to display and generally deal with non-ASCII character sets. K was created around the time of Windows 3.0. It was still the wild west. I can totally see wanting to have the same level of abstraction with easy-to-deal-with ASCII transliterations. The problem is that this is absolutely going in the wrong direction. Notation (symbols, icons) are incredibly powerful and are at the core of some of APL's ability to become a tool for thought. 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.