Lambda the Ultimate

FISh claims that FISh execution speeds on typical array problems are several times faster than other higher-order, polymorphic languages.

I'm confused about your post. The subject starts with "History", but the message refers to recent languages. If you include Mathematica, because it supports array operations, the family is not sparse at all.

On a more constructive note let me mention SAC - Single Assignment C. This is a functional language for numerical applications, in particular array processing.

Among the classics you left out APL2000, Dyalog APL,
Sharp APL and MicroAPL. F-Script probably fits the
bill as an array language, too.

You seem to imply that this is a short list but if you
consider that most of the languages mentioned so far
are commercial (i.e., all except SAC, F-Script and A+
but the latter got its start as a proprietary language
in use at Morgan Stanley), that is a rather long list.
Quick: how many commercial Lisp vendors are left?

There's a good list of array languages here, including some I'm not familiar with.

Some thoughts on why array languages aren't more prevalent.

1. Most major programs that make significant use of arrays (and would benefit from array constructs there) also make use of significant other features where one wants a more polished, complete, or mainstream language than array languages.

2. Most programs that use arrays don't do anything that's difficult to do with existing languages. For example, if you deal with fixed-size vectors and matrices, then you just write a few functions for array-matrix multiplication and then you build your program on top of that.

3. There are reasonable theoretical arguments against some of the common features of array languages. For example, given a function f:t->u, some array languages automatically let that function operate on arrays, for example as if it's overloaded to f:[t]->[u]=map(f), etc. This is incompatible with Haskell-style polymorphism. For example, given a function reverse:[t]->[t] which reverses an array, and a value a::[[t]], there are two different ways one could interpret reverse(a), and this is confusing. Similar combinatorical ambiguities occur with automatic currying (treating any f:(t,u)->v as f:t->u->v , etc.

There is also
Lush, a dialect of Lisp whose centerpiece is an array processing engine. With it's Lisp syntax, it is less array centric than APL derived languages, but is still quite effective tor applications that require maniuplating large arrays of data. Lush is FLOSS, available under the Gnu GPL at Sourceforge.

Nummaray is an array processing package for Python. It allows efficient processing of large arrays of data with a simple Python syntax. Matlab and Mathematica have been mentioned elsewehre.

The extreme terseness and array orientation of the classic APL family of languages makes for a steep learning curve which limits their appeal. They aren't always easy to apply to non-array oriented problems. I don't think the array processing barch of the language tree is really that sparse, just not well known.

i think you missed:

• C*
• SISAL
• ZPL
• Matlab

at the very least. while these are all great if you are solving PDEs, systems of linear equations, etc., its really a bit of work to apply them to other problem domains. still, this thread unfortunately has mostly died, and people who do work in those domains are worse
off for it.

... I've come across.

While not "array" langauges per se; the various relational languages (SQL, Tutorial D, Business System 12) operates on sets and the like. If not siblings of APL, perhaps these are at least cousins?

I do research in a field that requires fast numerics (linear algebra). I use Matlab because it offers a very productive development environment (a REPL and a concise language that maps onto the problem domain), and gives simple access to LAPACK.

One of the problems with the more open languages and development environments (e.g. Python) is that support for numerics has to be 'bolted-on' as an afterthought.

I would encourage the designers and implementers of new languages to seriously consider making numerics a first class citizen of the language. People *really* do need to do this stuff, e.g. for: scientific computing; 3D games; image, video and sound manipulation. Yes, some of these tasks can be offloaded to GPUs and DSPs, but this is often impractical and undesirable.

Simply providing access to LAPACK and supplying a convenient syntax, as a core part of the language, would undoubtedly attract many to consider the more 'academic' languages.

If integers, floating point numbers, lists and tuples may be first class citizens of languages, then surely so must vectors, matrices and multidimensional arrays. We really do need to operate on these data types on a routine and efficient basis (as evidenced by the AltiVec unit and forthcoming Cell architecture), and to do so within a comfortable environment (i.e. the language, not afterthought libraries).