Why has the array paradigm, which emerged in the 1950s and 60s amongst mathematicians, and which underpins certain programming languages, apparently failed to capture and maintain interest amongst mathematicians as a foundational innovation in their field, despite tacit applications of the principles being widespread?
The long read
As an analyst and a programmer working in industry, conventionally I would be considered an IT professional, but I tend to consider my real profession to be that of administration.
Administration has a longer history than computing, both as an occupation, and as a focus for systematic study. A bread and butter activity in administration is what would nowadays be expressed as the storage, maintenance, and processing of data.
In my view, it's a peculiar feature of administration (despite its extensive handling of numbers as well as other kinds of information) that the mathematics involved are rarely regarded as difficult, whether by mathematicians or anybody else. IT professionals are rarely expected to have more than a basic knowledge of conventional mathematics.
Complexity arises in administration largely because mathematics as practised here, is a mathematics where calculations often consist of a long series of simple operations, carried out by multiple people in different places, and on a schedule that is often ill-defined and unreliable.
These challenges of calculation are unfamiliar to the academic mathematician who works at the blackboard, and who does not routinely do a third of the calculation now, a third over the road, and a third next week. Indeed these challenges are alien to students, in almost all educational settings where mathematical knowledge is reproduced.
Another feature of mathematics as practised in administration, much more pertinent to the question I will arrive at, is that it is frequently concerned with operating on multiple "values" - that is, multiple items of data, or put another way, arrays of data. Exactly how such arrays of data are arranged for storage and movement, as part of what is essentially a process of constant calculation, is a central concern.
There is however no standardised treatment of arrays in conventional mathematics. No standard notation. No standard battery of operations. No algebra.
Don't get me wrong, I'm aware of statistics, and calculus, and matrix multiplication and it's associated notation, but these areas are not regarded as uniform, and they are not regarded as elementary (that is, not in a way that is commensurate with how administration is considered to have elementary aspects that all citizens of a society like ours ought to be familiar with, and handling arrays of values are undoubtedly elementary in administration).
The notation for the "binary iterated operations", like sigma for summation and pi for the combined product, are probably the closest one comes, and the notation is in a class of its own. Again also, it is not regarded as elementary mathematics (as would be on a school curriculum with addition and multiplication), despite the ubiquity of summation in daily life.
For reasons that are certainly obvious once one explicitly acknowledges the close connection between computers and the field of administration, all the innovations in this area have been in computer science.
The SQL programming language is underpinned by "relational algebra", work done in the 1960s at IBM by British mathematician E.F. Codd, and published in 1970, which (amongst other things) defines a simple array model consisting of "tables", a set of operators which accept tables as operands and manipulate them to produce a table as an output, and which operators obey algebraic principles. Codd himself used a maths-like notation for his work, but SQL then resulted from work by ergonomics and usability experts to ease the notation.
SQL remains in ubiquitous use today, and many IT professionals who use it routinely will know of Codd.
It's worth mentioning in passing however, that amongst syllabuses I've seen on the "relational model", many revert to using Codd's notation (and some of his awkward vocabulary too) which is completely superseded by SQL, and such syllabuses do not succeed in giving a general introduction to arrays and array operators.
There was also a period in the past 20 years, though now seemingly over, when SQL became the subject of a lot of negative hype about its own complexity and user-unfriendliness, and even in the 90s it was often regarded as mind-bending by many programmers of conventional languages.
One imagines that this could be related to consistent poor tuition of the SQL language, and failure to reproduce the mathematical concepts which underpin it (since it is definitely a form of mathematics, but one which is specifically designed to operate on arrays of values).
A now much-lesser-known figure from the same era as Codd, and publishing some years prior, is the Canadian mathematician and later computer scientist, Kenneth E. Iverson.
People familiar with mathematics may be most familiar with the notation of the ceiling and floor functions which Iverson devised: $\lceil x \rceil$ and $\lfloor x \rfloor$, respectively.
Most of Iverson's academic and industrial career however was dedicated to a programming language called APL. Devised originally by him in the 1950s as a terse, pen-and-paper notation for describing algorithms, and intended to augment and improve upon the standard mathematical notation available, some of it's main innovations were a large set of brand-new mathematical symbols, and it's incorporation of an array model (with operators and notation).
In the 1960s, it found an immediate niche for interactive use on early computers based around a teletype machine. For the unfamiliar, a teletype is a computer terminal which resembles a standard typewriter, having a keyboard for entry, and a computer-controlled printer mechanism for output, but no monitor. Interactive use means you type input and immediately receive output, via the printer - step-by-step like a retail till printing items on receipt paper.
Being so terse allowed a teletype operator to do a lot of ad-hoc numerical computation quickly with such limited hardware, and IBM made a significant investment in APL at the time, primarily to cater for financial applications. The symbol set was tailored to what a daisy-wheel printer of the time could output, and a custom keyboard was designed for input of the same symbols.
What distinguishes APL from SQL (with the latter's basic tenet of a 2-d tabular model), is that the arrays in APL need not take the form of "tables", and there are thus a more extensive complement of operators in APL which are not designed to process the values in arrays, but instead to change the structural arrangement of those values within the array, or to influence the order or the axis of the array which an operator acts upon (for example, the distinction between summing columns or summing rows).
Only a sniff of such complex functionality has been introduced into SQL, with its so-called window/analytic functions. But one never sees the implied, non-tabular intermediary results which these operators must generate internally, and they cannot be explained within the tenets of Codd's relational algebra. They can only be described within a more general array model.
Unfortunately, the symbology and the way in which APL notated and parsed expressions, in conjunction with its other innovations, became infamous in computer science. Influential Dutch computer scientist, Edsger Dijkstra, ridiculed the APL language as "a mistake, carried through to perfection". Others condemned it as "write-only code".
By the end of his career in the late 80s, Iverson had unequivocally recognised the strategic mistake of the non-standard symbology, which made it difficult by then to represent APL on standard PC hardware, and imposed a learning curve in terms of being able to pronounce and remember the functionality of utterly unfamiliar symbols. The terseness also became less important than it had been with a teletype interface.
But adjustments to the notation failed to reinvigorate the APL language, which exists now only in small niches. Only SQL has emerged vital in the modern day, and like I say, not without enduring a period of negative hype, and not without most users struggling with its conceptual underpinnings.
For those who have tolerated this tome of historical context so far, my question is this.
Why has the array paradigm, which emerged in the 1950s and 60s amongst mathematicians, apparently failed to capture and maintain interest amongst mathematicians as a foundational innovation in their field, despite tacit applications of the principles being widespread?