Recollections

Roger Hui

My first contact with APL occurred 50 years ago, in April 1966, when I travelled from Hong Kong to San Francisco on the S.S. President Wilson of the American President Lines.

My career in APL started as a summer student at IPSA Calgary in 1975, where Arthur Whitney was a summer student the year before. On my first day on the job Ian Sharp happened to be visiting, and the whole office (5 or 6 people in total) went out to lunch with Ian. During lunch I expounded on matters far and wide. Ian watched me for a while, then turned to Lib Gibson, IPSA Calgary branch manager, and asked, "Isn't Arthur Whitney coming back with us this year?" It was years before I realized that I had been put down.

----------------------------------------

In my APL career, I have been privileged to be allowed to do my best on programming problems large and small, including a personal list of benchmark problems. They are benchmarks not only of my own understanding but also on advancements in the APL language. One such problem is generating all the permutations of ⍳n.

1981:

      p←perm n;i;ind;t
     ⍝ all permutations of ⍳n
      p←(×n,n)⍴⎕io
      →(1≥n)⍴0
      t←perm n-1
      p←(0,n)⍴ind←⍳n
      i←n-~⎕io
     l10:p←(i,((i≠ind)/ind)[t]),[⎕io]p
      →(⎕io≤i←i-1)⍴l10

2015:

      perm←{0=⍵:1 0⍴0 ⋄ ,[⍳2](⊂0,1+∇ ¯1+⍵)⌷⍤1⍒⍤1∘.=⍨⍳⍵}

This last version is not the last word. The details are in the Dyalog blog entry Permutations.

back to top

Gregory Jaxon

The APL\360 portion of Syracuse University's time-sharing system was just being rolled out in 1973 when I came to campus as a freshman architecture student. I quickly acquired a copy of Gilman & Rose's "Interactive APL" book and burned through several students' quotas of CPU time. When I discovered that the accounts I'd beg, borrow, or steal lasted longer if I coded more efficiently, the optimization game that became my obsession was suddenly on.

My architecture professors became more and more alarmed that a computer could be used as a design aid. There was one line-drawing graphics terminal in the "fishbowl" room of the engineering building, for which I wrote one-liners to cast perspective views of wire-frame model data. Another of my one-liners solved the statics problems throughout an entire semester of steel design.

By fifth year, I'd switched to the CS department, studied Lisp, Pascal, and Prolog and had the ultimate good fortune to rent a house with two other amazing APL hackers, Jan Prins and Stephen Bartels. Jan actually got me my first APL job when we wrote a database and query language for SU's Art museum. Steve and I later co-wrote APLB for Burroughs/Unisys. We three eventually graduated and set out to make SIMD parallelism conquer the world.

Well that took a while to not quite happen! After a stint at IPSA (but outside the "zoo" proper in the ill-fated Cleveland "field" office), I joined Steve at Burroughs where we took up Jim Ryan and Ron Murray's APL\700 product. Burroughs made parallel processors with virtual memory and had just fielded the first vectorized instruction set, which Ron's APL interpreter mods demonstrated to the envy of Fortran coders throughout Burroughs' customer base. Ron later gave us a clue about Burroughs memory management that led Steve and I to rewrite APL\700 as APLB for a 40% runtime gain on the same hardware. We added atop that nested arrays and loads of APL2-like goodies. I distinctly recall crashing Dyalog APL's booth at APL83 by throwing curveballs to the "execute each" derived function, which I'd recently finished implementing correctly; all's fair in love and war, and APL is both.

During 1980-83, I had the honor of serving as secretary for X3J10 under chairman Clark Weidemann. There I met practically all of the luminaries of the early APL world, some of whose praises I happily sang in the live APL Blossom Time at APL'81 – special thanks to John Gilmore (toad.com) for the crash pad at that conference! The entire crew of APLers were as talented and hip a bunch as I have ever met since.

