Website van Eke van Batenburg

If development in APL is so fast, what is the secret? Several characteristics of APL contribute to this speed of development:

• APL is an interpreter. At any moment and at any program line one can interrupt execution, query local and global variables, try out alternative modules or expressions, correct erroneous program lines and continue execution at any suitable place.
• APL has powerful functions. APL has many powerful functions that you may not need for every application but that come in handy when you need them (for example matrix inverse, many trigonometric functions and their inverses, sorting, searching and many others).
• APL is problem oriented, not machine oriented. APL screens you from machine quirks. For example, there are no type-declarations, APL takes care of truncation errors in comparing results of expressions and many expressions don't need element by element specification (explicit loops).
• APL is concise. APL uses (suggestive) symbols for its operations. So APL programs only need a very small amount of keystrokes. This not only accounts for quicker typing, but more importantly for very concise programs. This makes APL programs very comprehensible. One can see and understand rather complex operations in a glance. Experienced APL programmers learn to recognize idioms, small sets of functions that perform complex operations but are recognized as one "gestalt".
• APL program development is fast. This seems a funny circular argument, but there is some logic in it. Because of it's speed and terseness, one APL programmer can do a job that needs a team when using a conventional language. A team always wastes time in communication and in repairing problems due to misunderstandings. This is missing in one-person APL projects.

All these characteristics make for very concise programs. For example if you need the sum of your data, you program in Pascal:

   VAR
      sum,ARRAY data[1..500] OF REAL
      i INTEGER;
   BEGIN
      WRITE('Number of data=..');
      READLN(n);
      sum:=0;
      FOR i:=1 TO n DO
         BEGIN
         READ(data[i]);
         sum:=sum+data[i]
      END;
      WRITELN(sum);
   END.

but in APL you simply program the sum of inputs (no need for loops) as:    ,
and the mean is also very tersely formulated as:   .

At the end of this what-paragraph we will tell in a nutshell about the birth of APL.

APL is an acronym for "A Programming Language". The language was designed by Kenneth Iverson in the sixties. His purpose was to develop an improved mathematical notation, as he considered conventional math notation not very consistent. Iverson was joined by Adin Falkoff, Larry Breed and Philip Abrahams. They set out to implement this notation as a programming language. In 1966 APL emerged as a computer programming language. This makes APL a rather old language along with old hands like ALGOL (1958), Basic (1965), COBOL (1960), Fortran (1953) and PL/I (1965). Notwithstanding its age, many ideas in APL are still unique, while others have found their way into modern languages.

Since 1966 APL has been implemented on many computers, mainly large mainframes like those of Burroughs, IBM and Siemens. Initially APL missed the proliferation of microcomputers because APL needed more power (storage as well as speed) than was available in those early years. Very few of those early microcomputers had APL; exceptions were Tandy's TRs90 and Commodore's PET. It was the rise of the more powerful 16-bits micro computers that enabled APL to settle commercially on microcomputers. Nowadays one finds APL on nearly all computers, whether micro, mini or mainframe.

In the eighties APL had a major extension: nested arrays. Up to then arrays always had scalar elements (numbers or characters). In the N.A. version (Nested Array version) each array-element can be an array itself (which in turn ....).

This N.A. extension does not infringe on the standard APL syntax. For example "5+AR" still adds five to all elements of AR, whether AR is a "flat" array of say size 5x10x20x30 elements or a nested array of say 3 elements with element 1 scalar, element 2 an array of 1000 elements and element 3 a 5x10x20x30 array.
Furthermore only a few function extensions were required to handle the increased power.

Research showed that APL's power increased substantially in the NA extension. Its already high Halstead score which was 3.07 for flat APL increased to 3.66 for N.A. APL as compared to 1.14 for Fortran and 1.53 for PL/I (see F.H.D. van Batenburg, E.deRidder, J.de Kerf (1998): APL extended compared with other languages according to Halstead's theory ACM Sigplan 1998, 33(6)54-60 ) .

APL is a programming language that enables extremely fast program development.

I would venture to state that this is the one and the best reason to use APL. Quick development is appreciated whether one is working commercially (where development time is money) or in science (quick programming leaves more time for science).

