Category Archives: CTO

Posts from Dyalog Ltd’s CTO

Welcome to the Dyalog ’19 Videos!

Posted on by

It is still true that most APL users live north of the equator, which means that at this time of year the sun is below the horizon more than half the time. It’s the perfect time to snuggle up in a warm place and watch some videos, and we’ll be offering you about three a week from now until just after the Winter Solstice, when we can start looking forward to the Spring.

As usual, we’ll be releasing videos of the vast majority of the presentations that were made at the recent Dyalog ’19 user meeting, which was held in Elsinore, Denmark in September. If you would like to get a feeling for what is coming, take a look at the blogs from the meeting itself, starting with this one.

In accordance with tradition, we’re opening with the three keynote presentations by Dyalog’s CEO Gitte Christensen, CTO Morten Kromberg, and Chief Architect John Daintree.

Gitte welcomes delegates to Dyalog '19

2019 is the first “Year of the Hammer”: after seven years of Norse wyrms and seven years of Viking ships, we were now entering the era of seven hammer-inspired logos. As Gitte explains in her talk, we are celebrating the first year under Thor’s Hammer by making Dyalog APL freely available for non-commercial use – without requiring registration – under Microsoft Windows, Apple macOS and GNU/Linux (including a collection of public Docker images). The intention is to make APL much more easily accessible for experiments – especially in the cloud!

Gitte’s talk also contains sombre tones, remembering that we lost John Scholes in February as well as Harriett Neville, who had registered to attend Dyalog ’19 but passed away most unexpectedly just before the meeting.

After last year’s Technical Road Map, which was almost entirely a live demonstration of using APL with modern development tools like Git, VS Code and Docker, I decided to play it safe this year and do no demos at all in my keynote. Instead, I concentrated on explaining some of our thoughts about making Dyalog APL easier to discover, learn and integrate into modern frameworks and development processes – and making applications written in APL easier to deploy and maintain. As a result, despite the world premiere of our new Webinar Jingle, composed by Stefano Lanzavecchia (short and long versions are available), I probably shocked the audience by leaving three minutes at the end for questions!

 

The title of John’s talk was “Cor(e) Blimey!”. The Cor(e) is of course a reference to Microsoft’s “.NET Core” but if English is not your first language, the title of John’s talk may need a little explanation. “Cor blimey” is an exclamation of surprise, a euphemism derived from “God Blind Me”. In this talk, John explains how Dyalog is poised to provide a bridge to Microsoft’s new portable, open source version of .NET. Scheduled for release with Dyalog version 18.0 next year, this will provide APL users with access to a vast collection of libraries under Linux and macOS, in addition to Windows.

Summary of this week’s videos:

I hope you enjoy these presentations. Join us again next week for another three recordings from Dyalog ’19!

Email, RSS Follow

A Blustery Spring

Posted on by

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!

Email, RSS Follow

Goodbye

Posted on by

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, April, dzaima/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.

Email, RSS Follow

A message from the CTO

Posted on by

Hello! Further to Morten’s kind words of introduction, I’d like to take this opportunity to introduce myself as the new CTO of Dyalog Ltd.

About me

I’m a newcomer to APL. When I started working for Dyalog in 2010 I had only seen the Game of Life video, an intriguing but baffling glimpse into a world of squiggles. But I soon got the opportunity to learn from some giants of the language, and came to appreciate the power and beauty of the notation. Later I learned that, despite its venerable history, the language is not set in stone; with care and attention we can develop and extend it to increase its power, relevance and performance, without sacrificing its elegance and simplicity.

We — not just Dyalog, but the wider APL community — are guardians of a rare thing: a language born more than 50 years ago that is not just relevant and useful today, but groundbreaking in the way it embodies data parallelism from the ground up in a simple, consistent notation.

Before working at Dyalog I spent 13 years developing compilers, optimisers and debuggers for more mainstream programming languages, including C and Java. This has given me a good insight into how to get the best performance out of modern computer hardware, and I’ve made it my continuing mission to help bring that level of performance to APL!

My rôle

As CTO I’ll be responsible for day-to-day management of the core interpreter development team, and for the overall technical strategy of the company. This strategy must include getting the maximum performance out of current and future hardware, but also:

  • Keeping the quality of the product as high as possible.
  • Embracing new platforms and attracting new users.
  • Improving our development tools, and making it easier to create and deploy new applications.
  • Ensuring that Dyalog APL can interoperate smoothly with modern frameworks and services.
  • Continuing to look at new ways of (carefully!) extending and improving the core APL language.

I’m looking forward to working on this alongside the “new” CXO, Morten. At Dyalog we take a lot of care in the design of new features, and I firmly believe that a lively discussion between CXO (representing the needs of the customer) and CTO (representing the language designers and implementers) will only improve the quality of the designs we come up with.

On the road

In the future I expect to spend a bit more time out and about, showing off Dyalog APL, and talking to all of you about your own needs and expectations of the product. In particular, this year I’ll be at DYNA16 in Princeton in April, and the Dyalog ’16 User Meeting in Glasgow in October. I look forward to seeing, or meeting, all of you soon!

Email, RSS Follow
Posted in CTO

SWEDAPL Meeting in Malmö, November 11th 2015

Posted on by

