3 ms·
The idea appears to be that array languages have builtin functions for operations that would require map/reduce/etc in the applicative programming paradigm. I a
by crowding 14y ago
The idea appears to be that array languages have builtin functions for operations that would require map/reduce/etc in the applicative programming paradigm. I agree that is convenient, but the downside is that only array operations that are supported this way are the ones that are anticipated by the language designer. If you want to split up an array in some way other than intended, you're back to applicative programming, so your language needs good support for that too.
I would argue that the more important thing that makes something an "array language" is that scatter/gather operations on arrays have syntactic support, as described here:
http://prog21.dadgum.com/141.html http://prog21.dadgum.com/141.html
As a personal anecdote: In my thesis work I switched most of my data analysis workflow from MATLAB to R. In terms of paradigms I'd say R is a slightly worse array-language (although it does have builtin syntax for things that require messing with sub2ind() in MATLAB) but a much better functional language than MATLAB. The empirical result is that I finished my first analysis project -- including the time it took to learn R -- faster than it had taken me to do a similar task in MATLAB, using 1/3 the code. Add to that that there is presently more active development of open graphics and statistical analysis libraries in R, and I haven't really looked back, though I occasionally think of picking up an APL-derivative like J to play with.
- kd0amg 14y agothe downside is that only array operations that are supported this way are the ones that are anticipated by the language designer. … I occasionally think of picking up an APL-derivative like J to play with. You really should -- it provides a nice counterexample to the "downside" you worry about. Having mapping over arrays (even with mismatched dimensionality) built into the mechanics of function application means that any function the programmer writes is automatically supported by the array mapping.
- batista 14y ago>The idea appears to be that array languages have builtin functions for operations that would require map/reduce/etc in the applicative programming paradigm. I agree that is convenient, but the downside is that only array operations that are supported this way are the ones that are anticipated by the language designer. If you want to split up an array in some way other than intended, you're back to applicative programming I can't see why this should hold for all array languages in general. If the language has some mechanism to let you add new operation that are on the same "class / level" as the built-ins, then the above does not hold.