History: Array languages

This has got to be one of the sparsest language families. The classics are APL, APL2, A+, J, and K, which were developed in that order and have entangled histories. Nial is the dark horse. Glee is the newest. Nesl is a parallel array language. Then there's the programming language of Mathematica, which supports array operations.

Surely there are more?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

FISh

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

SAC

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.

History clarification

"History" as in, "all array languages ever created, both new and old."

More

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?

Lisp vendors

This page lists ten vendors.

10 vendors

Thanks but that's pretty much the point. APL has a reputation for being obscure and dead whereas Lisp could be called the most mainstream of non-mainstream programming languages. Yet here are about ten current array language implementations, most of different languages or APL dialects, as many as for Common Lisp. That's evidence of vitality, I would say, and I don't understand why the original poster called array languages "one of the sparsest language families".

There's also MatLab, by the way.

And Maple too

Maple in fact has more Array types than all the usual array languages - but also offers a uniform access mechanism to all those types.

What other language allows you to deal with banded symmetric matrices of 8 bit integers in C order storage as easily as with sparse complex hermitian hermitian matricies of 10000 Digit complex floats in Fortran order storage? All with optimal space and (often) optimal algorithms for particular sub-classes.

Disclaimer: I used to work for Maplesoft, although am now in academia.

What other language

Maple is a great package, but Mathematica 5 meets that challenge, down to the particular sub-classes. Have a look.

Maple/Mathematica

Comparing the history of both these packages is fascinating. In part because they are both commercial but neither are overwhelming market leaders, there is pretty healthy competition going on. Each of Maple and Mathematica are ahead of the other in some areas, and quite behind in others, while being essentially equivalent for most purposes. Whenever one side comes up with some real useful features, within a few releases the other side has that too.

One of these days, if someone prods me, I'll write up a short (ongoing!) history of feature innovation in both these products. It really is fascinating.

Re: More

Among the classics you left out APL2000, Dyalog APL, Sharp APL and MicroAPL

Isn't that somewhat like listing various flavors of Lisp as different languages? Regardless of the vendor and vendor-specific extensions, they're all Lisp.

Wikipedia on array languages

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

Why not more array languages?

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.

How to solve problem #3

My toy language Moiell solves problem #3 by making a difference between lists and sequences. A sequence is 1,2,3, and a list contains one sequence. Sequences always flatten, lists don't. So f(1,2,3) calls f 3 times, but f([1,2,3]) calls f only once.

Lush and Numarray

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.

there are a few

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.

Some more ...

What about relational languages

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?

Numerics are neglected by most languages

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).