Consider the lone factorial problem: Every array programmer will do some kind of the product of, one plus array of all ints up to x
apl: ×/⍳X
q: prd 1+til x
j: */1+i.x
k: */1+!x
Notice how similar they are?
Now, how do you solve this problem in Fortran? In Python? In R? In Matlab? What's the first tool in your toolbox? Is it to iterate over the values?
FUNCTION FACT(N)
INTEGER N,I,FACT
FACT=1
DO 10 I=1,N
10 FACT=FACT*I
END
def fact(n):
result = 1
for i in range(1, n+1):
result *= i
return result
function b=fact(a)
b=1;
for i=1:a
b=b*i;
end
function fact = iter_fact(n)
fact = 1;
for i = 2:n
fact = fact * i;
endfor
endfunction
fact <- function(n) {
f = 1
for (i in 2:n) f <- f * i
f
}
If the native programmer's first impulse looks something like that, then it's not an array language because the programmer isn't thinking in terms of arrays.
I wonder if some of the popularity of "functional" in imperative languages is that it lets you put this sort of stuff together without needing an "array language". In python it's pretty easy to
(albeit with some imports, and note range is [begin, end) so that's 4!, not 5!). It might not be the first thing a Python programmer does, but it's certainly reasonable. Haskell of course is
Prelude> foldl (*) 1 [1..5]
120
(inclusive this time, hence 5!) which is only slightly more verbose than the "array" languages, but does have the advantage of clearly specifying what your base case is if the list is empty.
Perhaps array languages are just getting subsumed as a special case of "functional programming", be it either the relatively weakly-guaranteed FP that gets embedded into otherwise OO/imperative languages or Haskell's stronger-guarentees FP.
It's worth noting that the behavior is totally different if you pass higher dimensional matrices. The Fortran, Python, Haskell, etc. code will all break or fail to typecheck, whereas the APL/J/K implicitly maps over them. Understanding this topic ("rank") is a major source of confusion for new users and power for existing users, as lots of different mapping regimes can be obtained without a lot of additional operators.
The rank operator in J (and probably Dyalog APL) allows you to treat a 3D matrix as an array of 2D matrices, a 2D matrix of arrays, a single item or a bunch of unit-sized boxes. This concept generalizes to higher dimensions. I don't think this aspect of array programming has gotten as much airtime as it deserves, probably because it is complex, but this is where the semantics of array languages and conventional languages really differ.
It seems to me that mathematical higher dimensional matrices are, in the broad scheme of programming languages, a corner case. Certainly a big one and an important one, but not one that was ever likely to drive general purpose languages.
Indeed, I'd argue that if that was your primary use case you are and always were better off with a relatively custom language (relative to programming as a whole), because the needs are so different and the wins so big using an environment set up to support those needs that you'll want that in the end. You can fuzz the line with things like NumPy, because all these lines are fuzzy, but dedicated support will be a big win in the end.
I think it's kind of a chicken-and-egg question, personally. Compared to array languages, most other programming languages are, in a sense, tree-oriented. Does their prevalence mean that our problems are mostly tree-structured? Or is our propensity to see problems as tree-structured a result of brainwashing by our tools? "A prisoner falls in love with his chains" as Dijkstra said.
But I wouldn't call Julia an array programming language. Not everything is an array, there are scalars too, and vectors (vs matrices) are very special arrays that exhibit the expected duality properites (since 0.6)
It's kind of crazy to think of Matlab as not an array programming language since the array is literally the only data type.
Here is a Fortran 95 program to compute the factorial of 0 through 5. The factorial can be computed as the product of an array created on the fly, without an explicit loop.
program xfact
integer :: i
print*,fact([(i,i=0,5)])
contains
elemental function fact(n)
integer, intent(in) :: n
integer :: i,fact
fact = product([(i,i=1,n)])
end function fact
end program xfact
program xfact
integer::i
print *, fact ([(i, i = 0, 5)])
contains
elemental function fact (n)
integer, intent (in)::n
integer::i
fact = product ([(i, i = 1, n)])
end function fact
end program xfact
I like that definition! Not least because it means Futhark qualifies as an array language: i32.product (map (1+) (iota n)). I have also heard the more fundamentalist definition that if you have to say 'map', then it is not an array language.
Consider the lone factorial problem: Every array programmer will do some kind of the product of, one plus array of all ints up to x
Notice how similar they are?Now, how do you solve this problem in Fortran? In Python? In R? In Matlab? What's the first tool in your toolbox? Is it to iterate over the values?
If the native programmer's first impulse looks something like that, then it's not an array language because the programmer isn't thinking in terms of arrays.