If you have a photograph/paper that we can publish or a story from the first 50 years of APL, please email; we'll collect the stories and photographs on these pages for you to enjoy during the next 50 years! Contributions can be anonymous if preferred (please include this request when emailing us).

The recollections on this page have been contributed by: David AyreDan BaronetAndrew BrownSteve CalnekJohn GerthLarry GoodwinAaron HsuRoger HuiGregory JaxonCurtis A JonesRoger KumlerStefano LanzavecchiaGary LoganMichael K RosenbergJack RuddJohn ScholesAndy ShiersGeoff StreeterRex SwainNick TelferVibeke Ulmann

David Ayre

Like many old timers, from 1980 onwards I passed enthusiastically through the learning curve of Z80 source and assembler and MS BASIC on my TRS-80 clone. In a brief period between cassette and DOS I discovered APL-80 from RAMWARE.

Although the symbols and keyboard mapping was 'challenging' it opened my door to APL and thereafter to software from STSC and IBM for my Amstrad, XT and successors.

My early usage was totally into logic applications and the interfacing to instrumentation through ports with much )peek and )poke! Later, as a professional electronics engineer, I encountered APL used for the highly effective prototyping and development of a process control/plant monitoring system in a North Sea oil & gas Terminal (the Micro-Vis system).

The development of computers and software has been astounding, from DOS through GEM and through about eight versions of MS Windows to the present. Initially the cost of the Windows version of APL was prohibitive for personal use, and coinciding with the departure of floppy disks by the industry, I successfully (financially) embraced MS Excel with VBA.

Only recently discovered by me, DYALOG APL-64 15.0 running under MS Win 8.1 is a superb platform and it has completely revived my interest in APL.

I began above with 'old timers'. My generation will expire as a close group of mature APLers, but if we do not address and encourage the young from an early age with material written to inspire them (unlike tedious manuals) then I fear for the market growth of this unique language.

back to top

Dan Baronet

Having learned FORTRAN, I was thrilled to learn in 1975 that APL was going to be offered in high school at the next semester. I managed to get hold of the book from Gilman & Rose (the smaller original black edition) and an account at Laval university and learned it quickly before the course was even given. After high school I was hired immediately as an APL programmer and since then, except for 2 years when I did Pascal and J, I earned a living using APL. APL has been very good to me :-)

back to top

Andrew Brown

I knew Roger Moore when I worked at Sharp and have fond memories of him. I remember signing off from the time sharing system at about 2.00 am one morning, having had a frustrating time at the terminal. I logged in again at about 6.00 am and found the same problem. So I called IPSA help – the phone was answered by Roger. At 11.00 he phoned me back and said: "I think I am beginning to see a problem". He called back a bit later and explained what he had found. The operator started by asking whether there was enough space to do the operation on this variable.
Yes – start
No – go through garbage collection and start again
Maybe – start. Then while working it found it had run out of space and had to go through garbage collection - part of that collected and deleted was necessary.

Remember that a WS was only 32k at the time.

