In April we hosted DYNA26, our latest Dyalog North America user meeting. We returned to midtown Manhattan for a day of presentations, demonstrations, and the sort of impromptu conversations that only happen when APLers are in the same room.

Part of the Dyalog Ltd contingent (Brian Becker, Rich Park, Asher Harvey-Smith, and Holden Hoover) spent a few days beforehand in Rochester, New York, having a pre-DYNA “conclave” at Brian’s house, working through tooling design discussions and event preparation. We’re a geographically-distributed team, so we make the most of the opportunities to work together in person; our thanks to Brian for hosting once again.

The room filled with a familiar mix: enthusiasts, current developers building on Dyalog at customer sites, users of other APL implementations, and a few who hadn’t written any APL but were curious enough to spend a day with us. As ever, that mix is what makes DYNA enjoyable to host.

Presentations

The Dyalog Road Map
Morten Kromberg (remote)

Morten joined us remotely to open the day with the road map. The headline theme was LLMs. Stephen Taylor’s line that “Claude is the new Quad” captured it nicely, suggesting how the often-tedious system-interaction layer of programming, usually handled by I-beams and quad-functions and increasingly by libraries, can now be handled by LLMs as well, leaving APLers freer to focus on the core problem-solving to which the notation is so well-suited.

Morten covered recent experiments and experience: writing prototypes, tests and documentation; generating ⎕WC GUI code; and producing interactive tutorials for existing tools. There appear to be some productivity gains, particularly when an experienced developer is supervising. LLMs are already strong at non-APL tooling code (C#, HTML/CSS/JavaScript) that APLers regularly need to write around their core applications, and they’re steadily improving with APL code.

Of course, generative tooling is not the only thing on the road map. Morten talked about an increased focus on organisational and software security through the BSIMM initiative, including static analysis of both the interpreter’s C code and APL code. This can be used to, for example, find injection vulnerabilities through uses of ⍎ (execute), ⎕SHELL, or SQAPL. He also covered recent language additions, including APL array notation and ⎕VGET/⎕VSET, and looked ahead to future work including a potential ⎕IMPORT module system — a prerequisite for the robust project and package management that the community has been asking for.

An APL App End to End
Rich Park

Rich followed with a showcase of Dyalog’s tools wrapped around a single example application: a video data CRUD/REST service with search and recommendation. The demonstration included the upcoming Stark REST router and its OpenAPI specification generator, the extensions to ⎕DT coming in Dyalog v21.0, and the use of isolates to push heavy computation into a separate Dyalog process so that Jarvis/Stark can keep servicing HTTP requests in the main thread. He showed APL code to compute search results and recommendations using simplified expressions of term-frequency inverse-document-frequency and cosine-similarity, to convey how using Dyalog to deal with the fiddly interfaces and inconveniences of real applications lets us focus on using APL to express core algorithms. Plenty to consider for anyone building services in APL.

Migration Tools for APL Systems
Morten Kromberg (remote)

Morten returned for a second presentation, this one looking at tooling for migrating to Dyalog from other APL implementations. There are tools to swap language constructs for Dyalog cover functions that reproduce the original behaviour — and you wouldn’t necessarily expect it, but even ∧/ (and-reduction) and ∨/ (or-reduction) can need special handling to behave identically for certain arguments.

GUIs are often the trickiest part of any migration. Often, the pragmatic answer is to move to a conventional web stack, such as React, but sometimes a customer would rather retain the native Windows GUI behaviour intact through the migration. For that, there’s the ∆WI emulator for APL+Win’s ⎕WI that is being developed by Davin Church. In the past we’ve even seen an APL2 GDDM terminal interface migrated to an HTML/SVG-based emulator. Looking further ahead, the path from ∆WI to eWC could let migrated (or original Dyalog-native) GUIs run cross-platform inside HTMLRenderer or a browser without much further refactoring.

Parsing User Input for Database Normalisation
Mark Wolfson and Kori Smith, BIG

Mark is a familiar face at Dyalog events; this time he was joined by Kori Smith to talk about the work BIG does in inventory analysis and data aggregation for the jewellery industry — highly customised data processing for approximately 1,000 customers. The case study they explored was the perennial problem of inconsistent, hand-entered, product descriptions that need to be mapped onto a regular set of fields for database storage and later analysis.

BIG’s approach combines APL with regular expressions to iteratively refine the processing in a way that can be tuned on an individual customer basis. As Mark and Kori explained, the use case demands more consistency than an LLM can comfortably guarantee, and the mainstream NLP toolkit is overkill for what’s actually a fairly bounded problem albeit with some ambiguities (“emerald”, for example, is both a gemstone and a cut of diamond).

Dyalog OpenAPI Client Generator
Holden Hoover

Holden presented the Dyalog OpenAPI Client Generator, a tool that promises to make it considerably more straightforward to interoperate with the many existing services that publish OpenAPI specifications. Several attendees indicated that they had encountered precisely this issue already, and would benefit from not having to hand-write clients for sprawling third-party APIs.

One nice side effect of a machine- and human-readable specification is that it encourages thinking through API design before implementation. Holden demonstrated the generator against the Open-Meteo weather API, and against the OpenAI API — the latter to generate an introduction-to-APL page complete with examples and an image. He also mentioned the Stark REST Router layer that sits on top of Jarvis, making it easier to expose a Dyalog application to the wider world of HTTP clients.

APL Primitives in the 21st Century
Enhancements in Dyalog v20.0: Arrays, Namespaces, Composition, and Inline Tracing
Asher Harvey-Smith

After lunch, Asher gave us a double-bill of presentations about the past and current development of language features in Dyalog.

First, he took us on a whirlwind tour of how the APL primitives have evolved through Dyalog v13.0 to v18.0, with a particular focus on extensions and new primitives motivated by leading axis theory. This is the idea that functions applied along the first axis can be used to apply to sub-arrays, or between collections of sub-arrays of two argument arrays, in a consistent and malleable way compared to the ad-hoc nature of bracket axis. He started with short left arguments to take (↑) and drop (↓) in Dyalog v13.0, and progressed through to unique mask (≠) which marks unique major cells along the leading axis from the outset.

From there, Asher moved on to new features in Dyalog version 20.0. We saw APL array notation and its integration into the Dyalog session and editor, the ability to write namespace literals analogous to JSON, and inline tracing to step through an expression one function at a time. He explained behind (⍛) as a complement to compose (∘), with the filter idiom ⍛/ as his favourite example (for example, >∘0⍛/ to extract positive elements from a list). He concluded with ⎕VGET/⎕VSET for manipulating variable values without resorting to the potentially-dangerous execute (⍎), and ⎕SHELL for more complete and controllable command-line execution from APL.

Jarvis and AI
Brian Becker

Brian presented an experiment exploring how far a modern LLM could go in building a simple – but fully functional – Jarvis‑based web service. The target application was a Wordle™‑style game, and the model chosen was Google’s Gemini, selected for its easy, low‑cost browser access.

Brian began by crafting a prompt that described his requirements for the service. He then asked Gemini to refine the prompt and produce a project plan. Gemini responded with a surprisingly thorough plan, addressing several architectural details that Brian had not explicitly mentioned. When instructed to “do it all,” Gemini generated an HTML file containing the complete HTML/CSS/JavaScript front end, an .apln file defining the WordleServer namespace, and an .apls DyalogScript file to configure and launch the service. Then followed an iterative debugging loop (run the service, hit an error, paste the error into Gemini, apply the suggested fix, and repeat). Eventually Gemini produced a workable, if not elegant, solution. Brian proposed a cleaner approach, which Gemini incorporated. That single suggestion ended up being Brian’s only code contribution; all other APL, HTML, CSS, and JavaScript was generated entirely by Gemini. The final product was a clean, responsive game that Gemini named ARRAYDLE. Brian noted that the process might have been even smoother if Gemini had the ability to execute APL code directly.

This experiment reinforced two trends: LLMs are rapidly improving at generating APL code, and they already excel at producing polished HTML‑based front ends.

AVG — A Voxel Game
Kyle Croarkin

Kyle gave us a glimpse of his experience learning APL since he started in August 2025, and the substantial project he built to test his learning – AVG, A Voxel Game (essentially, a mini-Minecraft!). He’d wanted to develop something more meaningful than puzzles but nothing too daunting, so that he could really explore APL’s expressivity and the interpreter’s performance against the demands of a real-time game.

It was particularly nice to hear Kyle describe moments that more seasoned APLers will recognise. Kyle described arriving at a solution for finding invisible cube faces, only to realise it mirrored the structure of John Scholes’ Game of Life, giving him the revelatory experience of suggestivity. He talked about how quickly one can iterate on ideas when the notation is terse enough to keep everything on screen, and how APL puts the data right in your face. He was honest about the learning cliff, especially coming from a conventional CS background, and about the things that weren’t well-suited for APL in any obvious way (flood-filling algorithms for light and shadow being a notable example).

The APL Trust
Mark Wolfson

Mark closed the day with a talk about The APL Trust, a charitable organisation looking for applications for projects that either do work with/in APL or that benefit the APL community and ecosystem more broadly. As an example, a recent grant has supported the development of the APL387 font. Mark is also now an official Dyalog agent for North America, helping to support existing and prospective customers with their use of Dyalog.

Q&A and Conversation

The day was concluded with a Q&A session that gradually broadened into a more general discussion, touching on the ongoing challenges of promoting APL such as the glyphs, onboarding more generally, engaging with communities beyond the existing APL world, and the difficulty commercial users sometimes face in sharing their use cases without revealing industry secrets. None of these are new problems, but it’s always useful to discuss them together.

In Conclusion…

DYNA26 was a great day, well attended and warmly received. Conversations extended beyond the scheduled breaks and continued afterwards when we went for dinner and drinks.

The next user meeting will be Dyalog ’26 in Eastbourne, U.K., on 12-16 October. We hope to see many of you there.

---

Materials and recordings from DYNA26 will be added to the event webpage as they become available.