Supporting APL in a Large Organisation

Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 68

BA spend 3% of revenues on information management, expected to be 5% in 2 years time. This leaves enough to fund 3 APLers in a full-time central support role. They have some 30 - 40 mips running APL, with around 10Gb of data, and 30 - 40 APL developers. (“How much is that in Megaflops?!”) The corporate info systems “got us through Libya/Chernobyl” when the switchboard was jammed with Americans wanting to cancel.

Main Tasks of the APL Development Centre¶

• to be BA local experts in APL
• to develop and maintain an APL infrastructure. (2,500 functions). Makes developers more productive by doing all the nasty things at the centre, and doing them well. Examples are: language extensions; cover for APs; inverted file support and so on. Also a variety of documentation tools, code checkers etc.
• to handle archiving, efficiency checking, response-time monitoring and so on.

Minimizing the Maintenance Load¶

2,500 functions
12 lines each on average
= 30K lines of APL code
= = 150K lines in typical 3GL!

Typically the maintenance time is about 1/25th of the development time, which is not half bad. Why?

• a lot of the functions are simple. They are easily described in a 1-line comment.
• they have 1 or 2 arguments. They return 1 result. They have no side effects.

There are some functions which do cause problems.

• Functions using stranded arguments (of many types); functions which use globals to hold results; functions which do lots of things with the screen (everything going to the screen is essentially a side-effect!) With stranding it is often hard to tell which is the function and which are the arguments!!
• over-generalized functions. Don’t go for a 200% solution; you throw away all the fast development time, and the result is much harder to change to reflect what actually happens, rather than all the things you thought might, but never did!

The Cost of Poor Quality¶

Manufacturing industry …………… 5%
Service industry …………… 20%
Software development …………… >50%

… for every 100 bug fixes that IBM sends out, 58 produce a bug somewhere else! Moral:

• keep bug logs up to date. Put them in the WS or on Email where you can find them again.
• take time to do it right 1st time. “There is never time to do it once properly, but by God you can always find time to do it twice”
• use formal methods for debugging. (“I wonder if the A320 is fully debugged?!”) Use APL as a formal notation (e.g. using the set operations) to check the spec, even if the algorithms would be hopeless in practice.

Thoughts on Efficiency¶

… roughly the equivalent of 1 747 (plane) would have been required if this had not been pushed as an issue.

• response time does matter. To get the “superprogrammer” effect you need small teams, no hierarchy, and good response time.
• monitor overall response, and check workspaces with ⎕MF. Set this for all functions, write the results to file, and analyse at leisure. Typically the results are sorted by “gross time” of function, and refined in more detail by looking at the functions called by the top 10 worst offenders.
• using ⎕MF and Fastfns, the total saving on CPU is between 20% and 40%.
• watch the Sharefile response … a job run automatically every hour checks response, and has been calibrated with user-reaction (“fine” …. “upset” ….. “hopping mad” etc) to give sensible warnings.

Editorial note …¶

… there was lots more, all of it good stuff. I will try and find room in VECTOR 5.2 to continue through MJ’s thoughts on training APLers, communication with the APL development teams, and exploring new environments for APL. Watch this space!