Notation as a Tool of Thought in practice: Rob Hodgkinson on a Surveillance System in q/kdb+

An oral history that spans the transformation of financial trading from open outcry to today’s electronic trading systems

Rob can often be found on a motorcycle in Australia or New Zealand touring with his mates

This article is based on an interview with Rob Hodgkinson of Sydney, Australia. Rob is a serial entrepreneur and expert computer programmer, whose over 40-year career encompasses the building of many of the first electronic securities trading systems across Asia Pacific and beyond, to the founding, and funding, of a number of technology startups, several of which have been acquired by public companies around the world.

In this interview we focus on Rob’s intellectual journey as an engineer, which started at I.P. Sharp (IPSA), a Toronto, Canada-based technology consulting company famous for, among other things, disseminating APL globally, which ultimately led to Rob building expert financial systems in q/kdb+.

At IPSA Rob worked directly with Ken Iverson, the Turing Award winning inventor of APL, and Arthur Whitney, the creator of programming languages A, k, q and the database system kdb+. In the years following his start at IPSA, Rob has always grounded his work in the core concepts of Iverson’s famous Turing Award lecture and paper, Notation as a Tool of Thought.¹

Editor’s Note

This article is based on an edited excerpt from an interview conducted by Abby Gruen and Kyoung Jae Seo of KX on January 22, 2026. The interview has been lightly edited for clarity and continuity while preserving the interviewee’s voice and technical intent.

Foundations in Programming

Notation as a tool of thought was a seminal paper that really laid down what the hell is this notation about²? Like, why write in Greek symbols at the time? Why try to summarize everything into functional tokens, or functional symbols, one at a time for every abstract concept that you wanted to apply? I’d really urge all current q/kdb+ developers to go back and read that paper in detail.

What it presented was a way of looking at the world where you could express things more concisely, more efficiently, more precisely and less ambiguously in an executable format, and you could then try something, modify it, revise it, and try it again, thereby writing good code. It is as simple as that. It has been a philosophy that attracted me to APL when I first read Notation as a Tool of Thought, which was written in 1979.

I.P. Sharp (IPSA)

I joined IPSA in 1979 and went straight into using APL, which I had learned in 1978 in university, and it was wonderful. The lecturer at university gave us a simple example. He had us emulate the operation of a computer chip, to write out the instructions. He said, I want you to write the code that does all of the operations using APL to model the machine, which was the IBM 360. That was fun.³

But the array concepts didn’t truly hit me until I got into IPSA and saw some more deep-rooted stuff, and the challenges that IPSA posed. The culture at IPSA really encouraged innovation, genius, hard work, and learning more than the guy next to you. It encouraged you to be better at APL.

We learned all the basics, including idioms and routines. They are the same idioms you use in k, q and kdb+. I see k, q or kdb+, not as a quantum leap, but a paradigm shift, the next step of evolution. It took all of the functional array concepts and provided them in an ASCII directly executable format by using special symbols that all then had the same sort of meaning that we had in APL. I immediately saw that was how k worked and it drew me to it.

Working with Arthur Whitney in Australia

I met Arthur Whitney at IPSA in 1980. IPSA’s Australian branch manager, Chris Sanderson, brought on Stephen Taylor from England. He told Stephen he wanted to create APL on a departmental server in-house. Stephen said, you should be talking to Arthur Whitney; he works with “the Zoo” (a subset of senior programmers at IPSA) in APL on various systems, including the overseas airline database. He is very bright, and he has his own ideas about APL.

Chris brought Arthur out to Sydney, and Arthur was fascinated with the project. He wanted to write APL interpreters to express the concepts that he saw in APL, He had already modeled stuff in C, so he came out and started the project. I ended up working on the project with him, and I learned the way that he codes from the ground up. I’m one of the few people that has had that experience, I realized that I’m learning from one of the best and I should just shut up and learn. And I did.