I especially valued the several times Ken Iverson and I were able to converse. Both Ken's and Jim Ryan's openness to creative thinking and their role-models for how to translate blue sky into computing applications has inspired me throughout my career since. I've attached a photo from Minnowbrook back then that includes Ken and several nested array developers still sorting out the fundamentals.

I have to say, though, that the solid CS theory sessions at SU, Minnowbrook and X3J10 meetings, followed up by the compiler, interpreter, HPC, GPU & network architecture work that APLers worldwide have developed over the last 4 decades made key progress that is still ongoing in the computing world of 2016. I've been doing my part by developing vector-oriented aspects of the SystemVerilog hardware design language and advancing wherever possible the efficient use of notations as tools of thought.

back to top

Curtis A Jones

What are the highlights of my own 42 years with APL? First I tried to think of something cool about APL ... I did once put a x.+ (instead of the usual +.x) into a public workspace. That could lead to a discussion about how valuable APL's operators are and how that's one way APL is better than MATLAB. I coined the term "Guerilla Marketing" (I doubt I was the first!) when scrounging envelopes from an IBM San Jose supply room to take to the Santa Teresa Lab to help mail copies of TryAPL2 in 1990.

But what's really important is the people developing and using APL. Paul Wesling (e.g. Origins of Silicon Valley (1909-1960)) has given several fascinating talks on the "Origins of Silicon Valley" in maritime radio and ham radio. He argues strongly that the success of Silicon Valley comes from the culture in which hams are competitive but always willing to help out other hams. I got a major lift into electronics from the ham across the alley in Brookville, PA. I think APLers are like that. The quality of APL may be due in large measure to big arguments and eventual consensus among the developers (and probably users). There's no way I could list all the people in APL who have helped me, but thinking about Paul Wesling's praise of the ham-radio culture made me think of an APL BUG meeting that must have been in 1987 when Gene McDonnell talked about Conway's game of life. (Jon McGrew: Should it be "Game of Life"?) A book on PostScript had just come out and it had Life written in PostScript. Somebody at I.P. Sharp translated it to APL and passed it around. Then another showed how the code could be shortened. I don't know how many iterations it went through, but it got really short. The "competition" was not to reduce the number of lines, it was to reduce the number of symbols! Gene's talk to the APL BUG described the combination of sharing and competition nicely. It's not as strongly emphasized in his APL88 paper "Life: Nasty, Brutish and Short" in APL Quote Quad, V. 18, no. 2 (Dec 1987). APL seems to attract really bright people who are proud of what they've done and are more interested in discussing ideas than tooting their own horns.

back to top

Roger Kumler

My APL experience reaches back almost 40 years (which surprises the heck out of me!). I graduated from college in 1974 and took a job at the University of Rochester, in Rochester, NY in a medical research lab. I transferred to a different research lab a few years later, and a year after that, met a recent PhD who was brought in to oversee the lab.

The lab had tons of data, a dozen or so different parameters, measured every 15 to 30 minutes over 5 or 6 hours, across many dozens of experiments. The new supervisor, Fred Pierce, suggested that we see if APL could help, so we would go down to a basement room in the hospital where the only terminals were and connected to a DEC machine running APL\SF, using an Anderson-Jacobsen terminal.

I was quickly hooked. It took me a few weeks to figure out how to use functions across multi-dimensional arrays, but, once mastered, it was perfect for our 3-D data matrices. There were many days when I would head to that terminal room first thing in the morning and not leave until the end of the day. There was only 1 CRT and I was loathe to give it up, even if it meant skipping lunch.