A second reason to program in APL is that one experienced APL programmer can handle rather complex problems on his own. No need to have a team where a lot of planning and communication is necessary and misunderstanding is inevitable.

Finally I have to confess there is a "soft" reason too. Personally it gives me a lot of satisfaction to develop a complex program in a short time, especially if it looks elegant. This is why I use APL. But this is not something that everybody should necessarily share.

APL is used over a wide spectrum of applications, varying from prototyping, administration, to science in a great diversity of applications, varying from data mining to mathematical applications such as actuarial use.

Recently the journal Quote Quad, the journal of the APL Special Interest Group of ACM (SIGAPL of ACM) started a column "WhatsWhere" with succinct descriptions of APL projects. See projects.

If the above information has made you interested to learn more about APL you can...

• consult the FAQ that is kept by Sam Sirlin for APL programmers Sam Sirlin APL FAQ or consult my "APL-novices"-FAQ (FAQ).
• download public domain APL (see section Public Domain APL).
• buy APL; contact APL vendors (see section Websites for APL).
• visit APL conferences (see section APL conferences & publications).
• subscribe to the APL newsgroup, mailinglist or to APL user groups (see section Websites for APL).
• subscribe to APL journals (see section APL conferences & publications).
• buy/read APL books (see section APL conferences & publications).

This section deals with questions that are frequently asked about APL.

It is useful to make a distinction between 2 types of questions.
Some questions are frequently asked by APL programmers, others by non-APL-ers or APL novices. For the first category (APL programmers), Sam Sirlin compiled questions with answers in an APL-FAQ. This is available at...

• home.earthlink.net/~swsirlin/apl.faq.html
• an older copy at: www.faqs.org/faqs/apl-faq/.

His FAQ deals with questions like...

1. Where can I find APL for machine X?
2. How do I use APL on an XX terminal connected to machine YY?
3. What about APL keyboards/stickers?
4. Can I compile APL?
5. What tools exist for APL?
6. Can I get an APL font for X?
7. What information exists online about APL?
8. How do I get book Y?
9. What good APL books exist?
10. What user groups exist?
11. What's the latest APL conference?
12. How do I pass APL functions from one APL to another?
13. How do I write APL using only ASCII?
14. Where can I find APL employment information?

Novices have quite different questions. Those that were asked to me most frequently....

1. Is APL code easy to read?
2. Is APL fast?
3. Is APL only for mathematics?
4. Is APL easy to learn?
5. Is APL expensive?

Yes and no.
First of all, yes, undeniably there is APL code around that is hard to read. Just as there is Basic code or Pascal code that is very hard to read.

However a careful designed and written APL program is no harder to read than one in Basic or Pascal.

The point is that one should compare programs rather than program lines. The misconception that APL is hard to read stems from the fact that people tend to compare program-lines. APL lines require much more time to read than lines in any conventional programming language. Because APL is so terse, one line of code can perform a complex task that may need several pages of Pascal. Subsequently, a naive reader is extremely disappointed that such a line in APL requires far more time to read than one line in Pascal. In general however, that one line of APL does not require longer to study than the several pages that Pascal needs for that same task.

An observation that also suggests unreadability is that APL programmers tend to give up reading an APL program quickly and start programming it themselves. This is not due to unreadability of the APL-code, but rather to the fact that one can program so quickly in APL.

So the answer is: In general APL code is more readable than code of a similar function written in a conventional language.

Again, yes and no.

APL is distributed as an interpreter. And interpreters are by definition slower than compiled execution modules.

On the other hand, APL programs are littered with "implicit-constructs". With this I mean constructs where you don't need to specify much code in APL (it performs that implicitly) but are required to code much explicitly in conventional languages. For example in APL one does not have to program loops explicitly when adding or multiplying multi-dimensional arrays ("+/array" and "x/array" is fine) and one does not have to program IF/ELSE statements explicitly when selecting data (using "replicate" to select as in "(data>12)/data").
Those constructs are fast because they do not have significant overhead for interpretation. Moreover, many array operations have been extremely optimized in the more than 30 years existence of APL.