The November cycle of APL User Meetings is kicking off; the SWEDAPL meeting in Malmö was first this year, holding a meeting at the top of the famous Turning Torso in Malmö. Since it was just a short trip from our Danish office, Dyalog was represented by Gitte Christensen, Bjørn Christensen and Morten Kromberg – with Brian Becker and Dan Baronet joining the meeting remotely. Next week, Richard Smith and Nick Nickolov will be representing Dyalog at APL Germany in Erfurt and Dan Baronet at FinnAPL in Helsinki – check http://dyalog.com/dates-for-your-diary.htm periodically for a list of APL meetings and Dyalog presentations!

Gilgamesh Athoraya welcomes us to SWEDAPL

Gilgamesh Athoraya welcomes us to SWEDAPL

This turned out to be a very international group – ten Swedes (two of whom were from India but based in Göteborg), six Danes who made the trip across the sound, two from the UK, one German and one delegate from each of Serbia and the Ukraine – plus about five North Americans who joined the afternoon sessions via GoToMeeting. This was the first “themed” SWEDAPL meeting; all of the talks were related to the use of Web Services in APL.

First up was our host Gilgamesh Athoraya from Data Analytics in Malmö, who showed us how he had been using Paul Mansour’s new RUMBA application interface which is built on top of Dyalog’s TCP toolkit (which is known as CONGA). Gil has been experimenting with support for Web Sockets, which are bi-directional connections that allow the server to push data to web client applications, making it possible to have very responsive user interfaces in web applications.

Joakim Hårsman explaining how slippery SOAP can be

Joakim Hårsman explaining how slippery SOAP can be


The next presentation was by Joakim Hårsman of CompuGroup Medical, who have been exposing data held on IBM AIX servers via Microsoft.NET-based Web Services for many years. Joakim had a few interesting stories to tell about getting a grip on and maintaining Web Services based on the protocol known as SOAP, which is supposed to make this easy…

The last talk before lunch was by Stephan Poßberg of Vallourec, who talked about the use of Web Services to make computational code available across a large, global organisation. Lunch was served on the 54th floor; unfortunately the weather didn’t quite allow us to see all the way to Helsingør.

The Turning Torso in the Mist, After Dark

The Turning Torso in the Mist, After Dark

After lunch, it was Morten’s turn, assisted by Brian Becker (who joined the meeting from Rochester NY) to present Dyalog’s brand new support for RESTFul web services, available in MiServer 3.0. Paul Mansour also joined this session and provided valuable insights into REST technology, which seems to be taking over as the preferred Web Service architecture for new applications.

Finally, Peter Simonsson from Aplensia in Göteborg told us how Web Services had become widespread at Volvo Cars, where a couple of hundred APL-based services provide the backbone of a network of applications centered around product data and production planning – with the earliest web services dating back to the days when APL ran under VM on IBM Mainframes.

Many thanks to Gilgamesh, Data Analytics and Optima Systems for arranging this event, which provided much food for thought, and inspiration for future work by several people at Dyalog – and by the sound of it, a number of users of APL as well! Expect to see more support for Web Services and Sockets in future versions of Dyalog products!

Email, RSS Follow

Over the Moon with Selenium

Posted on by

Over the years, I have become more and more reluctant to write code without good regression tests – 35 years of software development have taught me that it is just too dangerous! Regression testing of user interfaces has always been difficult, but for the last few weeks I have been working with technologies that put user interface testing within easy reach: HTML and the Selenium WebDriver, which star in the following video (if you can wait, read the full story below the video before watching):

This is exciting – I hope you can see why I am “over the moon” (apart from Selene being the Greek Moon Goddess).

Modern Markup Languages

One of the good things about modern User Interfaces based on markup languages like HTML is that logical information about the user interface is available at runtime. For example, a browser displaying HTML maintains a “Document Object Model” of the web page. The content and other attributes of each element within the DOM can be inspected and manipulated at runtime by a testing tool – this is what Selenium does.

Selenium

Selenium is a widely used open-source tool for automating browsers, with growing support from browser vendors. Selenium provides an API that allows you to perform just about any operation that a user could: click on buttons and select items from drop-downs, press keys to enter text, drag and drop items, or perform exact mouse movements and different types of clicks. Over the last few weeks, we have been working on a some thin covers for Selenium to make it easy to drive browsers from Dyalog APL. At the moment we require the Microsoft .NET bindings and can only do the testing from Microsoft Windows. The web server can be running anywhere, and we hope to add other client platforms in the future.

The results of this work are now available in the GitHub Repository Dyalog/Selenium. The following example, included in that repository, shows a simple test which verifies that the TryAPL website is able to execute a simple expression:

 ∇ r←Basic;S;result
 ⍝ Basic test that TryAPL is working - return error message if it isn't
 
 S←##.Selenium
 S.InitBrowser''
 S.GoTo'http://tryapl.org'
 
 'APLedit'S.SendKeys'1 2 3+4 5 6'
 S.('APLedit'SendKeys Keys.Return)
 result←'ClassName'S.Find'result'
 r←result S.WaitFor'5 7 9' '1 2 3+4 5 6 failed'
 ∇

MiServer Regression Testing

The primary motivation for this work has been to create regression test scripts for MiServer version 3.0. The MiServer regression testing mechanism is extremely simple (possibly a bit TOO simple, we’ll cross that bridge later): If a site contains a folder called “QA”, and the folders within mirror the structure of the web site, then a mechanism exists to load each page in turn and run the corresponding test function. You can read more about it on GitHub and see it working in the video at the top of this post.

Email, RSS Follow