Something about the way the language allowed me to construct expressions seemed to match very quickly with how I was naturally thinking about the problem (or maybe it worked the other way and I was seduced by APL's simplicity and modified my thought process accordingly).

I was lucky enough to find a copy of Polivka and Pakin's "APL: The Language and its Uses" in the University library and renewed my loan multiple times so I could go through it cover to cover.

After a year, I answered a local advertisement for an APL programmer and landed a contract job with a Xerox APL group in 1980. Xerox was a very heavy user of Sharp APL at the time and there was a group of about 15 APLers supporting applications across all of Xerox.

In 1981, I managed to wrangle a customer support job at the I.P. Sharp office in Rochester. The next 9 or so years were challenging, but fun - trying to provide support for US in-house SAPL customers in a rapidly changing computing environment. I am grateful for the opportunity to have met so many people within the APL community, in Rochester of course, but also in Toronto, NYC and other offices around the world as people came in for conferences and meetings. Lael Kirk, Fletcher McTaggert, Bob Metzger, David Smith, Bob Campbell, Sue Wajda, Eric Iverson, Mark Dempsey, Leslie Goldsmith, Charles Chandler, Kevin Harrel, Raj Chohan, Nancy Lamb, Margo & Bill Tate, Lib Gibson, and many, many others.

In later years at Sharp, I did a lot of QA testing on LOGOS and I recall, with some fondness, and some fear, the LOGOS classes that I taught while at IPSA. Most of the classes were in Toronto, but there were also two at Irish Life in Dublin. Before the first class, I got some overheads from Mark Dempsey and used those for that initial class. I then furiously revised them for the next class a couple of weeks later. I'm pretty sure that I never used the same set of overheads twice. It was always the case that something could be presented better.

Then there was the trip that Jo Taylor and I took to meet with Morten and Gitte and colleagues in Copenhagen to learn all about SHAPE. We enjoyed the trip immensely. Sadly, SHAPE never really took off in any meaningful way.

After the Soliton spin off, I worked for about 18 months as an independent contractor to various of the current Sharp APL in-house customers.

Ever since the end of my contracting days, in 1992, I have worked on basically one product. This was prototyped by a gentleman named Bruce Hutton. He was a long time telephone switch engineer and knew that software could be created to automatically update phone switches based on the contents of a customer order. He and his wife started The Hutton Company and Bruce and I wrote the software, using Dyalog APL version 6 in SCO Unix. Bruce was brilliant in figuring out how to interface between a Dyalog APL session and the Unix Telnet command (lots of pipes and redirection involved), and the use of serial ports. That product was very successful in its niche market, and at least one phone company is still running it more than 20 years later!

Through various corporate changes and transitions, I ended up at a telecom software company in Albany, NY and essentially rewrote the product in Dyalog APL for Windows, and, except for occasional forays into Linux releases, that is where the product remains.

I have met some fabulous people, travelled to places I would never have gone otherwise and managed to contribute in a small way to the telecom industry with the automation products that Bruce Hutton and I started work on in 1992. Looking forward to a few more years, at least, working in the APL community.

back to top

Stefano Lanzavecchia

Rewind back to 1985: what is a good way to give a dream to a 13 years old boy fascinated by computers? Entertain him for an entire Sunday afternoon with a roaring shiny clicky alluring dual monitor (MDA + CGA) IBM PC running an APL interpreter! Also, if you want to make sure that he remains caught in the web, a bit later, give him a copy of Pocket APL to run on the IBM PC his father bought to work from home. After all, when he's not writing spaghetti BASIC, the critter enjoys entering programs in 8088 assembler using DEBUG.COM, so he needs to be straightened out. That critter was younger me.

Fast-forward 10 years, Windows 95 is barely 6 months old, it's the golden age of the BBS and their colorful ANSI art and the Internet is slowly shaping up but its access is reserved to a few lucky ones, professor at Universities. I, fresh out of a Master in Physics, need to find a job abroad and by sheer luck (or had it all been planned?) I obtain a recommendation to apply for a position involving a DOS to Windows conversion: the company's name is Insight Systems, the program to be converted originated in IBM and is written in APL, Dyalog APL in its last incarnation. Despite the fact that I show up in a smelly jumper, after a seven kilometers ride on a bike through heavily snow-clad roads, with two centimeters of beard, in days when the savage look was definitely unfashionable, I pass the interview. In a matter of days I move from home, the largest city in Italy, to a small seaside town in Denmark, in the middle of one of the coldest winters of the last few decades: two thirds each side of the Øresund would be frozen solid a few days later. The office was nice and warm, though, and there was a lot of work to be done: not much time to enjoy the overstretched Christmas scenery. Thus began my adulthood and my professional life, both inextricably tied to APL, in a tangle that I never since bothered to unravel. A fellow with a nicely mixed ancestry and a welcoming family called Morten Kromberg became my boss, my mentor and, shortly after, a good friend.

The turn of the millennium found me back again in mother Italy, professionally hosted by a company called APL Italiana and soon to become one of their employees. I am still breathing Dyalog APL.

Fast forward all the way to the present time, and here I am, now the CTO of APL Italiana, eight (15.0-7.0) full integer releases of Dyalog APL later, still enjoying my daily struggle, the vain attempt to tame the beast. In 30 odd years, I went through many programming languages and computing environments, most somewhat influential, many useful. Some keep baffling me, some have become faithful and trusted travel companions. But the longest thread remains APL, the longest involvement of my life, professional and private. I, grateful still to my benefactor responsible for that fateful Sunday, would be glad if it could continue some more.

back to top

Gary Logan

Adin Falkoff was the IBM manager of the APL development group. Adin always tried to find a good reason for any design/implementation decision.

Here are a couple of examples which show the thinking of the group.

Every APL system had a system operator userid which when signed on had special interpreter privileges. A numeric userid needed to be selected for the operator. Every employee had a six digit employee number. The number chosen for the operator was 314159 the first six digits of pi.

All users would sign on to APL by entering, for example, )userid:password at their 2741 terminal. This terminal used paper to record the user session. There was a need to prevent passwords from showing.