Arthur was great to work with, but quite rigid in his approach; however, if you argued with him and gave him something to think about, then he respected you. We got on quite well. Arthur finished the Sharp APL/HP interpreter in two or three years. We got the system up and running. I then had the job of aligning all the APL so we could take the Sharp APL source code and run it unchanged on this departmental server. That was the goal, to reproduce Sharp APL, and it was on an HP Unix environment in C and we got it running and started importing packages from Sharp APL.

I recall the first time I succeeded in loading and running the PLOT workspace, then I spent ages drawing amazing images on a color screen, that we were only able to send to a flatbed plotter on our APL terminals. That was a total epiphany; we then had many keen APL people watching.

Introduction to Electronic Financial Markets

In the 1980’s, I spun off and began building trading systems. My partner, Paul Phillips (who I also met at IPSA), and I wrote matching engines that were really fast. I was optimizing C code to match as quickly as possible. We had machines back then that were just basically overgrown IBM PCs, and we could match a million orders a second in-memory, which was way above any SQL database, or other database.

The exchanges were using databases, not to match, but to record all transactions. The order matching was all open outcry, floor trading. They had to collect those tickets and enter them as transactions into a database. That was how trading was done at that time.

Electronic trading started in the mid-1980’s at the Singapore Exchange (SGX), closely followed by the Australian exchange (ASX). Paul wrote a real time, in-memory matching engine for SGX from scratch, and it was truly pioneering.

After that the Shanghai Stock Exchange approached Paul about building a trading platform. Paul said, the first thing you need is a benchmark, so you can see how vendors should match, because speed is of the essence when matching in-memory. They engaged Paul and I to write a prototype benchmark system, and we wrote it in C, which was what Paul had written his matching engine in for SGX. We completed the benchmarking system in three or four months, and the exchange decided not to go to tender. Instead, they contracted us to finish the benchmark as their new platform.

The Shanghai system was barely live when we were contacted by a Swedish systems integrator saying they had just sold the first HP Unix box behind the Iron Curtain to Moscow Interbank Currency Exchange (MICEX) and they needed a matching engine. Russia was starting a market in several different asset classes. We won that deal and all those experiences led us to deliver systems in Indonesia, Istanbul, Budapest, Oslo and Helsinki as well as other venues. Eventually our company was acquired by Computershare, and our system ultimately ended up at NASDAQ under a different name (XStream).

Working with Arthur Whitney in New York City

All of this background knowledge of electronic trading systems made me realize that financial processing in financial markets can be so much faster if it is done in-memory. Around this time, in 1988, Arthur had moved to Morgan Stanley and was writing the language A. He called me in Australia to come help work on the system they were building.

It was gratifying to be called by Arthur, who I really respected, and who I thought was brilliant. He said, we’re doing an interpreter called A for program trading — analytical, proprietary trading. I have written most of the interpreter, the guts of it, and we can run the algorithms, but we need a couple more mathematical algorithms.

What I had previously done on the old interpreter were the transcendental functions, (sine, cos, tan) and related things like modulo, as well as the gamma function, and the matrix inverse routine. He said, we need all of that. Can you come over to New York and write it?

I took a three-month leave from my job and went over and lived with Arthur and his wife Janet Lustgarten, co-founder of Kx Systems, in New York. We built the system and Morgan Stanley asked if I’d like to stay in New York, but I returned to my job (and my wife Glenda, also ex-IPSA) in Australia.

Joining forces with First Derivatives (FD)

When kdb+ was released in the 1990’s, I was aware of it and understood what it did, but I really got to learn it when First Derivatives (FD) bought another company Paul and I were working with (Hologram) in 2008. FD decided they were going after straight trading solution tick capture. Initially, they just wanted to capture the ticks for the quants at the banks to analyze. I said to FD, why don’t you have a package for analytics; or for market making; or for execution management; or best execution, or whatever. But at that time FD was a consultancy; they didn’t see the value in products.