So the answer is: In principle APL execution is slower than compiled code; in practice the difference is often negligible (and often irrelevant).

This is not true at all. It is true that APL is very powerful in its mathematical capabilities. So many actuaries use APL.
However APL is also very popular for prototyping, for "spidering" (being the central spider in the web that activates other COBOL, Fortran, SQL programs to produce data that are processed and pushed to another program) and for driving database systems.

So APL is used over a wide spectrum of applications, varying from prototyping, administration, science and commercial use from record keeping to mathematical applications such as actuarial use.

In order to illustrate this point, look at some projects that were published in conference papers and in Quote Quad journal.

So the answer is: APL is strong in mathematical fields as well as in other application fields.

Yes and no; it is true that APL is not the most simple language to learn.

It is not so hard to become a reasonable expert in Basic or Pascal. To become an expert in APL takes much longer. And to enjoy the fruits of developing so much quicker in APL than in Basic or in Pascal requires a minimal level of expertise.

However, this observation needs some clarification. To obtain the level of expertise in APL that is comparable to an "expert Pascal Programmer" does not require much more than it takes for the Pascal student; a bit more, but not much. However to harness more of the typical APL power that gives you the real advantage is harder. This is roughly shown in the graph where you see that APL is a bit harder to learn, but also that you can acquire much more power in the end.

So the answer is: APL is probably slightly harder to learn, but one can acquire much more power than one ever can do in a conventional language.

Yes, unfortunately current APL systems are fairly expensive; about US$1500 or more (see vendors).
Nevertheless, there are free APL systems. See "Public domain APL".

Similar to your film rolls that have a standardized "ISO"-speed, there is an ISO standard for the programming language APL too.
ISO (=International Standard Organisation www.iso.ch) betrothed IEC (=International Electrotechnical Commission). In 1987 they begot JTC1 (=Joint Technical Committee) for standardization of all things human, ranging from film speed, paper sizes to procedures.
The JTC1 formed a Standard Committee for program languages: SC22 (www.open-std.org/jtc1/sc22/); in SC22 several languages are represented by their own working group. WG3 is the Working Group in SC22 for APL standardization. This working group is chaired by Prof.L.J.Dickey (email: ljdickey@math.uwaterloo.ca).

In the Netherlands this WG3 is represented by the Nederlands Normen Instituut (www2.nen.nl/) where the language group is chaired by drs.W.F.Wakker (email: willemw@ace.nl).

Up to now the fruits of WG3 are :

• Classical (or "flat" APL) was standardized in 1989 and specified in the publication IS-08484.
• The standard with the nested array extension (N.A. APL) was finished in 2000.
  It is available at ISO and downloadable from www.math.uwaterloo.ca/~ljdickey/apl-rep/docs/is13751.pdf.

APL programmers can write fairly unreadable programs. This is not unique for APL programmers, but APL programmers are not better than any other programmer.

Writing very clear programs is an art. This art can be mastered by years and years of making bad mistakes. Another option is to learn from others who made many of such mistakes in the past.

The Dutch APL User Group decided to write down a number of suggestions that could help preventing such mistakes. This developed into the "ASWI programming standards for APL programs" written by F.H.D. van Batenburg, T.R.C.Bonnema, L.van Geldrop, H.van Loon and B.Smoor. It can be downloaded as an PDF document at "ASWI programming standards for APL programs". If you have any trouble in getting this document, please contact me by email and I will send this file as an attachment.

APL is a very powerful language. Nevertheless, there is room for improvement.
Old APL versions only had the GOTO for flow-control and no control structure. Modern APL versions have added the "usual" concepts: IF...ELSE, WHILE...END, DO...UNTIL and SELECT...CASE...ENDSELECT.
Unfortunately many vendors implemented these concepts using the verbose constructs from the conventional languages. Although APL needs better structural constructs than the mere GOTO, my position is that APL should not gratuitously copy the syntax from conventional languages but seek a more APL-lish implementation.

My favorite APL-lish implementation of structured control is one single function (baptised control) that uses the -symbol that is used for blocks since the early beginning of APL. This extension implements all necessary control structures in one: condition, alternatives, fixed repetition as well as while repetition.

Syntax of this proposed control is:

controlling_expression   <-- begin of 
                              control block
     ...                  <--- executable
     ...                       expressions
                         <-- end of 
                              control block

The executable_expressions are done as many times as the value of the controlling_expression dictates. This results into fixed iteration if the controlling expression yields an integer and into conditional execute if the result is either 1 or 0.
If the controlling expression yields a negative integer -m, it behaves like a while construction. At first the effect is similar as if the integer was positive (the executable_expression is done m times), but at the end the negative value forces APL to execute the controlling expression again. If that results in a 0, 1 or another integer n, the executable_expression is done 0, 1 or n times only; but if that result was a negative value again, another while-step is done.

Some examples can illustrate the use:

Fixed repetition.

Execute 365 times:
  300+65 <-- any expression yielding 365
    ...
  

Condition.

Execute only for A equal to 0:
  A=0 <-- an expression yielding 0 or 1
    ...
  

While repetition.

While is implemented similar to fixed iteration, but with a negative iteration counter to indicate that at the end of the iterations, APL should check the condition again.
Execute as long as A equals 0:
  -A=0 <-- an expression yielding 0 or -1
    ...
   .

Alternatives.

For alternatives the controlling expression should have as many numbers as there are alternatives, and each executable alternative is headed by a label-less colon ":".
 A=2 3
 :'XXX is a variable'
   ...
 :'XXX is a function'
   ...
 

These examples show how control is used monadically to define the beginning of a control block and niladically to define the end of that block.

Single line control

This symbol control can also be applied dyadically for single line control. In that case the syntax is:
    executable_expressioncontrolling_expression

Some examples that illustrate this dyadic use for single lines:

1. Condition.
   Assign 3 to variable LARG if LARG doesn't exist:
      
2. Fixed repetition.
   Read 365 samples:
      
3. Fixed repetition.
   Factorial computation (rather artificial):
      
4. While repetition.
   Continue to collect user input, until finally the user enters empty line:
      
5. Condition.
   Division only if B is not zero:
      
6. Alternatives.
   If/else: assign color RED to variable FLOW if ANSWR is 1, otherwise assign YELLOW.
      

   If/else: Report zero division if B=0, otherwise perform division:
      

   Seven alternatives: do either of 7 modules depending on the value of variable DAY:
      