The solution was to provide a security blot on the paper so the characters would not be seen. The user would enter a bare right paren and the blot would print and the terminal would await input at the start of the blot. A typically simple solution.

The blot itself consisted of a sequence of characters and backspaces. To achieve a dense blot, they chose M backspace I backspace 8. Repeated to provide a blot of long enough to hide a signon, e.g. )314159:JKT

These are just two examples to show the detail of thought the group put into decisions.

back to top

Michael K. Rosenberg

I was 15 years old and it was my first day of high school in 1972. I walked by a small room from which a fair amount of typing noise was emanating. I looked in and saw students sitting in front of two large typewriters. They would type something, and amazingly, the typewriters would type something back in response. That was my first exposure to a computer, and to APL\360. For the next three years I spent almost every free minute I had in that room, coding, discussing computers and programming, and learning everything I could about APL. Flash forward to 1980. I'm about to graduate from the University of Rochester, and all I want to do is program APL. Fortunately, in 1980 the city of Rochester, NY was a major center of APL programming and I quickly landed a job. Every since then I've been involved with APL in one form or another – APL\360, Sharp APL, A+, k and kdb+/q. I've been incredibly lucky to have a career doing what I love. Recently, I fired up the original APL\360 source code. Boy, did that bring back fond memories!

back to top

Jack Rudd

My role in SCAMP, IBM's first personal computer

SCAMP (Scientific Center APL Machine Portable) was developed in 1972-73 as a demonstration prototype; and in 1975 the production version was formally announced as the IBM 5100 desktop computer. It was the only non-defense project that I have worked on in my entire 50 years in the aerospace industry.

My role began in autumn of 1974, when IBM management was looking for someone to install APL software on a new computer under production. Someone at IBM San Jose had suggested my name, and when I expressed interest my local management agreed.

The task was to take a collection of 40 programs written in APL that were part of an existing statistical analysis package that executed under the APLSV interpreter on IBM 360 mainframes (with 32 kilobyte workspaces), and adapt them to the smaller (25 kilobyte) workspaces of the SCAMP environment.