When the Australian Securities and Investments Commission (ASIC) came along, I was working with FD selling tick capture to banks like Macquarie, HSBC, ANZ, Westpac and National Australia Bank (NAB). We had a number of banks already running kdb+ for tick capture, but they then did their own thing with it, producing their own solutions. There was no package on top. I thought this is what we have got to be able to harness and make a product out of. Then I got the ASIC request for proposal (RFP).

The ASIC Financial Surveillance System Use Case

The ASIC RFP asked for five key components in their surveillance system:

1. Realtime Event Processing (alerts)
2. Post trade analysis
3. Data storage (ie. the Market Database)
4. Hosting Capability
5. Integration across all components and external interfaces.

Wow! I visualized a perfect use case for kdb+. I just needed to convey ‘the whole’ clearly and explicitly to ASIC. The truth was, we had components, but we did not have a Market Surveillance solution. We could integrate the components and also help them plan for future features that turned out to be scraping chat rooms, emails, texts for “sentiment analysis” and then later AI and inference alerting, and related functionality. I saw we could do the whole lot with kdb+, not the AI component at the time, but everything else, and we could integrate with their workflow tool, or we could write the workflow ourselves.

Because this was the first deal of its kind at FD, I needed to go to FD’s headquarters in Newry, Northern Ireland to get approval for the RFP. There was some resistance because at that time FD’s business was deploying consultants, and Brian Conlon, the CEO, said this is only a single consulting project. I said no, it’s the opposite, Brian. If we do it right once, we have built a surveillance package that can evolve; we can resell it to other places around a new business delivery model called market surveillance. If we add a compliance component, it can go to brokers as well.

I said to FD, if you don’t reach out to do this now, you probably never will, and someone else will do it, and you will have missed out. This is an opportunity with one of the top seven market regulators. I know that they are using a platform called Securities Markets Automated Research Training and Surveillance (SMARTS) and they have gone to tender only because they want assurances that they are still using the best technology.

SMARTS was a mix of various technologies. It was not universally or holistically developed. There was no core tick database underneath it, so they couldn’t have access to the data. If they wanted to apply a surveillance alert, they had one date where they could go through the transactions. If they wanted to search the transactions for some occurrence, and do it for the last week, or the last month, they basically had to loop each day; read each data set; reproduce the logic and rerun it to get the output. Then they had to MapReduce the results to put it all together. It took them ten to twenty minutes to run it. Because SMARTS was slow, it was another impetus for ASIC to see if it still was the best technology.

I told FD that I knew from my experience with the banks, that with kdb+ we could run a query over a date range, given a volume of half a billion transactions every day, in less than a few seconds on an appropriate machine. That won the argument, and FD said if you win the deal, we will support you.

While writing the 150-page RFP, I realized there is another lesson here about kdb+. People can talk about kdb+ and its features, but they’re not always very good at relating the features to someone’s requirements — and describing how a feature meets their requirements, how it would work. In the case of the ASIC project, it was all about the central database. The tick capture, the surveillance, the order book replay, they were all on top of the same database. The lack of a database was also the key weakness in the SMARTS solution, combined with the fact that SMARTS used disparate technologies.

Demonstrating Notation as a Tool of Thought to ASIC

We responded to ASIC saying we would capture everything in a single database and deliver all of ASIC’s requirements directly from the database — and it would take a couple of months to write the system. I felt our strength was the notation’s expressiveness, and being able to write statistical alerts, outliers, statistical distributions and so forth in one line. It was not rocket science; we weren’t putting a spaceship on the moon.

ASIC then made their selection and shortlisted three companies who were given some data and asked to come into ASIC’s offices on three successive weeks for meetings and demonstrations. The tender ran in two stages. There was an REOI (Request for Expressions of Interest). Then they proceeded with the best two or three responses and asked specific parties to give a ballpark price, structure, and solution.

The next step was the RFP where we had to add the result, write a proposal, and give a binding total project cost. It was getting to the pointy end of the whole thing when we walked into a shortlist meeting at ASIC, and we had nothing to show except a database. We had put all their data into the database and told ASIC we could do a query; we could do a select; we could get trades for BHP, or whichever ticker symbol, and we could pull all this data out because it is in a really well-structured database, which is the key to what you need.

