More like Excel killed APL. APL was mainly used by "domain experts", i.e., people who were not software engineers. According to Dyalog's YouTube videos, APL is still there for these people who started doing spreadsheets way before anything like Excel was available.
Accounting and planning people, who use Excel today, were never APL users.
APL was popular in the operations research community, and those people are now mostly R users (but they left APL to SAS, Stata, S/S+ and a few others through the years, before adopting R)
This is part of the open-access Proceedings of the ACM on Programming Languages, so it would be available anyway; but just a reminder that the entire ACM DL is available free to download until June 30: https://www.acm.org/articles/bulletins/2020/march/dl-access-... .
That remains unclear. Similar to q/k4/kdb, it's optimized for fin-tech database work; that is, operations on very long columns. Apl (esp. dyalog) and j have proper multidimensional arrays, which means that e.g. matrix ops are practical/easier. They also have better tacit programming support.
For a multidimensional array: a matrix will be in stored single vector with metadata showing dimension. The presentation of the matrix (view) will then not matter on the data contained therein.
For q, they are stored as lists of lists, which can mean that their memory is not contiguous. Some algorithms can slow down significantly as a result (eg dense), others might speed up (eg sparse)
However, there are libs in q such as qml which interface with LAPACK and are doing memory mapping so it is not entirely q, just an interface to a C implementation
Are you sure they're not stores in contiguous memory? Q features a crazy number of optimizations for special cases. I would imagine a dense representation of rectangular nested lists is one of them. Q code uses flip (flips a list) and requires it to be rectangular. Moreover, I highly highly doubt column vectors are stored as a bunch of pointers to a single element list. I just can't imagine Whitney ever tolerating such obvious inefficiency.
Looking at the link, Q is only 10% slower for big matrices. I can't imagine this being possible without major optimization on q's part since lapack is insanely optimized.
It is interesting to speculate about how a technology affected the zeitgeist, and directly or indirectly influenced subsequent work. My first programming language was APL, and it profoundly influenced how I think about programming. Lately I have been using numpy, and it feels awfully familiar to me! The authors of numpy acknowledge the influence of the APL/J school of thought on numpy. Have other people noticed the deep similarities between numpy and APL? (I will admit, words attributed to C.A.R. Hoare about Algol 60 have come to mind frequently: "Here is a language so far ahead of its time, that it was not only an improvement on its predecessors, but also on nearly all its successors.")
Have you seen matlab/octave?
It appeared in 1984, quite a bit earlier than numpy, and is atill widely used today, introducing a large number of people to the wonders of array programming.
22 comments
[ 3.6 ms ] story [ 54.2 ms ] threadAPL was popular in the operations research community, and those people are now mostly R users (but they left APL to SAS, Stata, S/S+ and a few others through the years, before adopting R)
Incidentally, the issue from which this comes is called "No. HOPL": https://dl.acm.org/toc/pacmpl/2020/4/HOPL. I'm not sure if it's in place of, or in addition to, HOPL IV which was postponed: https://hopl4.sigplan.org .
Downloading PDF from Archive.org does not require cookies.
https://web.archive.org/web/20200612214124if_/https://dl.acm...
For q, they are stored as lists of lists, which can mean that their memory is not contiguous. Some algorithms can slow down significantly as a result (eg dense), others might speed up (eg sparse)
However, there are libs in q such as qml which interface with LAPACK and are doing memory mapping so it is not entirely q, just an interface to a C implementation
http://althenia.net/qml
Looking at the link, Q is only 10% slower for big matrices. I can't imagine this being possible without major optimization on q's part since lapack is insanely optimized.