This type of structured control is implemented for blocks in APL2C (http://www.apl2c.de/).

J is a language with most of the ideas and power from APL. In many ways it is even superior to APL. As K. Iverson, the designer of APL and J, once remarked, in J he tried to keep the good things of APL and correct the mistakes that he made in APL.

Moreover, J is further developed and distributed by a bunch of very enthusiastic people. This accounts for the fact that many new ideas and improvements still find their way into J, notwithstanding the fact that it was already very powerful to begin with.

Personally I concur with Iverson that J is an improvement to APL in many ways, except for one powerful feature of APL: the special characters that are used in APL. Iverson considered these special characters of APL a mistake and consequently J uses the normal ASCII characters. However, these special characters let me read APL lines far easier than J lines.
Another weak point of J is the written documentation. This written documentation has not kept up with the rapid speed that new developments in J features took place.
Both these points are criticism that are not shared by everybody, though.

Contrary to most APL implementations, J is completely free.
Furthermore, there are several tutorials to learn more about specific features of J.
Moreover there are many very useful packages available; one that I am found particular useful was the package to make all kind of graphics.
Finally I should mention that there are a lot of interfaces available to packages like R, LAPACK and Excel.

All this can be found at the J site: www.jsoftware.com.

• If you use Linux, you are blessed. MicroAPL makes available their excellent APL (with nested arrays) for free for the unix platform. You can download it at www.microapl.co.uk/apl/aplx_downloads.html.
• The best offer for windows is nowadays from Dyalog APL. This APL currently is the most extensive APL and they provide a free personal version at this page.
• A free APL version of APL was reported to me by Don Bary: ...Similarly, several years ago a high quality free/libre implementation of APL, GNU APL, was published, which almost completely implements ISO standard 13751, an extension to APL.....
  It is available for unix and for windows (although I did nog succeed in getting it running on my windows machine due to the not very intuitive installer cygwin that ended with several errors) at: www.gnu.org/software/apl/.
• Recently a full APL on experimental base for Windows is NARS (Nested Arrays Research System). This also has full APL nested array capabilities, but it has no GUI-features nor has it file-system capabilities. A nice aspect of this version is that you can install it portable (e.g. your USB-stick).
  Unfortunately the absence of file and GUI support makes it less useful for most applications. However for learning APL or for solving personal problems it is very nice.
  See the website www.nars2000.org/.

Conferences

APL is one of the few programming languages that has an international conference every year.

• APL2016
  Dyalog yearly conference.
  See Dyalog conference info
• APL2015
  Dyalog yearly conference.
  See Dyalog conference info
• APL2014
  APL2000 conference.
  See APL2000 conference info and pdf report
  Dyalog yearly conference.
  See Dyalog conference info
• APL2013
  Dyalog yearly conference.
  See Dyalog conference info
• APL2012
  Dyalog yearly conference.
  See Dyalog conference info
• APL2011
  Dyalog yearly conference.
  See Dyalog conference info
• APL2010
  APL2000 yearly conference.
  See APL2000 conference info
  Dyalog yearly conference.
  See Dyalog conference info
• APL2009
  APL2000 yearly conference.
  See APL2000 conference info
  Dyalog yearly conference.
  See Dyalog conference info
• APL2008
  APL2000 yearly conference is in Bethesda (Maryland) from 10-11 november.
  See APL2000 conference info
  Dyalog yearly conference is in LO-Skolen in Denmark from October 12-15.
  See Dyalog conference info
• APL2007
  Dyalog yearly conference in Glasgow from 14 - 16 November.
  See Dyalog conference info
• APL2006
  Dyalog yearly conference.
  See Dyalog conference info
• APL2003 "Stretching the mind"
  In 2003 the APL conference was held as a part of the 32nd conference on Array Programming Languages in San Diego (calif.) from June 11 - June 14.
• APL2002 was in Madrid Spain from 22-25 july.
  Chairman was Manuel Alfonseca (email: Manuel.Alfonseca@uam.es).
• APL2001 was at Yale University in New Haven, Connecticut, U.S.A..
  Chairman was Ed Shaw (email: shaw@acm.org).
• APL2000 was in Berlin at the Department of Computer Science of the Technical University.
  Chairman was be Dieter Lattermann (email: dieter_lattermann@compuserve.com).
• APL99 was in Scranton (Penssylvania, USA).
• APL98 was in Rome.
• APL97 was in Toronto.
• APL96 was in Lancaster.
• APL95 was in San Antonio (Texas, USA).

Journals

There used to be several journals, publishing regularly about APL. Some names are Quote Quad (ACM/SIGAPL) and Gimme Arrays! (Toronto APL SIG). Currently only one journal is available which is:

• Vector (British APL Association): http://www.vector.org.uk

Books

Some books to learn APL are:

• Brown et. al.APL2 at a Glance, Prentice Hall, ISBN 0-13-038670-7.
• Dalois,Maurice: Introduction to APL*PLUS PC, available from EducAPL, US$30, US$10 for overseas shipping.
• Gilman,Leonard & Rose,Allen.J.: APL - An Interactive Approach, Wiley, ISBN 220-471-30022-5.
• McGrew,Jon: An Introduction to APL2, IBM (SH20-9229).
• Peelle,Howard.A.: APL an Introduction, Holt, Rinehart & Winston, ISBN 0-03-004953-9.
• Thomson,Norman D. & Polivka,Raymond P.: APL2 in Depth, Springer-Verlag, 1995, ISBN 0-387-94213-0 ($39.95).
• Turner,Jerry R.: APL IS EASY!, Manugistics, 1993.
• Weigang,Jim: APL Notes, Available from J. Weigang (includes APL*PLUS interpreter) 68 Plateau Circle West Springfield, MA, 01089, USA price: US$29 postpaid in US & Canada, US$38 overseas.
• "J Primer," Iverson Software, 1996, ISBN 1-895721-14-8
• Batenburg,F.H.D.van: Mikrokursus modelbouw & simulatie voor Biologen .