APL has had its detractors, particularly from those who experienced it during the seventies and eighties. This page deals with most of the critiques.

This was certainly not entirely wrong on an 80286 or even an 80386.

On an 80486 APL did run well already, let alone a Pentium. This is demonstrated by the enormous consumption of both, memory and CPU in every-day applications like Word or Excel.

This feeds on two misconceptions:

On average a single line of APL equates to as much as 30 lines of C code or 4 pages of COBOL! Yet critics expect the time needed to understand a single line of APL code to be the same as for understanding a single line of C or COBOL code.

COBOL programs written fifteen years ago are inferior in terms of readability than current COBOL programs. The same is true for APL, or any programming language for that matter.

A manager who looks at a page of code written in C or COBOL or Pascal or Java may think something along the lines of “I don’t understand it, but if I had to, I would make an effort and I would understand it.”

A manager who looks at a page of code written in APL might think something along the lines of “I don’t understand this, and I am sure: no matter how hard I try, I will never understand it!”

Let’s be clear about this: the usage of English words in practically all programming languages but APL suggests a possible understanding of the code. To really understand a complex program this does not help that much!

To understand highly complex programs written by somebody else is difficult even for good programmers, no matter what language the code was written in.

If those same managers had to make a decision on whether mathematics is “maintainable” based on some equations from quantum physics, well, mathematics might not have made it into C21.

APL always was, and still is, a primary tool in areas where development speed is paramount.

A typical example are large banks, where projects are occasionally started twice: the APLers implement something quick (translates to “dirty”) in order to support the traders.

The C programmers do the same but properly. More often than not the C project will never make it, be it because the resources are suddenly needed elsewhere more urgently or because the product vanishes into nowhere before they are ready to deliver.

The time pressure on APL programmers contradicts of course the demand for maintainable software.

You have to get your priorities right: it is either speed or maintainability but not both at the same time.

This is not a flaw in APL, it’s a consequence of priorities.

That was once correct, but now both Dyalog APL as well as APL/Win both offer control structures for significantly longer than a decade.

However, although control structures are actually much less important in APL than in other languages because …

  • loops are used much less.
  • APL functions are much shorter.

Many, including me, consider control structures as an important tool for structuring code; APL functions with control structures are often more readable than those without.

Syntax colouring, a common feature these days, has proven to be an advantage as well because it also improves readability and maintainability.

Due to the colouring in the editor one can effortlessly spot …

  • reserved words (control structures)
  • system function and – variables
  • global variables
  • local variables
  • constants
  • comments
  • syntax errors

Dyalog-APL as well as APL/Win can act as both OLE clients and OLE servers.

All three can use ActiveX controls.

All master DDE.

All can communicate via ODBC or vendor-specific DLLs with all major databases. Relational databases work especially well with APL; after all SQL is a non-scalar programming language like APL.

All interpreters are capable of communicating via TCP/IP.

All interpreters can use DLLs.

All have an interface for calling programs written in other languages.

Dyalog APL and APLX have both ⎕XML which allows the conversion of APL arrays into XML and vice versa.

Dyalog APL is a first-class citizen of the certified (by Microsoft that is) .NET programming languages.

Dyalog-APL as well as APL/Win and APLX have special editors and debuggers.

Control structures are properly indented and coloured.

Break points, stop vectors in APL speech, can be set and unset with a single mouse click.

It’s certainly correct that APL, given its mathematical background, is especially suited for such applications.

APL is indeed used by quite a lot of statisticians for analysis, and it is also widely used in the insurance industry.

However, that does not mean that APL is restricted to such applications.

Since Dyalog APL offered the first APL with a real GUI the two leading vendors have always implemented the latest technology in this area rapidly.

Today one can produce an APL application with a GUI that does not look any different from those implemented with other languages like C++ or Delphi.

That was a big problem in a distant past.

But the days are gone when one needed special hardware for displaying APL characters. Today you just install the font and there you are.

Anyway, the APL character set is needed by developers only.

APL is slow when it has to take care of single pieces of data or events, because it is an interpreted language.

On an 80486 it was still a nightmare to establish a callback on the “KeyPress” event with APL, which was executed whenever a key was pressed.

Since the introduction of the Pentium that has not been a problem.

APL is fast when it deals with large amounts of data, because the necessary loops are executed within highly specialized routines.

That is basically the reason why APL programs, processing large amounts of data, quite often outperform C programs. The C program then needs tuning to catch up, and the tuning might take up significant amounts of time!

K (and its child Q) are also part of the APL family, and they are used in the financial industry because they are so much faster than their competitors.

Good point. However, should we stop the development of new programming languages because by definition there are no programmers available for them?

I’ve never heard of a company that rejected SAP because there are not enough SAP specialists available, although this has certainly been true for a long period of time.

If one needs APL programmers, well, train them. APL can be learned quite easily, at least compared with other languages.

SimCorp, the world market leader for portfolio management systems, has grown exceptionally rapidly over the last 20 years. In 2010 they had 1000 employees, 160 of them being APL developers. Most of them were educated in APL on the job.