Welcome Nathan Rogers

Based in Denver, Colorado, Nathan Rogers is a new member of the Dyalog team. In previous lives, Nathan spent six years as a member of the United States Armed Services as a Satellite Communications Operator, studied music theory and performance at the University of Northern Colorado, and built desktop and web applications across numerous languages and frameworks in a variety of domains.

Nathan first came into contact with APL when discussing code obfuscation with other programmers, and a coworker mentioned K and APL. APL became an immediate obsession, and Nathan became a regular in the Stack Exchange chat room “The APL Orchard”. He quickly began spending all of his free time learning APL, building familiar applications and tools using this quirky language, and reading about its fascinating history. He finds it funny in hindsight that he was introduced to the language in a conversation about code obfuscation, only to now be an APL evangelist, believing the concepts of APL to be as fundamental to elevating the world of computer programming as the Arabic numerals were to the study of Mathematics. After a year or so, Nathan was put in touch with Morten Kromberg at Dyalog. The two began pair-programming projects, which quickly proved fruitful and led to Nathan joining the team soon after.

When Nathan isn’t working on consulting projects, or tools for Dyalog, you can typically find him behind his keyboard building his own tools and toy functions in APL, with two aims in mind: convert as many traditional programmers as possible to APL, and bring his knowledge and experience to bear on modernizing APL and its tools for the current and next generation of new programmers.

A Blustery Spring

Dyalog version 17.1 will be released soon, with the HTMLRenderer working under Windows, macOS and GNU/Linux, the “Link” system providing infrastructure for connecting APL to source code management systems, pre-built Docker containers with Dyalog APL for Linux installed and many other enhancements that simplify the installation and maintenance of systems based on Dyalog APL.

We’ll be writing much more about version 17.1 soon, and next year’s 18.0 release in due course. The main purpose of this blog entry is to let you know about new members of the Dyalog team and, unfortunately, a couple of departures as well.

Departures


In February, John Scholes passed away. Together with Geoff Streeter, John was one of the original implementors of Dyalog APL in 1982-1983, a cornerstone of all aspects of the Dyalog language and business, and one of the pillars of the APL community. Many members of the community have paid tribute to our Genius, Gentleman and Mischievous Schoolboy at http://johnscholes.rip.

At the end of May 2019, Jay Foad is leaving Dyalog to return to his first love (as a software developer) and become a proper compiler geek again, after nearly a decade of helping move Dyalog APL forward and, for the last three years, helping to “herd the cats” as CTO. We will sorely miss Jay’s technical excellence but understand the desire to hit the sweet skill spot when the opportunity arises, and we wish him good fortune in that pursuit! You can read Jay’s farewell blog post here.

Jay’s management responsibilities will be shared between Richard Smith, our Development Manager and myself; I will be re-assuming the role of CTO until further notice.

New Faces in 2019

The good news is that we will welcome several new people to Dyalog in 2019 – new hands to write code in APL, to work on the APL interpreter, and to write documentation and training materials to help new and old users get their work done more effectively.

APL Consultants

