HomeAPL HistoryExperienceContactLinksNamePrivate

My perception of APL in the insurance industry

My first exposure to APL was in the 1970's.  At that time APL ran on the mainframe computer through time sharing using special terminals with the APL keyboard.  APL was fairly common in the industry and was usually a first language that an actuarial student would learn.  An advantage of APL is that it was easy to learn and accessible to someone without prior experience in computer use.  On the other hand, APL is a powerful language and its array orientation very natural to actuarial work.  The language is very compact (http://catpad.net/michael/apl/) and development speed is extremely quick.  APL is very flexible and can offer several ways to peform the same results.  What drives the choice of the style of code?  Readability versus execution speed is an example.

The APL actuarial community was very varied and had a wide range in skills and attitudes.  Actuarial staff were generally not aware of IT standards and practices.  The emphasis was on development speed and not on maintenance needs. It was not uncommon to rewrite an application rather than try to figure out existing code.  This was acceptable when the applications were relatively small. 

Actuarial students participate in a rotation program and generally change positions within the company every 18-24 months.  Documentation that is created tends to get lost.  Documentation may exist somewhere on a LAN but is buried among thousands of other documents.  APL does not have embedded facilities for documentation.  With time, applications grew in size and importance; APL applications were used for the valuation of reserves and affected financial statements.  Actuarial rotations and the range of APL skills could create problems.  An actuarial student inherting code written by an APL expert would face very compact, efficient code that is difficult to interpret and maintain.  This created the opportunity for misinterpretations and for errors to creep into the code. 

APL is a computing language.  Accessing files and interfacing with Windows environment is possible through system functions but these are technically not part of the language and can vary between vendors.  The use of these system functions can be difficult and represent a steep learning curve especially for those without a computer science background.  A common solution is to cut and paste data from APL to Excel for formatting output etc.  Very few realized that APL could be a server to Excel and data can be transferred to/from APL using Excel's VBA. 

More recently management focused on quality control, documentation, and a uniform platform.  This led to the adoption of third party software sold by the large actuarial consulting firms to replace APL applications.  However, the implementation accross the company is not immediate and APL applications persist in places.  With the advent of third party software, the need and incentive for staff to learn APL greatly diminished.  Some staff can therefore be running APL black boxes. 

The loss of APL skills also represent the loss of a useful tool.  It was common to use APL for sundry needs and applications.  As a result of the loss of APL skills, there are now too many large and clumsy Excel workbooks. Excel is an excellent tool that can address many needs but just because Excel can support a specific application does not mean it's the best tool for it.  Warning signs are Excel workbooks that exceed 10 MB size, have close to 100 sheets or are interlinked to half a dozen other workbooks.  Another warning sign is when the formulas in the workbook become unreadable to the average Excel user.  Finally, workbook so highly structured that moving rows, columns or cells is forbidden is a sign a different tool is needed.  There are modern alternatives to deal with large amounts of data and the interpretation of this data.