Working Practices - Phil Last

I started APL in 1981 in my first computing job using IBM's VSAPL. I moved on to APL2 when it came out in '83 or '84, to Dyalog in '88, added APL*PLUS/PC in '89 and since the mid '90s have worked almost exclusively in Dyalog.

Is

• Since '97 when Dyalog first implemented dynamic functions & operators I use almost nothing else. So far I've found very few places where I need to.

• I make more than common use of operators. I have 38 in my current project only one of which is application specific.
• If one of my functions approaches the size of the screen it needs to be broken up.
• I always have a set of common utilities in a sub-namespace of the project and use them.
• I like to keep local names short so they don't obscure the algorithm.
• I like to put at least four to seven comments at the bottom of each function or operator so they don't get in the way of the tracer:

⍝ a one to five word description
⍝ ⍺  - specify left argument
⍝ ⍺⍺ - specify left operand
⍝ ⍵⍵ - specify right operand
⍝ ⍵  - specify right argument
⍝ ←  - specify result
⍝ anything else worth mentioning

These should be sufficiently precise that my successor can rewrite the function without having to read the APL!

Isn't

• I make almost no use of control structures because:
  • I saw them as already redundant when they were first introduced into APL in the eighties because I had a full set of operators that did the same thing only using infix notation.
  • I believe they obscure the flow of a function by emphasising trivialities.
  • Dynamic functions and operators preclude their use.

• So far I've made little use of Dyalog's object/class extensions. I'm waiting for the unscripted version to appear! I do use my own object/class framework on those occasions when it seems applicable. I've written the first draft of a facility to let me write classes using only dfns and have it auto-generate the script.

• I don't like Select lists. They masquerade as a set of equivalents belying the fact that they are progressively restrictive

  this set of conditions      | is not a set but a sequence:
       case c0                |     case c0
       case c1                |     case c1>c0
       case c2                |     case c2>c1∨c0

  Their sheer verticality invites us to sort them into a more attractive order.

CategoryWorkingPractices