Fortunately, SCAMP ran an emulator that indirectly executed instructions of the IBM mainframe architecture. This enabled it to run APL programs under an exact replica of the APLSV interpreter. Therefore, I could do most of this adaptation and testing in my normal Westlake Village, CA office, which had a Selectric typewriter terminal (with an APL typeball) connected via phone lines to an APLSV timeshare system running on an IBM mainframe in Palo Alto.

Now 25 kilobytes is a very small memory, and it had to contain the APL code as well as the input data, the output data, and whatever temporary intermediate data was required. One was obliged to conserve space using extreme measures, such as deleting all comments, eliminating blank lines, and using (and reusing) single-character variable names as much as reasonably possible.

Also avoiding floating point where possible without degrading accuracy. Also reusing the same variable multiple times in one line of code to minimize the amount of temporary data required at any one instant. And all the while assuring that executing the test cases did not violate the 25 kilobyte constraint.

After doing all this for all 40 programs, I printed out all the modified programs and the input and output data for all the supplied test cases, so that I could later re-enter this information (except for the output data) manually into SCAMP. At this point, because of IBM's excessive secrecy about new products, I hadn't even been told what its storage medium was; so paper was the medium of first and last resort.

Then it was off to IBM Rochester, MN, where the production lab was. It was January 1975, and the temperatures approached minus 15 deg F. most nights.

At last I got to see the machine itself and its peripherals, and all was revealed. It had a 5-inch display screen (revolutionary for the time) with a very small font. The auxiliary storage, where the APL workspaces were stored, was a 3M tape drive, with a tape that held 300 kilobytes and required 90 seconds to rewind. The keyboard was reasonably comfortable. There was no mouse.

The afternoon before my first work session, the lab manager gave me a single tape on which to store my work. He then showed me how the machine worked, and informed me that my lab time was from 10pm to 6am, when I would be the only one there. That night I entered programs and input data, and tested thoroughly, for 8 hours.

The second afternoon I told the manager I needed a second tape, since I had filled more than half the first tape the previous night. He laughed out loud. "That's impossible!" I replied that it was truly the case that the tape was more than half full of programs and data. He replied, "Show me!"

So we went into the lab, I pulled out a hard copy sheet with APL code, and started to enter it via the keyboard. In due course the manager's jaw fell open, and he exclaimed quietly, "I've never seen anyone touch-type APL!"

I had no trouble getting more tapes after that. A week later all the programs were entered and tested, and my work was finished. I never received any feedback after that; but at least nobody complained, so apparently all was well.

back to top

John Scholes

Sometime in 1971 Brian Pyne told me that the Sigma 9 would soon have a new language in which it would be possible to write Conway's Game of Life in one line. As a FORTRAN programmer, I was impressed.

At around the same time, there was an article in (I think) COMPUTING magazine claiming that researchers were working on languages where your program would still work if you shuffled the source card deck. As a FORTRAN programmer, I was impressed. I now understand this to refer to research into declarative or denotational languages, which express definitions as a set of equations and which, among other influences, inspired some of the thinking behind dfns.

I owe Brian a lot. He used to encourage me to mitch off with him on a Wednesday afternoon to attend public lectures at Imperial College. One I remember in particular was by a CDC engineer about the CDC STAR-100 machine, which was inspired by APL and whose order code contained many APL primitive functions. He said that the machine would be commercially successful [only] if they could persuade enough people to code in an array language, such as APL. As it turned out, they couldn't and it wasn't :-(

----------------------------------------

Anyone who saw the young, pony-tailed Jim Ryan demonstrating Burroughs APL in the early '70s will remember the experience. Jim touched-typed APL, on the wonderful IBM 2741 terminal, at impressive speed. In particular, Jim made great use of the ATTN key (top right), which stopped the 14.7cps output dead in its tracks. With ATTN, you could try an expression without worrying how much output it might produce. If you didn't like what you were seeing after the first dozen or so characters, you would hit ATTN; recall the prior line for editing; and try again. The printed (on continuous stationery) session might look like this:

      ⍳1000
1 2 3 4 5 6 7 8 ...
      )
     ⌽⍳1000