One of the members of the senior panel from ASIC was an ex-investment banking professional. He said, OK, you know you are on the short list because we liked the story that you spun in the RFP, but we know you don’t have a surveillance solution, so now you need to convince us that you can do this. We gave you data and we know you can’t show us any alerts running, so I am going to ask you the same questions that we asked the other two providers.

Firstly, let me ask you, do you know what insider trading is? I said, yes, I understand the concept. Someone has access to information before it’s public. They make trading decisions based on that. The information is made public and then the price moves, and they profit from the result.

The panelist said, that’s a pretty good description. In the data we provided you, in one particular security, in a particular month, there is an occurrence of insider trading, and I’d like to understand how you would find that.

In the meeting I was joined by our senior engineer, Nion Chang, who I planned to appoint as the system architect. Nion was one of the best kdb+ programmers I had ever met. He is an actuary and he can write kdb+ code that is clear and expressive using the notation. His goal in life is to write the most elegant, expressive functions he can, which is also my goal. We share the same focus and passion.

When ASIC asked this question about insider trading, I was sitting next to Nion, who had his laptop open and was looking at the database. I said, well, maybe we can actually use this as a workshop and show you how we would do it. Let me lay out the requirements and you tell me if I’m right or wrong.

I said, we know there was an announcement [that would affect a company’s stock price either up or down] and you gave us the announcement dates. We would create a window of time before and after the announcement. The start is maybe one or two weeks before the announcement, and it’s a parameter. The end is maybe one or two weeks after the announcement, and it’s a parameter.

What the function would do is take these parameters, search for all trades in the database by security, and we would work out where the maximum profit occurred. That is where someone bought low and sold high on a positive price announcement or sold high and bought low on a negative price announcement, or short sold. It’s got to be one of those two situations, right? They confirmed, yes, that’s correct.

While I was speaking, Nion had started writing the query in a script and a function, using the parameters to do it. He was just transcribing what I was describing and writing the script right next to me. When I looked at his screen, he already had four or five lines written. I thought, wow. I said OK, if we ran that, we would expect to find after the announcement close window who traded in that security and who profited from that trade in the window time, and rank it in descending order by profit, to see any likely key offenders at the top. Those are probably the key suspects.

They said, yes, that’s right; that is the way you’d solve it. Nion tapped me on the shoulder and said OK, I’ve got it. While I had been describing the problem, Nion had converted what I was saying and wrote the notation which produced a running and executable copy in real time.

I handed the meeting over to Nion, and the date was something like the 20th of January 2012 or so, and the window was two weeks before, and the trailing window was two weeks after. Nion ran it, and it showed the trade groupings; worked out the differences; worked out the profits and sorted in descending order. The big profit maker came first. Nion highlighted the participant, the broker, as well as the top five. ASIC said, yes, that’s right, that was amazing, show us the code.

ASIC already knew there was market manipulation, and we discovered it in front of them. It took six lines of readable q. Then they posed another occurrence for us to discover without giving us the date of the market manipulation. Nion had already loaded all the announcements from the data they had given us, so he then re-ran the query over a time frame going back 12 months because, he’d been told it was in the last 12 months. And bang, it came up with another instance in March of the previous year.

The panelist looked at it and said, OK, it’s right again, and you haven’t changed the code. That’s pretty impressive.

Nion then said, since it is so fast, we can run it over all the data, so then he re-ran it in the full three-year window of data they gave us, and it pulled up a third instance with the same broker. But it had happened a year and a half previously. The panelist looked closely at the result, and said I’m not sure if we have that one.

ASIC asked, what if you had to do order book reconstruction and order book monitoring? Our response was that we reconstruct the order book in real time, which is what we do with the bank data. No problem. We would just do it the same way and raise order book alerts on that. From then on, everything ASIC asked for, we could answer in English and show them a bit of a q code at the same time.

