Speaker
Description
Julia's technical qualifications as a data analysis language for HEP are obvious: it combines the interactivity of dynamic scripting with the speed of statically typed compilation. It's well-posed to replace Python and C++ in HEP, at least from the stage of analysis objects (e.g. NanoAOD in CMS and PHYSLITE in ATLAS) to final publication.
However, developers don't select a language purely on technical merits. Using the same language as one's peers has several advantages: sharing code, being able to talk about code in the same ways, and having access to the same libraries and tools. Also, programming language communities develop personalities—shared priorities about performance, readability, future-proofing, tooling, etc. Choosing a language based on popularity is a self-reinforcing proposition, though. It biases against new languages, even when they have qualitatively new and technologically better features.
Changing the HEP analysis community from its current mixture of Python and C++ to Julia will be like moving from one local minimum to another, more optimal, minimum. There is a barrier to cross and we will need to find the best pathway over it, as well as short-term, local motivations—not just the technical merits of a 100% Julia future—to convince members of the community that each step is worth the effort.
In this talk, I'll discuss the general challenge in terms of what I consider to be a specific and partial solution—sharing columnar data between Python and Julia using AwkwardArray.jl. I'll present some of the differences between the Python perspective and the Julia perspective on technical issues like type-granularity, indexing, object orientation/syntax/naming, and packaging, but also community values, such as those expressed in the Zen of Python (now 20 years old) and the Greed of Julia (12 years old), how those values have changed over time, and what may need to change for widespread adoption in HEP.