In response to client requests and to help new clients get started writing their first APL systems, we are creating a consulting group in the USA. To date, we have recruited two members for this team: Nathan Rogers joined the team at the end of April and is based in Denver, Colorado, and Josh David starts work for Dyalog in early June (as soon as he graduates) and will be based in New Jersey. If you think you have heard of Josh before, that is probably because he was a winner of the Dyalog Problem-Solving Contest in 2016 (https://www.dyalog.com/news/112/420/2016-APL-Programming-Contest-Winners.htm) – and a runner up in 2015. Nathan found us thanks to Adam Brudzewsky’s work on Stack Exchange: https://chat.stackexchange.com/rooms/52405/the-apl-orchard. You can reach them both using e-addresses in the form firstname at dyalog.com.

When members of the consulting team are not working for clients, the intention is that they will be members of the APL Tools Group at Dyalog, working on new tools for APL application development and helping create test suites for Dyalog APL. They will also support Richard Park, who joined us late in 2018, to work on the creation of training materials and tutorials for new users.

Once we have a better idea of the demand for consulting in North America, we expect to grow the team. Please let us know if you could use hired APL hands – in any territory! If we don’t have the resources ourselves, we may be able to find someone else.

Programming Language Implementors

Nathan comes to us with experience from a broad set of tools and programming languages. In addition to writing tools in APL, he will be a part-time member of the core development team, working on the APL interpreter and its interfaces in C, C#, JavaScript, Python and other languages. However, he won’t spend enough time on this to make up for the loss of Jay, who (like most managers at Dyalog) spent a significant amount of his time writing code.

Therefore, as described at https://www.dyalog.com/careers.htm, we are recruiting at least one C / C++ programmer to help us grow the core team.

A Busy – and Exciting Time

2019 is looking like an extremely busy year, with significant growth at Dyalog. As usual, our plan is to bring all the new (and old) hands to the Dyalog user meeting, which will be held in Elsinore, Denmark this year – September 8th to 12th. Details of the programme will soon start to appear at https://www.dyalog.com/user-meetings/dyalog19.htm. If you would like to present an APL-related experience to the user community, make proposals for new features of Dyalog products or suggest topics that you would like Dyalog to speak about at the user meeting, then please let us know as soon as possible!

Goodbye

At the end of May 2019 I am leaving Dyalog, so it seems like a good time to reflect on my time here and what I’ve learned from APL and the APL community.

When I joined Dyalog in 2010 I knew nothing about APL, so there was a really steep learning curve as I got to grips with both the language and its implementation. I was using some of my previous experience with compilers to improve the performance of the implementation, and thinking about ways to compile APL. This is a tough problem, and one that many people have worked on over the years (see for example Timothy Budd’s 1988 book An APL Compiler). My own ideas have shifted as I’ve gained more experience with APL and the way it is used. At first I thought “writing a compiler” was an obvious thing to do; now I think that hybrid compiler/interpreter techniques are much more promising, and Dyalog’s recent experiments with deferred execution and thunks are a good step in that direction.

At the same time, there was a lot of excitement around the APL language itself. Dyalog was working on APL#, a new .NET-based APL dialect (sadly abandoned as Microsoft’s own commitment to .NET waned). And Dyalog APL itself was starting to borrow more language features from the SharpAPL/J branch of the family tree, starting with the Rank operator and continuing over many years. This prompted me to delve more into the history of APL, to try to understand some of the fundamental differences between different implementations, so that we could reconcile those differences in Dyalog APL and provide, as far as possible, the best of both worlds. I think we’ve done pretty well in that, as evidenced by the fact that many APLers are happily using Rank, Key, function trains et al in an APL2-based language, something that seemed unthinkable a decade ago.

One of the most gratifying developments in the time I’ve been working with APL is the rapid growth of new APL implementations, open source projects and grass-roots enthusiasm. In particular, the open source movement has made it much easier for anyone with a good idea about language design to implement it, and share it with the world. We’ve seen a wide variety of new APLs and APL-inspired languages popping up over the years, ranging from full-featured to highly experimental, including but not limited to (in roughly the order I remember hearing about them): ELI, ngn/apl, GNU APL, Ivy, Aprildzaima/APL and APL\iv.

And speaking of new APLs, of course there is Co-dfns, a compiled APL implementation that tries to solve another tough problem: harnessing the power of GPUs and other massively parallel hardware in a way that makes it accessible to the end user. This is something that many people are trying to do, in a wide variety of languages, but as far as I can tell no-one has quite succeeded yet. The state of the art is still that, in order to get good performance, you need quite a lot of mechanical sympathy for the underlying hardware. But Co-dfns has come a long way, and if any language is well-suited to run on parallel array processors then surely it is APL!

This brings me on neatly to my next job: I’ll be working on compilers for GPUs, the parallel computers that render 3D graphics. They are closely related to their “general purpose” cousins the GPGPUs, which are used for pure number crunching, and to so-called tensor processing units (TPUs) that simulate neural networks for use in machine learning and artificial intelligence. “Tensor” here just means an array of arbitrary rank, or as we would say: an array. For programming TPUs there is a Python-based framework called TensorFlow. But, look closely at the APIs for some of the core TensorFlow libraries, and you’ll see operations like reshape, reverse and transpose, which are eerily similar to their APL equivalents. There truly is nothing new under the sun!

With fond regards to all APLers,
Jay.

Welcome Richard Park

Richard Park is the latest addition to the Dyalog team and is based at Dyalog HQ in the UK. Richard has been living in the same house in Bramley his entire life and recently returned to the village after one successful degree in physics at the University of Manchester, and one unsuccessful degree in education at Manchester Metropolitan University.

How Richard and Dyalog came to meet is a story that deserves to be told, albeit a bit embarrassing for poor Richard!

One day, while walking his dog and father, Richard rang the office doorbell to inquire about any software-related opportunities that might be available. He had developed an interest in computers from using them at young age, building circuits for A-level electronics and learning about the physics of computers (as well as computational physics) at University. If only Richard had been able to convey any of that to Jay Foad, who answered the door, instead of standing like a “gormless idiot” (his words) whilst his father jumped in and asked about internships and job opportunities…

Richard went home that evening and browsed the Dyalog website… the Pandora’s box of APL edged ajar and he began to imbibe the symbols. He also sent an amusing email explaining the earlier awkward encounter and clearly showing that he was not a “gormless idiot”. This resulted in a meeting with the CEO and CXO, Gitte and Morten, in October 2018. After that meeting Richard showed enough aptitude and interest, while pair-programming a simplistic physics simulation with Morten, that they decided to keep him.

Given that Richard’s previous experience includes programming an autonomous robot for the QMC team in the 2012 and 2013 Student Robotics competitions and using MATLAB and CERN’s ROOT library to process experimental data and run simulations, he was very surprised that he had never heard of APL before. He sees a potential in APL to develop domain specific programming languages and software packages to help teachers convey concepts in a way which more closely matches the syntax and jargon in which problems are already described.

In his new role at Dyalog, Richard is developing teaching materials and demos to promote APL.

Dan Baronet

Dan Baronet

Dan Baronet

We do not know the details, but Dan’s luck ran out this week. On Tuesday, as he headed South from Nevada into California, en route to Mexico on the first leg of a four month motor cycle adventure to South America, something went wrong … Dan lost control of the bike and collided with a motor home, and many of us are now struggling to comprehend that Dan won’t be back.

Dan made friends everywhere that he went. On our annual Dyalog skiing “retreat” (we frequently did real work on prototypes of new tools, honest!), I was always impressed (while trying to hide my slight embarrassment) by the way Dan always kicked off conversations with hotel staff. Whether the waiters and waitresses were native Italians from the resort town – or migrants as hotel staff frequently are – Dan would typically know enough words in some shared language to get the conversation off to a good start (or he would extend his vocabulary on the spot). This always guaranteed us service with a smile, and excellent advice on which wine to order for dinner.

Dan gave as well as he got: on the slopes, Dan was always the first to stop by anyone who had fallen over and was struggling to get back up. Dan has friends all over the world and always took the time to visit them when he could, to keep the friendships alive. He was also happy to open his own home to travellers, both my kids had little Canadian adventures as guests of Dan and his family in Quebec, and Dyalog team members would also “couch-surf” chez Dan.

At work, Dan also loved extending his vocabulary. He remembered more details of different APL dialects than anyone else that I know, and was an expert in migrating code from one system to another. He also knew the weaknesses of each system, and was a feared visitor to vendor booths at APL conferences. Dan would mischievously sit down to play with a new APL system, try a couple of his favourite edge cases, and usually manage to crash new (and some old) APL interpreters within seconds.

But even when crashing interpreters, Dan was really trying to help the vendor produce a more stable platform. At work, as on the ski slopes, Dan was one of the few people who was always going out of his way to help. When he had spent time learning a new technique, or how to use a new tool, he would go the extra mile to create a utility library, document it, presented it at conferences and APL user meetings. He also did the really hard part – writing an article about it, making frequent contributions to Vector and other publications: http://archive.vector.org.uk/?qry=baronet&submit=search. He also enjoyed teaching APL, as an instructor at I.P.Sharp Associates and in the modern era as the author of numerous tutorials at https://www.youtube.com/user/APLtrainer.

More than 30 years ago, as an APL rookie at I.P.Sharp Associates, I was fortunate to meet, work with, and learn from Dan when he and I both found ourselves at IPSA Copenhagen. In addition to a general interest in tools, I shared Dan’s interest in the migration of code between APL systems, and flying airplanes. Dan actually flew small aircraft (and helicopters!) and I, like so many other friends and colleagues, admired him and got invited along for rides.

A decade and a half later in 2005, as the new CTO of Dyalog, I was keen to add an APL toolsmith to the company. Despite his location in Montreal, Dan was at the top of my list. Dan continued to live in Montreal but was a frequent guest in Bramley, coming over several times a year to spend some weeks to work with the growing “APL Tools Team” – and with the core development team on improving the quality of the interpreter by crashing it in as many ways as he could think of.

When his imagination ran out, he wrote code to generate even more ways to crash the interpreter. Dan has been cursed loudly many times, and will be remembered – if for no other reason than that it will be a long time before we are able to close the last “issues” that he logged in our problem tracking system. The quality of Dyalog APL has increased enormously in the last decade, and we have much to thank Dan for. Dan also “poured the concrete” for the foundations of the source code management tool (SALT) and the User Command framework that we are all starting to take for granted, and contributed to many other pieces of our growing collection of tools.

C-GSXN in Toronto

Dan often flew himself to APL User Meetings

Dan was an adventurer. He skied, snowboarded, snowshoe’d, biked, skated, hiked and flew – and with his great sense of humour and warm personality, he was able to entice many of us to come along with him to share. He photographed and brought his video camera, although he would often manage a 3-week trip to Europe which included a skiing trip, carrying only a small backpack.

Dan had just turned 60, and he had taken four months leave this winter to pursue an old dream to revisit South America with a friend – on motor cycles. They had wisely gone on a trial ride in the late summer, riding from Canada to Las Vegas and parking the bikes there in order to test the equipment and not have to ride two-wheelers in the Canadian winter. As a pilot, Dan understood risks very well – or rather, how not to take unnecessary ones.

“If only he had been a little more cautious”, some will say. Was that trip really necessary? These thoughts are unavoidable – but we have to remember that his decision to ride was natural to the adventurous and mischievous spirit that we all knew and loved.