I honestly believe that was what won the deal for us. We had been honest and said we didn’t have a surveillance solution, but we could write it. We said, trust us, and then we showed them how we would do it.

What was different about our solution compared to the other two on the short list was that their solutions had a system database stored somewhere, but they could not directly query the database. They had screens and dashboards that showed them the results, but they weren’t fast.

With q, we basically showed them a V12 engine running, which they could put under the hood and see the performance on their dashboard. They were driving the world’s fastest engine. We focused on how the notation brought out the performance of the engine, by addressing all of their requirements without the sore points, like MapReduce, which was slow over a date range. With q/kdb+ they could just go bang and have their answer in seconds because it was optimized.

Observations about Arthur Whitney’s technology

When I initially started working with Arthur, I was shell-shocked by his C code. It was dense and I struggled to read it. It was full of macros. I thought, my God, how can you write like this? Plus, he didn’t believe in white space. He wanted everything to fit on a page, so he joined lines together to have a rectangular block of code that he could look at in one go. He said, I don’t like having to scroll. It taught me to look at macros differently.

Some anecdotes of that time:

Rob: “Why don’t you spread out your lines and indent for readability?” Arthur: “White space is a waste of space. I want to see ALL the code for one section on one page, then I can truly analyze what to improve as I see it all in front of me”.

Arthur spent a lot of time walking around analyzing a single sheet of paper. I recall a fire alarm made us have to leave the building; I ran into Arthur in the stairwell standing still reading a page of paper. I said, we have to leave now and go outside. He read as he walked with me.

Rob: “Why do you have all these single letter macros (W for a while loop, P to print)?”

Arthur: “It’s like a mini dictionary the code uses, macros expand inline to C code, so I optimize the macro definition and that optimization permeates throughout. It also means my C code is shorter, terser and more expressive.”

Rob: “Why not put a few comments in to help explain your approach?”

Arthur: “Comments are bad. The code should be so clear, well defined (aka optimized macros) that you can follow the code and understand exactly what is happening. Comments become stale (the code changes; the comments don’t), and that is far worse than having no comments. The code is the single truth; comments are a distraction.”

If you think about learning the English language, what’s the first thing you have to master? It’s the dictionary. Arthur’s macros created the dictionary. They created capital H and capital P and the loop constructs. All of these things were in-line, one-character macros, but Arthur had optimized the macro C code (looping, printing, running over memory objects).

Once you had that glossary of terms, or the raw dictionary, then when you are reading Arthur’s code, it all made sense. You can see this even in that one-line C interpreter that Arthur wrote for the J creators, Ken Iverson and Roger Hui⁵.

I was there with Ken and Arthur at Ken’s flat in Toronto when this idea was discussed. Arthur said, maybe I could write a shell of an interpreter to help Roger come up to speed. This was before Roger joined Ken to write the programming language J. We discussed the idea for the prototype, and I completely agreed. I said, if you wrote a shell like that, then it makes it easier. Roger can just analyze how he completes it. Maybe he writes the parser differently. Maybe he doesn’t use recursive descent; he uses another form, or a different structure, and he works on the tokenizer. When Arthur wrote that shell, the last line of that C code was one line;

main(){C s[99];while(gets(s))pr(ex(wd(s)));}

This is the REPL: gets() to READ, wd() for word tokenize & parse (word formation), ex() for EXECUTE, pr() to PRINT then LOOP in the while().

The whole interpreter was built on that. You could basically follow everything right in front of your eyes on one page. It was pretty amazing.

Programming Language as a Tool of Thought

When we were in front of ASIC we could express the problem in q notation. It was very important to describe in words the concepts involved in market manipulation and show how Nion could paraphrase each concept and code it exactly.

It comes back full circle to Ken Iverson’s paper; Notation as a Tool of Thought. It is exactly that. The notation translates the thought processes straight into an executable notation. If someone is showing me how to do something in Python or C and they start out by writing a while loop, or an if and an else construct then as they go down the page my eyes glaze over. I don’t want to watch them write syntactical garbage. I want to see the algorithm.