Later we formed a separate company from IPSA to add hardware development skills. (We developed and built the hardware and software for the Information display systems in all of Canada's airports.) I became finance director and used APL for the accounts. Partly as a result of my discussion with Roger we adopted the attitude: "If a software engineer says something cannot happen - fire him".

I also remember that we had another Government contract and the engineer in charge came to me suggesting that it might be an ideal case for APL. I told him that that could be the case but it would take him longer to explain the problem to me (and for me to understand it!) than it would take me to teach him (part of) APL. He laughed but said he would try. After about 10 minutes he agreed and we had another convert.

back to top

Steve Calnek

So, if my math is correct, APL was born in 1966 and it was only 5 years old when I started using it as a 15 year old high school freshman in 1971. At the time I saw it as a way I could get out of classes, but I got drawn in, it largely defined my high school experience, and eventually it became a lucrative source of employment after I dropped out of college just a few years later. I'm no longer an APL programmer, but I am still a computer programmer – there hasn't been anything else I've really wanted to do. Working with APL had a HUGE effect on me in how I think about data and doing operations on sets of data instead of iterating through cursors and other mediocre approaches that are so common. If someone offered me a job today programming in APL I would jump at it, but until then I am grateful that APL set me onto a path that has been both productive and satisfying for so many years.

back to top

John Gerth

I first saw APL running under Multics at MIT in '70, but it wasn't until Bob Heterick decided to build courses for Virginia Tech architects using APL/CMS in '74 that I began to appreciate its power and beauty – even as we lugged an IBM 5100 around. Later we became perhaps the only US site to run Alfonseca's APL for the System/7. In those years I was impressed by Ken Iverson in part because, unlike most talks which relied on artificial examples, he always wrote and spoke using substantive problems and making real the idea of notation as a tool for thought.

I was hooked and found my way to IBM's San Jose product development group in '78. APL shaped my life for two decades. More precisely, it was shaped by the friends and colleagues with whom I worked and played. Alex Morrow introduced me to my wife and Jim Brown led the TGIF get-togethers with Nancy Wheeler, the Anglins, Wheatleys and others playing and singing along. Of course, the one voice I can still hear singing is Ampico J. Steinway, aka Mike Montalbano. The year he wrote "APL Blossom Time" we had to work the midnight shift to get quality mainframe time and Mike always had KFAT on the radio blaring out Leon Redbone and other outlaws.

We were turning out a steady stream of products across IBM platforms and with Dick Dunbar and Ray Trimble solving system issues, I was able to move over to the language team where they were re-engineering the APL2 prototype. I learned a lot from programmers like Ev Allen and testers like Rich Harvey. One summer Eben Moglen was our intern as we rewrote memory management; figured out how to JIT the scalar functions; and reduced some common idioms to machine language. As a member of ANSI X3J10, I got to know Burroughs' Greg Jaxon, who explained how to "save the (parse) trees" and learned the IEEE 754 floating point standard, along with appreciating good food and wine, from STSC's Bob Smith. Later, during the controversy over "strands", John Bunda and I were able to work out a simple model for syntax analysis which could represent the various designs as just differences in a table of binding strengths.

I spent the second half of my IBM career at Watson Research where I transferred to work for Falkoff's design group. The most important work during those years in that group was done by Don Orth, first with Yorktown APL Translator which produced quality FORTRAN code for computational algorithms and later added a handwriting recognition front-end which accepted standard 2D math notation. Don and I carpooled together for years and I learned more about math on the Saw Mill Parkway than I ever did in school.

After leaving IBM for Stanford in '96, I renewed contact with Gene McDonnell who would sometimes cross over the El Camino for a walk and talk around campus. And just this summer Arthur Whitney revived the discussion of syntax analysis and how the binding table decomposition looked for his new language. After a half-century, we're all still traveling that long and winding road.

back to top

Larry Goodwin

I was a student at SUNY Binghamton and was looking for some class to take for the summer of 1975. There were six, 2-hour classes offered, Boolean Logic, PL1, ..., and something called APL. I had played with Fortran years earlier and found it interesting so PL1 sounded good and it fit my summer schedule.

I found the courses interesting and PL1 was sort of back in the days for Fortran. Finished with everything but APL, I finally dove in. Many hours later I came out, wow, a new world.

Then a friend, Steve Holmes, moved to Bethesda, Maryland to join his brother, Al Holmes, at STSC, and he got me an 800 number to dial into their APL system. Meanwhile I was converting my ADM-3 glass TTY into the APL char set. It worked but no overstrike, or just the last char visible, but then I had APL at home. (Try programming when you can't see the overstrike.) The idea was to hook me into joining them. I graduated, and joined. Steve and I have the only existing ADM-3 APL terminals.

I worked in support for a while and then joined the development team, working on the mainframe APL. Later five of us created the "C" based APL under UNIX; Bill Lewis, Mark Osborne, Bill Rutiser and myself, with James Wheeler managing. What a great job. I built the workspace, garbage collect, symbol table, file system, Quad Arbout and the external process interface, Quad XP.

Bill Rutiser built the grammar, and invented a sophisticated parser generator, which was written (and ran) on APL on the STSC mainframe timesharing service. This created tables which were then imported into the C source code.

Bill Rutiser and Bill Lewis built the interpreter and executor. The APL source lines were saved as-is so the user's formatting would be preserved for further function editing. Source lines were interpreted on a first-use basis, sent through the parser and a walk-and-emit phase that created bytecodes. These were then saved and reused if the lines were executed again. If the Execute primitive was encountered, this process was done on the fly.

About midway through the project Bill Lewis moved off and did the port to the 386 under MS-DOS. This work utilized the Phar Lap DOS Extender and MetaWare High C compiler. It was done on one of the first released Compaq 16 MHz 386 Deskpro PCs. This became a successful product, which we called Zippy internally. The APL system itself ran in 32-bit protected mode. And the user interface was an enhanced version lifted from Phelps Gates 16-bit APL*PLUS/PC. Communication between them was with a thunking mechanism.

Lewis had his hands in most everything, as he had the first prototype running quickly, even before the workspace existed. He was the guy who remembered everything, as when a bug appeared in a port, Bill would remember it and point out that we had fixed that on the Wicat port two years previously and sure enough, there would be the fix.

Bill Rutiser was working on speedups of internal processing and he created a Forth like internal mechanism, SCEX, the Scalar Execution Engine in 68000 assembly. Rutiser then went on vacation and I got the job of making SCEX in 80286 assembly, with the 68000 code as documentation. Converting to the 64k segmented system was an ugly painful job. I have no love for the Intel architecture.

Our manager, James Wheeler, wrote SCEX in C, which was a great addition and made porting so much quicker and easier. I ended up doing several ports and the "-S" option to the UNIX compiler left the assembler code around after the compile. Tuning the resulting SCEX assembler code to match the floating point hardware of the machine and by selectively using registers for temps and constants, the resulting code ran our benchmarks about 6 times faster than the base C version. At least it did on the last MIPS machine that I ported. It took about a week to do a port and the associated SCEX speedups.

One of the really useful tools we had was the testing workspaces. Whenever we found a bug, we built a test function that executed that particular bug. So we had a convenient way to test all the edge and corner conditions that came up during building and porting the system. It also worked well for performance timing. We had a good relative indication of how well a particular port would perform.

back to top

Aaron Hsu

I am a relative newcomer to APL. A baby amidst sages, really. That hasn't stopped me from appreciating a language much older than myself. I started my programming life on QBASIC in DOS machines in the 90s. At that time, I was fascinated at getting these machines to do things for me on the screen. The idea that I could program these systems was amazing to me as a high school student. Later I began to realize how much QBASIC limited my own abilities on the machine, as I could express what I wanted, but the system limits wouldn't let the program run. My programming mentor at the time suggested that I give Lisp a try. After some research, I discovered Scheme and spent the next 10 years of my life in that world. Scheme has shaped and formed probably ever aspect of my programming aesthetic, until I spent time with APL. Despite learning other languages, none of them, until APL, displaced Scheme as my primary programming language for the simple fact that none of them really offered something that I couldn't readily re-implement in a few lines of Scheme code. Object system? Type system? Pattern matching? Security? Abstraction? High-performance compilation? I could get it all with Scheme.

At some point I began to feel that I needed to learn something new. I started to ask myself, what language did I know the least about, but about which I had the most pre-conceptions and prejudices? The answer was obvious, APL. See, before this, I had been teaching beginning programmers Scheme at Indiana University and I still remember the first day of the first lab that I taught with one of my academic seniors we showed a line of APL on the board. It turns out it was the line for the Game of Life. We used that function as a shock function to preempt students from complaining about Scheme's parentheses. And that's really about all I knew of APL up until I decided I needed to learn more.

So then I started reading, I picked up an APL implementation, and started playing. It wasn't very long before I realized that this wasn't like anything I had ever done before. I picked up APL quickly, and it wasn't long before I was powering through algorithms and expressions at a pace and with more clarity than I would have ever thought possible. Suddenly, I wasn't inventing a new language every time I needed to express an idea, like I was in Scheme. Instead, I was just thinking natively in my programming language in a way that didn't require excessive or mandatory abstraction.

I spent a while after that trying to figure out how to get "APL" into Scheme. I failed. This is the first and only time I have been unable to capture another language in Scheme, and it remains one of the main reasons that I continue to spend my time in APL. Scheme is the language of least restriction, but APL is the language of clear human thinking. It was APL that opened up my experiences to seeing that there was more to languages and more to the expression of ideas than could be expressed in mechanical guarantees or programmatic tricks. APL showed me something I had been hunting for, that idea of a tool of thought, something that really could be a native competency of human communication. And it is still the only language that I have found which even begins to approach that magic space of human clarity and machine efficiency.

back to top

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.


      p←perm n;i;ind;t
     ⍝ all permutations of ⍳n
      t←perm n-1


      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 ( 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:

1 2 3 4 5 6 7 8 ...
1000 999 998 997 ...

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'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 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