1000 999 998 997 ...
      )
   +/⌽⍳1000
500500

back to top

Andy Shiers

My first introduction to APL was during an industrial placement during my time at university. I had a list of codes that I needed to sort, and I bemoaned that I had no tool to do that with. "Here," said one of my colleagues, "you can do that with APL" with which he sat me down at a terminal which had lines of dots, in groups of 8. "Replace the first column of dots with the codes, and hit <F10> when you're done. That will sort them".

"What a very odd language", I thought..."just a lot of dots and you hit the function keys to do things".

If only he had explained that I was looking at an AP124 screen, and he had written some (very) simple code to sort my input and put it back out on the screen, then I might have been less confused! APL was a black box to me then...it's much less murky now, but as any of my colleagues at Dyalog will tell you, if anyone can muddy the (Dyalog) APL waters, I can.

----------------------------------------

In the early days of Dyalog APL we ported to many different UNIX platforms; although the basic process was the same in almost all cases, each threw up a new problem or two to solve. We got pretty good at moving files between systems (these were the days before networks were ubiquitous), spotting the differences between flavours of UNIX, and peculiarities of the underlying hardware.

One I particularly remember is the port to a multi-CPUd UNISYS box. It started with getting a Lynwood terminal up to UNISYS's offices in Uxbridge; those terminals were large, heavy and pretty indestructible – and could have an EPROM inserted which contained the APL font. I optimistically slung the bag over my shoulder (which almost caused me to knock myself over) and walked the 10 minutes from the car to the machine room – by which time I was doing a pretty good impression of Quasimodo!

So I did my bit...got the kit on site, got the source of Dyalog onto the machine. Geoff then spent ½ day getting the code to compile – things were looking good for a quick port. Then we ran the QAs...and APL crashed – but in a way that was not obvious to us. We tried various experiments, trying to identify a pattern – and we were at this for a day or so. Eventually it turned out that on this system, division by zero generated a floating point exception for the first 6 times that a process ran, but from the 7th onwards a NaN was returned. Bizarre behaviour, and not one that the interpreter was expecting. Having discovered this, Geoff and I had a chat and decided that the best option was to call divide by zero 7 times each time Dyalog started – problem solved, and we finished the port, leaving the UNISYS support team to report the problem to their developers.

Some ports gave us problems purely due to the non-standard systems that we were working on; Apollo with their underlying management system underneath UNIX was one particularly irksome environment – for any regular UNIX user, discovering that root didn't have permissions to do everything to the operating system, but rather you had to switch to a different environment was exceeding irritating – a cue for some very bad language. Almost as much as the port where we were presented with an HP terminal which appeared to have all but A-Z, 0-9 thrown on the keyboard at random.

