From: andrew@rentec.com (Andrew Mullhaupt)
Newsgroups: comp.lang.apl
Subject: Re: APL and IDL
Date: 16 Nov 92 16:32:57 GMT
Organization: Renaissance Technologies Corp., Setauket, NY.

In article <16946@umd5.umd.edu> jph@astro.umd.edu (J. Patrick Harrington) writes:
>
>  When I first looked at IDL (Interactive Data Language), which is becoming
>the language of choice among astronomers for data reduction and image processing
>tasks, I was struck by the similarity to features of APL. In the latest manual
>they make it quite explicit: From the "IDL User's Guide" Version 3.0, Sept 1992:
>
>"IDL owes much of its semantics to the programming language APL. The power
> and conciseness of IDL is due to this APL influence. The main departure
> from APL is in syntax and in control mechanisms. Because scientists write
> their formulas using infix notation with parentheses, IDL has an expression
> syntax that resembles FORTRAN or BASIC, where infix operators are evaluated
> according to precedence and left-to-right sequence. ... "
>

You could say that S is an APL type interpreter with syntax based on C.
I'll interpolate your IDL lines with S to show the similarity:

>Here are a couple of lines of IDL dialog:
>
>IDL> a= findgen(10)

S> a <- 0:9

>IDL> print, a
>      0.00000      1.00000      2.00000      3.00000      4.00000      5.00000
>      6.100000      7.00000      8.00000      9.00000

S> a
 [1] 0 1 2 3 4 5 6 7 8 9

>IDL> b= 0.2 * a

S> b <- 0.2*a

>IDL> print, b
>      0.00000     0.200000     0.400000     0.600000     0.800000      1.00000
>      1.20000      1.40000      1.60000      1.80000

S> b
 [1] 0.0 0.2 0.4 0.6 0.8 1.0 1.2 1.4 1.6 1.8

>IDL> c= sin(b)

S> c <- sin(b)

>IDL> print, c
>      0.00000     0.198669     0.389418     0.564642     0.717356     0.841471
>      0.932039     0.985450     0.999574     0.973848

S> c
 [1] 0.0000000 0.1986693 0.3894183 0.5646425 0.7173561 0.8414710 0.9320391
 [8] 0.9854497 0.9995736 0.9738476

>
>You see that  findgen <-> floating index generator <-> iota <-> i.
>
>It is interesting how the IDL developers acknowledge their debt to APL. The adoption
>of the ideas in APL is a good thing for users, but probably a bad thing for APL, as
>some of these features will no longer be unique to APL. Of course APL (and J) can
>do so much more, but the potential audience for the "more exotic" features is not
>as broad.
>		    

S has been available from AT&T since the late '70's.  It does `more' than APL
does, but a lot of its exotic features are not obviously desirable. There are
a bunch of these type of languages out there and they all generally suffer from
not being as well implemented as APL interpreters. However, almost all of them
avoid the runic confusion of APL and its cousins, and some provide really high
bandwidth interfaces to compiled code. (This is the most redeeming feature of
S). There are also more sophisticated interpreters than APL out there, such
as Maple and (when it works) Mathematica.

As for operations like these on arrays, you can do that in standard FORTRAN 90
and C++ and in standard Pascal. (Remember that the Pascal standard changed in
1990!)

So there hasn't been much uniqueness to this kind of feature in APL for a long
time. APL is certainly of tremendous importance in the history of programming
languages, but in its purest form, the APL ideas are not the answer. Generally
the problems people have with APL are related to the triage which is forced
between clarity and speed.

Later,
Andrew Mullhaupt
Newsgroups: comp.lang.apl