| Intro | |||||||
| Personal | APL | Publications | Research | Software | Teaching | ||
| WhatsWhere | |||||||
My experience with conventional languages such as ALGOL, FORTRAN, Pascal and others was enjoyable. However I discovered early that I could produce programs with more fun and much quicker in non-conventional languages like SmallTalk or APL. Frequently even 1 day of APL programming accomplished something that required a week of diligent programming in, for example Basic or PL/I. It seems that I am now addicted to APL. (However I am not single-minded in my addictions; email me if you know more potent stuff: a language that is more powerful and cuts development time even more). This page will address the following topics in more detail...
|
Thanks to its power, programs are written much faster in APL than
in most other languages.
Opinions differ how fast development in APL is compared to development
in other languages.
My own feeling is that I develop roughly 5 to 10 times as much in a
week when I use APL than when I used PL/I.
Some APL-programmers claim a speed ratio of 1:10; using APL they can
finish a project in one or two months against a year with some
conventional language.
Datamation (DA92) cites a more conservative figure of
1 to 4 times as much when comparing APL to C.
But even then, an APL programmer only needs a day to complete a problem
that might take a C programmer nearly one week.
For this reason APL is especially suitable for prototyping.
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:
APL is an acronym for "A Programming Language". The language was designed by Kenneth Iverson in the sixties. His purpose was to invent an improved mathematical notation, as he considered conventional 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 other programming 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 of 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 ) .
Why APL?
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 would 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.
APL FAQ
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; I will give elaborate on this FAQ
in later on.
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. The above misconception 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 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.
APL is distributed as an interpreter. And interpreters are by definition slower than 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).
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.
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.
For APL programmers, Sam Sirlin compiled questions with answers in an APL-FAQ. This is available at...
In the Netherlands this WG3 is represented by the NNI (http://www.nni.nl) where the language group is chaired by drs.W.F.Wakker (email: willemw@ace.nl).
Up to now the fruits of WG3 are :
APL programming standards
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 language proposals
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:
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.controlling_expression <-- begin of control block ... <--- executable_expressions
<-- end of control block
Some examples can illustrate the use:
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.
This symbol control can also be applied dyadically for single line control.
In that case the syntax is:
executable_expression
controlling_expression
Some examples that illustrate this dyadic use for single lines:
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/).
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 very reasonable priced.
And for personal use it is free.
Furthermore, there are several tutorials to learn more about specific features of J.
All this can be found at the J site.
A selection of useful websites for J are...
Public domain APL
See FAQ for many more software addresses.
See FAQ for many more websites.
For much more information see FAQ.