That is what q, or APL, or J, lets you do. When it is assisted by someone walking you through the concepts to describe it, it becomes a natural flow. But you do have to accept the constraints. You have to agree upon the predefined set of primitives to express your algorithms. It is not just a free-floating form; you need to give in to the general construct. It is like a toolkit, and someone has to have the overall knowledge to put the tools together.

We chose different tools for different solutions with ASIC, for example, we were not always going to use a table solution, or if we were doing something around denominations of coins or notes, to work out the currencies, we would want an encode primitive, and so forth.

I think programmers don’t pick the right tools enough. Developers simply say, I am a C programmer, or a Java programmer, or a Python programmer, and they write a bunch of code without stopping to think about how they can fine tune it, or be more expressive, or be more concise. They never think about that, but that is what Ken thought about from the beginning.

Brevity and Innovation

I think Arthur’s database is unique. It would be very hard for someone to clone it. The influential database researcher Christopher J. Date’s idea of a relational database was that it is row-oriented, where each record on the disk is basically a row of the database with all the different column formats. Date thought about it that way so it was easier for him to do vertical selects. But Arthur came up with the idea of associating the lists in APL with columns of like data, so all the like types were in columns. Those were his raw lists, and I think that was one of the absolutely seminal ideas that Arthur had.

At one time, Arthur’s favorite book was called The Little Lisper. It is a very short book that gives you an understanding of the programming language Lisp back-to-front. Arthur loved that you could read all about Lisp, and learn it, in a book less than half a centimeter thick. He also referred to Donald Knuth very often, the Art of Computer Programming. He was always reviewing Volume 3: Searching and Sorting and seeking refinements.

I have always found it interesting how Arthur was fascinated by making tiny, expressive footprints for code. He really liked the Lisp language, which was why he initially used Lisp concepts when he was first playing around with k and trying to make it work. He ended up bridging them.

One of the biggest eye-opening things I saw was the relationship of dictionaries to tables, and especially how just the flip of an equal length N-tuple dictionary produces a table and vice versa. I thought that was really neat that you could flip a dictionary to get a table because it is a group of name value pairs. That’s what a table is, but the values are all columns of equal N- tuples.

There were a lot of observations that Arthur made where he thought, if I clean this up, I can make this really elegant. The fact that he extended flip on dictionary to table and tables to dictionary I thought was fascinating and it has been incredibly helpful because I’ve used that in programming constructs several times.

Again, in Python, they don’t associate dictionaries with tables. You’ve got dictionaries, and you’ve got tables, but never the twain shall meet. There’s no relationship. Well, there is, and Arthur saw it. But these guys didn’t. In the same way, other guys picked up the word “columnar,” and they wrote columnar databases, but continued to struggle with SQL as a verbose language for relational algebra.

Other designers don’t think out-of-the-box. They try to copy other people, but they can’t think and innovate themselves. That’s what Arthur did. Truly. He came up with more expressive ways of doing things. If you look at these other databases, it’s the same horse, a different jockey. Yes, it’s got a column in a database. It’s faster, but you still query it with SQL. You can’t do any of the nice group by stuff, or bucketing, or time partitioning, or other functionality that Arthur has built into the language. These guys are still scratching their heads.

Observations on Ken Iverson and Arthur Whitney’s Philosophies of Language Design

Ken Iverson

Right from the get-go Ken conceived operations on the whiteboard in linear algebra that he wanted to express in his notation to make it less ambiguous. Ken put reduce into his language on lists back in 1958 or so when he first drew it on a whiteboard. He had the reduction operator reduce, and he had the expansion operator, expand, which became known as, reduce and scan.

It was only when he got to IBM in 1960 that Ken’s colleagues looked at his notation and said, we could make this run on a computer. Ken said that would be great. I won’t have to do it on a whiteboard. Then Larry Breed, Dick Lathwell and Roger Moore built the first APL interpreter within IBM⁴.