But as time went on we did more and more ports in the office – UNIX suppliers would lend us a machine for a couple of weeks. We loved working on the Silicon Graphics machine since it was the first time we came across really good colour graphics – a lot of time was spent playing with the flight simulator :-) That was a moderate sized machine, unlike the ICL DRS6000 which was large and heavy. For reasons that escape me now, it was decided to put it in the development room...which meant getting it up a flight of wooden stairs. Still not sure how the stairs took the weight...there were a lot of very unpleasant creaking coming from them! We also had an IBM PS2 for which we had to have a Dyalog-with-FPU and a Dyalog-without-FPU version...cue a homemade tool to allow us to extract the FPU (how we never broke a pin I'll never know).

These days, with a single source tree for Dyalog APL, and all the platforms sharing the same network and disk has made the process of building on many platforms much easier and fully automated – but it has removed some of the fun and interest from our lives – although at the time that might have been exactly what we were hoping for!

back to top

Geoff Streeter

My first encounter with APL was when Ken Iverson came to give an evening lecture at the Polytechnic of Central London (now University of Westminster). I was doing a part time degree there in Applied Computing. This would be approximately 1972.

I went to the lecture but, I must say, I missed the point. Sometimes I am slow on the uptake.

I got part of the point when working for Atkins Computing and John Scholes, who worked for Atkins Planning, installed APL on the Sigma. This would be 1976. At this stage I still had not met John. We met when I was giving a course on EDMS which was a data base system.

I next met John in 1981 when I was allocated to help him write Dyalog APL. He started writing the parser. I started writing the symbol table management. Then I needed something large to get my teeth into whilst he got the parser in place. I tackled ⎕FMT. The symbol table management and ⎕FMT were the first pieces of code that I wrote in C. Debugging was in adb which was assembler level. Since C, at that time, was really a high level assembler that was not really a problem.

back to top

Rex Swain

I entered Vassar College in Poughkeepsie, New York in the fall of 1970. For the hell of it, I signed up for an "Introduction to FORTRAN" course in the school's fledgling Computer Science program. They had an IBM System/360 mainframe which was used by the administration during business hours, and in the early evening we students used punched cards and reams of 11x17 inch paper to do trivial things.

While waiting around for the system operator to deliver my job output (maybe 16 pages, pointing out a simple syntax error), I wandered down the hall and discovered a room with a few IBM 2741 terminals, which were based on the Selectric typewriter with its unique "golf ball" type element. Somebody was using one of them, and it was chattering away at the impossibly fast speed of 15 characters per second. The guy would type something and hit Return, and the machine would respond – immediately! It was love at first sight.

It turned out that these wonderful machines were connected by telephone to a mainframe running APL\360. This APL language used weird symbols, but I didn't care! I loved the interactive part of it. So I learned APL (largely from an online tutorial), taught an Intermediate APL course, and used APL for my senior thesis work in Economics.

Then I was told that there was a small company named Scientific Time Sharing Corporation that sold APL services and might want to hire me. I wanted to be a programmer but they made me be a marketing person – okay, but I still focused on programming. From 1974 to 1982, STSC grew from 30 to 300 employees, and sales of its APL*PLUS products and services peaked at over $30 million/year. It was a great period and the company had many amazingly clever and entertaining people.

Since then I have been self-employed, working on mainframes and personal computers with APL*PLUS, VS APL, APL2, and Dyalog APL. But I still have a soft spot for those old 2741 terminals. One detail I remember was that if your calculation was taking a long time, the system would twitch the typeball periodically to let you know it was still alive.

back to top

Nick Telfer

Sometime round about 1968 I was working in the BNFL Management Services department at Sellafield. I had a couple of programming projects on the go at the time. Programming in Fortran and IBM assembler. One day I chanced upon a book in the library with the rather mundane title "A Programming Language". Out of curiosity I opened it, and the rest as they say is history. I realised at once that it could be of significant importance. I took it back to the office and showed it to my colleague, Lindsay Russell, who agreed that it could be just what we were looking for for designing software. At the time we were writing subroutines to run as function calls in Fortran. My major project at the time was writing a replacement for a critical path management program which was urgently required because it was bought to run on an IBM 1620 (BCD variable wordlength, 28K memory). Totally incompatible with its replacement, an IBM 360. I think what first caught my eye was Ken's little critical path function which consisted of just a few lines of code. I realised I couldn't actually use it as it stood because it was "activity on node" whereas since I was constrained by the corpse of the program I was replacing I needed an "activity on arc" algorithm as that was what management wanted and the engineers were used to. However from that time on I don't think we ever went back to using our flow chart templates. Meanwhile we were also working on a file sort function to replace the painfully slow and inefficient IBM sort routines. We were pinning our hopes on an algorithm by C A R Hoare called QUICKSORT, in the Communications of the ACM July 1961. (Everything was spelt in capitals in those days, COBOL, FORTRAN, etc.) The function we produced, for the most part using what we called at the time "Iverson notation", had three entry points, called SRTSYS, QWIKST and BINSCH (those capitals again). Those words also became both nouns and verbs in a jargon only known to myself and Lindsay. It proved such a great success that even the COBOL programmers started to use it. (Nothing wrong with COBOL programmers, at least one of them went on to become a famous rock star called Elvis Costello). Ten years later it was in use by something like 60% of all the programs on the site.

"How can I find such and such in this table?" "Just binsearch it" "What do you mean?" "It's a little subroutine called SRTSYS, you just set it up using your specification and then call a thing called BINSCH"

I have no recollection of how I actually came to write the paper which I had published in 1978 or whether it was my idea or maybe my boss's but it made it to a publication called "Pragmatic Programming and Sensible Software" published by Online Conferences.

The critical path program which consisted of a FORTRAN main program with all the major functions designed in "Iverson notation" and implemented in IBM Assembler was still in use at least up until 1983, five years after I left and joined I.P.Sharp.

When I became responsible for the procurement of time sharing facilities for the site it was not long before I discovered that I.P.Sharp were offering an APL time sharing service. Naturally this was my first choice and proved very popular. About a year or so afterwards I joined IPSA working from home.

The chance discovery of an interesting book in a library changed my whole life. I've no idea what it might have been otherwise. I'd probably have ended up programming in HTML.

back to top

Vibeke Ulmann

Let me start my stating the blatantly obvious. I am NOT an APL programmer – I am a marketeer – specialised in Business Development, market communications & PR. So my journey with APL is a tad different – and shorter – in comparison to all the geniuses out there writing beautiful code.

I first came across Dyalog APL in 1991-1992 – when Gitte hired me on Consultant basis to help with some marketing in Insight Systems in Denmark. Soon after, Insight Systems was landed with the job of migrating the Adaytum budget modelling application from DOS to Windows. So my 'true life' with the power of APL used within an application started when the Windows version of Adaytum was completed, and Adaytum asked me to join as the Executive Nordic Sales and Marketing Director to build an organisation for sales, marketing and consultant services in Nordic and Baltic region. This was a magical moment, and the most difficult decision in my life. In hindsight, it's beaten all the other life changing decisions I have made before or since – and I fell instantly in love with the power of APL used in an application. From a demo perspective, using Adaytum, I have – literally – seen grown men on boardroom level reduced to tears, when I showed something complicated which calculated in 30 seconds, which they’d just spent 3 weeks trying to sort out in their football pitch size spreadsheets.

Since 2006 I have had the pleasure of working directly with Dyalog again. I have written many case studies, newsletters, press release, and user presentation 'blogs' from the annual user meetings. I have even been through Bernard Legrand's APL intro training course (and got the certificate to prove it). I still remember the eureka moment when I managed to program a matrix all by myself! It has been my privilege to 'pester' other application developers using Dyalog APL, to be allowed to write about the power of APL in their particular environment – witness Volvo, Laser Learning, the award winning Finnish archipelago navigation system in 3D, Cosmos, Take Care, Gama, Sophia, RiskFlow's Banking app, School Lunch ordering solution, a banking application migrating to Dyalog APL and many, many more.

When we celebrated APL in Berlin in 2010, Dyalog APL had nailed Unicode and Object Oriented Programming and achieved the targets set in 2005 for the 5 year plan. But most of the newest features in Dyalog APL such as speed ups, parallel processing, and new functions, were still in their infancy. We didn't talk about futures and isolates at all in Berlin. MiServer was a product – mostly of fantasy – in Brian Becker and Morten's brains, ditto RIDE. We did, however, spend hours and hours discussing Index Origin 0 or 1 (for the record; I am still for Index Origin 1!). One of my latest more memorable, and hilarious, evenings, was spent in the Dyalog House last December, with some of the clever programming people trying to come up with relevant squiggles to express some of the more poignant phrases leading up to the release of the new Starwars movie. The satisfaction when I 'got' the game and could contribute was immense. I felt that this was a true indication that I really DO understand some of the power in making beautiful code using squiggles – just for the fun of it. But I will never become a programmer. I'll just continue to write about all the clever stuff you guys do out there when programming super powerful applications using the Dyalog APL language.

back to top