I met and worked with Ken Iverson on numerous occasions when I was at IPSA. He came out with a training course called A Working Introduction to APL at IPSA and after I gave him feedback, I was gratified that he would redirect questions and improvements back to me to see what I thought.

When I saw Ken write the each operator with APL, dierisis with a greater than sign, it was called dual disclose. He called it the dual primitive, and I didn’t quite understand it. I asked him and he explained because if it is dual disclose, you disclose the data, apply the function, get the result, then apply the inverse of the disclose function, of the dual, which was enclose — which was basically unbox and box. That’s what each does now. But I didn’t get it at the time. Ken said, it is not that hard, we use it every day of our lives.

Ken said, you load the dishwasher, run the wash cycle, then unload the dishwasher. That is an inverse. So many functions have an inverse, it is natural, and we don’t think about it. What we are trying to do with these mathematical concepts is capture these concepts from real life and apply them. That becomes more complicated, of course, when you get to Lagrange formulas and Fourier transforms, but the essence is there.

Whenever you had a conversation with Ken he would pull his terminal up in front of you and explain using his primitives what he was talking about to describe something. If you said, Ken, can’t you just talk to me? You always show me on the computer. He would reply, if I talk to you, I’ll use the whiteboard, but I figure the computer is easier. The notation he wrote was for the whiteboard, for mathematical expression. He wanted to write on the whiteboard an expression that was clearer, more efficient, and less ambiguous than mathematical notation, which he regarded as having ambiguity and being verbose for iterative operations.

He always relied on the executable notation, and the essence of APL notation is that it is unambiguous. He was right, because if it is executed on a computer, it cannot be executed in two different ways based on how you read it. It executes in a single way based on the rules of the language; it is just right to left. There is no notion that times has a higher precedence than plus, all verbs (functions) are equal.

Ken enjoyed using this notation to explain difficult mathematical conceptual phrases that were just difficult in standard notation.

Arthur Whitney

On the other hand, Arthur chose primitives for the particular use case that he was trying to deliver. In the case of k, it was for financial applications.

For example, Arthur didn’t include encode and decode because while they were useful in APL, they were for pure math applications. Arthur wrote k for applied finance and program trading, where these functions were not typically used.

Arthur had precious few available single letters and symbols that he could use for primitives. He really tried to be minimalist. That’s also why in some ways he packed so much into the characters. That was a big challenge.

To get all of these linear algebra functions associated with one character symbols working, he still had to do right bracket, left bracket, and slash colon, and have an each right, and so forth. He also had to come up with diglyphs, two-character glyphs. But Arthur really worked hard to keep things to one character whenever he could.

Arthur’s philosophy was, if he didn’t need it, he didn’t include it. In fact, one of his favorite sayings was from Antoine de Saint-Exupéry, “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” That’s perfection, and that’s Arthur.

Final Reflections in Rob’s Own Words

Notation as a tool of thought was a seminal paper …[it] was a way of looking at the world where you could express things more concisely, more efficiently, more precisely and less ambiguously in an executable format, and you could then try something, modify it, revise it, and try it again, thereby writing good code. It is as simple as that.

¹Notation as a tool of thought: [https://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pdf](https://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pdf)

²APL Wiki: [https://aplwiki.com/wiki/Main_Page](https://aplwiki.com/wiki/Main_Page)

³IBM 360: [https://files.ibm360.info/Misc/1964%20SJ%20-%20A%20formal%20description%20of%20S360.pdf](https://files.ibm360.info/Misc/1964%20SJ%20-%20A%20formal%20description%20of%20S360.pdf)

⁴ IBM first APL interpreter: [https://aplwiki.com/wiki/APL%5C360](https://aplwiki.com/wiki/APL%5C360)

⁵ Arthur Whitney’s one page J interpreter fragment: [https://www.jsoftware.com/ioj/iojATW.htm](https://www.jsoftware.com/ioj/iojATW.htm)