CERN STEAM Academy puts the future of scientific software centre stage

by Panos Charitos (CERN), Alex Lasa Lamarca (CERN)

In a packed CERN STEAM Academy seminar, “21st Century C++“, Bjarne Stroustrup, C++ creator, explored how safer, simpler and more efficient programming practices can help prepare scientific software for the computing challenges ahead.

Photograph: Lasa Lamarca, Alex

The CERN Main Auditorium was filled to capacity on Tuesday, 14 July, as Professor Bjarne Stroustrup, the designer and original implementer of C++, delivered the EP/IT Data Science Seminar “21st Century C++” (you can watch the recording HERE). 

The subject resonates particularly at CERN. C++ forms part of the Laboratory’s largely invisible software infrastructure, supporting systems that range from detector control and real-time data processing to simulation, reconstruction and physics analysis. Stroustrup described himself as happy to have made his “tiny little contribution” to CERN’s scientific work—an assessment that Andrea Bocci, applied physicist at CERN and member of CMS  who interviewed Stroustrup, immediately challenged: “I think you’ve done more than a little bit to help.” Stroustrup’s visit therefore provided more than an opportunity to revisit the history of an influential programming language. It brought the creator of a tool deeply embedded in CERN’s scientific work into conversation with the younger researchers and engineers who will help shape its future use.

Interest in the seminar quickly exceeded the auditorium’s capacity, prompting the opening of the Council Chamber as an additional viewing space. Participation was equally strong online, with 173 people connecting via Zoom and another 254 following the webcast. Altogether, the seminar reached an estimated audience of around 900 people.

The event formed part of the CERN STEAM Academy Seminar Series, organised within the framework of CERN’sNext Generation Triggers (NGT) project. By bringing one of the most influential figures in computing history into direct conversation with CERN’s scientific and technical community, the seminar illustrated the Academy’s broader purpose: connecting advanced training with the technologies and ideas shaping the future of scientific research. The exceptional turnout also marked an important moment for the first edition of the CERN STEAM Academy. Developed within the Next Generation Triggers project, the ten-week advanced training programme is designed to strengthen expertise in the technologies needed for future data-intensive scientific computing.

“The remarkable response to this seminar demonstrates the importance that the CERN community attaches to software and computing,” said Felice Pantaleo of CERN’s Experimental Physics (EP) department, and Director of the CERN STEAM Academy. “Software is an essential part of our scientific infrastructure, even if much of it remains invisible. Creating opportunities to learn directly from figures such as Bjarne Stroustrup helps us reflect not only on the tools we use, but also on how we use them.”

Bjarne Stroustrup addresses a packed CERN auditorium during his July 2026 lecture, sharing his reflections on programming, software design and the direct representation of ideas in code. Lasa Lamarca, Alex © CERN

The software behind the science

For CERN, C++ is far from an abstract subject. It supports systems ranging from detector control and real-time data processing to simulation, reconstruction and physics analysis. “C++ is just about everywhere, but it’s usually invisible,” Stroustrup observed during the seminar. “Good software is often invisible.”

That invisibility is familiar in experimental physics. Detectors and accelerators are the visible instruments, but their operation and scientific output depend on a large, intricate software ecosystem. When it works, the software rarely attracts attention. When it fails, the consequences can range from lost computing time to the reproducibility of scientific results.

Stroustrup traced C++’s origins to a practical problem. While developing a distributed Unix system, he found that the languages available to him did not combine the low-level access he needed with a sufficiently expressive way of organising a complex program. “A good design starts with a problem,” he said.

The language that emerged could run efficiently close to the hardware while letting programmers represent higher-level ideas directly in code. At CERN, where software is developed by international collaborations and maintained over decades, that remains a practical requirement: code must be intelligible long after its original authors have moved on.

“You want to have your ideas directly represented in code,” Stroustrup explained. “That way, the next person who maintains the code has a chance to see what it’s supposed to be.”

He also challenged the assumption that high performance demands complicated code. Recalling his work reorganising a large, unreliable system, he summarised his approach in three words: “Simplify, simplify, simplify.” According to Stroustrup, the redesigned system was not only more reliable but approximately 100 times faster. Simpler interfaces and clearer type structures made the program easier to maintain and gave the compiler more opportunities to optimise it.

Audience questions brought the discussion to Python, machine learning and generative AI. Stroustrup cautioned against assuming that accessible, high-level tools remove the need for precise systems programming. Many rely on C++ underneath for performance, hardware access and reliability. “C++ is at the bottom of all AI,” he remarked. The point was not to set C++ against Python or AI, but to show how the different layers of contemporary computing rely on one another.

The following morning, Stroustrup sat down with CERN’s Andrea Bocci to explore several of these questions in greater depth: how C++ can evolve without abandoning its vast existing software base, how it can offer stronger guarantees without becoming a “straitjacket”, and whether it remains a sensible choice for the scientific systems being designed today.

WATCH: In the full interview below, Bjarne Stroustrup speaks with CERN’s Andrea Bocci about the evolution of C++, software safety and the challenges of developing tools for long-lived scientific systems.

A language meant to evolve

“It’s great to be back at CERN,” Stroustrup said. He was particularly pleased not only by the size of the audience, but also by its composition. “I was very pleased to see how many people turned up, how many young people turned up and what good questions they asked afterwards.”

His purpose was to move the discussion beyond programming practices inherited from the language’s early decades. “I was trying to explain how C++ was evolving – and was meant to evolve – and how to write modern C++ without being stuck in the previous millennium.”

Evolution was part of the design from the beginning. Stroustrup never expected to produce a finished language that could anticipate every future application. “When I started, I knew very well that I couldn’t build the language I wanted,” he said. “Furthermore, I knew I wouldn’t know enough about the future to build the ideal language for the future.”

His approach was iterative: identify a real problem, develop the best available solution, examine what works and what does not, and improve it. C++ began by combining low-level capabilities derived from C with higher-level ideas influenced by Simula. Over time, stronger type checking, systematic resource management, and generic programming emerged, helping programmers express more complex ideas without giving up control over performance.

Evolution, however, has limits. CERN maintains many millions of lines of C++, while the global software base runs into the billions. Radically changing the language would risk breaking software that embodies decades of scientific and technical investment.

“My assumption is that I can’t change the language in any meaningful way,” Stroustrup explained, “but I can help change the way people use the language in meaningful and effective ways, so that they can write simpler code that expresses things more clearly and runs faster.”

The Unix Room circa 2000. Unix provided an important technological context for the development of C++, which Bjarne Stroustrup began while working on distributed systems. Photo: Rob Pike / TUHS.

Safety beyond memory

Safety has become a defining issue as newer languages emphasise memory safety. Stroustrup does not dismiss the concern; he broadens it. Memory is only one resource. Software also acquires locks, opens files, creates threads and establishes connections. A program that fails to release any of them may eventually bring down a system.

This is particularly serious in many environments where C++ is used. Software controlling a vehicle, processing financial transactions or operating scientific infrastructure cannot always be stopped while someone is sent to repair it. Resources must be managed predictably, including when errors occur.

He also reminded us that safety doesn’t mean the same thing in every setting. A smart watch faces different constraints from a financial system, a vehicle control system, or a large research facility. In some applications, timing is itself part of correctness. “If I press my brake, it has to respond in time,” Stroustrup said. “It’s not enough to be correct. You have to be correct in time.”

His current work on C++ profiles seeks to provide stronger guarantees by enforcing selected sets of programming rules. During his CERN visit, Stroustrup was preparing to circulate a proposal for an initialisation profile (it has been published HERE), intended to prevent variables or objects from being used before they have been properly initialised. Much of the approach had already been implemented, although the proposal remained open to feedback.

The crucial test is whether such safeguards feel natural enough to become part of everyday programming rather than obstacles that developers continually work around.

“It’s not enough to be able to be safe,” he said. “You have to be safe while writing code in a way you like to write it. You don’t want safety to be a straitjacket that gets in your way. You want it to be the natural way of expressing things.”

Some important sources of safety problems in C++ are gradually being addressed, Stroustrup argued. Several areas still lack enforceable guarantees that developers can rely on without first becoming experts in every potentially dangerous facility in the language. Some elements are already being implemented; others may take several more years.

“The technological challenges of the High-Luminosity LHC era cannot be met through new hardware or algorithms alone,” Pantaleo said. “They require sustained investment in people and in the skills needed to connect advanced software, edge computing and machine learning with real scientific problems. The STEAM Academy was created to provide precisely this integrated learning environment.”

From experimentation to deployment

For CERN developers, the publication of a new C++ standard is only the beginning of its journey into production software. Experiments maintain large, long-lived code bases, supported by complex build systems and expected to run reliably across different hardware platforms. A feature may therefore be formally standardised long before every compiler implements it consistently—or before the surrounding tools are sufficiently mature for operational use.

At the time of the interview, CERN teams were still completing their transition to C++23 while already experimenting with features proposed for C++26. Stroustrup saw no contradiction in this. Experimentation lets developers understand what a new facility can offer and identify weaknesses in its implementation; deploying it in critical software calls for a different level of confidence.

“For production, I always recommend being a little bit cautious,” he said. Compilers may not yet be fully tuned, build systems may need to catch up, and early implementations can differ in their completeness or performance. C++26 was still going through the formal approval process, so complaining that all its features weren’t yet readily available was somewhat premature.

For production work, Stroustrup suggested that C++20 already provides a strong foundation. Its major additions include modules, designed to offer a cleaner alternative to traditional header inclusion and to improve the organisation and compilation of large software systems. Concepts, meanwhile, let developers express requirements on generic code more explicitly. This can produce clearer interfaces, more useful compiler diagnostics and safer generic programming.

C++26 is expected to take another significant step with static reflection. Reflection allows a program to examine aspects of its own structure—such as the members and properties of a type—at compile time. Developers can then use that information to generate repetitive code or construct specialised libraries without manually reproducing the same information in several places.

This is of practical interest at CERN. Developers have already been experimenting with reflection as a possible replacement for code that currently relies on extensive use of preprocessor macros—what interviewer Andrea Bocci candidly described as “macro hell”. By moving such work into the language itself, reflection could make sophisticated libraries considerably simpler to write, inspect and maintain.

Stroustrup acknowledged that early implementations of reflection were not yet as fast as developers would ultimately want. Compilation speed, however, may be less critical when the cost is incurred mainly while constructing a library. Once that library has been built, many other developers can use it without repeatedly paying the full development cost. Compiler performance should also improve as implementations mature.

The exchange highlighted the difference between evaluating a promising new capability and depending on it in deployed scientific software. CERN’s early experiments can help determine whether features such as reflection meet real high-performance-computing needs, while production systems can continue to rely on better-established parts of the language.

Some of Stroustrup’s current work, including the initialisation profile and other proposals for enforceable safety guarantees, lies on a longer horizon and may become relevant to standards beyond C++26. This staged process—experimenting, gathering feedback, improving implementations, and only then deploying—reflects how C++ itself has evolved. New features must prove not only that they are innovative, but also that they can become reliable parts of software expected to remain in use for many years.

An open standard – and CERN’s place in it

Unlike languages controlled by a single company, C++ is governed through an international standard. Stroustrup sees that arrangement as both a strength and a source of difficulty.

He recalled being approached by representatives of major technology companies who wanted his help standardising C++ under ISO rules. His initial reaction was that it was too early: he was still researching the language, correcting it and trying to understand how it should evolve. After what he jokingly described as about an hour of arm-twisting, he agreed – before asking what the ISO rules actually were.

Standardisation helped secure the language’s independence and portability. Because no single corporation owns C++, competing organisations can adopt it without handing control of their software platform to a rival. Companies have repeatedly promoted languages tied to their own platforms, but programs that must operate across different systems often return to C++. “You end up with C++ – again and again,” Stroustrup said.

The price is a difficult decision-making process involving hundreds of participants with different priorities. A proposal that appears ideal for one organisation or field may cause problems elsewhere. Once a feature enters an international standard and is widely adopted, it may need support for decades. “The first solution is not always the best,” Stroustrup said. “As a matter of fact, it rarely is the best, in my experience.”

The history of concepts offers an example. An initial design was extensively discussed but ultimately abandoned in favour of the substantially revised approach now available in modern C++. The process took time, but this was preferable to standardising a weak solution that could not later be removed without breaking existing code.

Asked whether scientists contribute sufficiently to this process, Stroustrup’s answer was characteristically direct: “A bit – and, in my opinion, not enough.” Scientific influence is not always obvious from committee membership: some contributors work for research organisations, while others are based in universities or companies but develop high-performance tools with and for scientists.

CERN participates directly, particularly on questions related to high-performance computing, GPU programming and interfaces that support vectorisation. The Laboratory is therefore not only one of C++’s major users, but also a contributor to its continuing development.

Bjarne Stroustrup speaking at CERN in September 2009 during a special IT Book Fair talk on “The Design of C++0x”, the draft standard that would later become C++11. © CERN

CERN’s requirements, however, cannot define a general-purpose standard. A facility designed specifically for its concurrency and parallel-computing needs may not work equally well for graphics, finance or other fields that depend on C++. “Not everything should be standard. Not everything can be standard,” Stroustrup said.

C++ was used for concurrent and parallel computing in the mid-1980s, long before these capabilities appeared in the standard. C++11 later introduced common foundations, including a memory model and initial standard support for threads. Meanwhile, specialised libraries and extensions let developers explore approaches that were not yet mature or general enough to standardise.

The same pattern continues with heterogeneous computing. C++ is used to programme GPUs, FPGAs and emerging specialised accelerators, often through extensions that express where code should run and where data should reside. As these technologies mature, common capabilities can move into the standard. C++26, for example, is expected to provide portable SIMD vectorisation. Such additions may simplify many applications, but CERN’s most demanding systems will probably continue to require specialised libraries and extensions. “The standard can take care of a lot,” Stroustrup concluded, “but not everything.”

A 15-year bet

The timescales of particle physics provide an unusually demanding test of a technology’s longevity. CERN’s current experiments are expected to operate for at least another 15 years, while possible future accelerators and detectors are already being designed. Software decisions made today can therefore have consequences for decades.

Asked whether C++ would still be a reference language for efficient computing in 15 years, Stroustrup recalled receiving a similar question from CERN developers more than a decade ago. They were planning systems that would have to remain operational for years. In his view, their confidence in C++ proved justified.

“In 15 years, you could do much, much worse than betting on C++,” he said. He expects the language available then to be noticeably better than it is today. “It’s a language, an ecosystem and a community that’s meant to evolve. It’s meant to address new challenges.”

C++ has continued to attract developers despite regular predictions of its decline. “Not bad for a language that people keep claiming to be dead,” Stroustrup remarked.

He was more reluctant to speculate about the next 50 years. “That’s science fiction,” he said, preferring to discuss horizons of ten, fifteen or perhaps twenty years, beyond which any answer would be little more than a guess.

Investing in people

Fifteen years is already a meaningful horizon at CERN. The experiments and computing systems now being planned will be developed and operated by scientists and engineers who are still at the beginning of their careers. This is where the STEAM Academy finds its wider purpose: not simply introducing participants to today’s technologies, but helping them acquire the knowledge and habits needed to assess and improve the tools on which future science will depend.

Running from 22 June to 28 August 2026, the Academy combines lectures, guided hands-on sessions, real-world case studies, seminars and collaborative learning activities delivered by specialists from CERN, universities, research laboratories and industry. Its core cohort follows the full ten-week curriculum, completes weekly assignments, and receives a certificate upon successful completion. Selected activities are also available to CERN personnel, subject to capacity.

Developed within the Next Generation Triggers project, the programme responds to the need for expertise spanning future data acquisition and trigger systems, modern software, edge computing and machine learning. Stroustrup’s visit showed why continuous training matters: technologies deliver their full value only when scientific communities learn how to use them well.

“The lesson is not simply that C++ has evolved,” Pantaleo said. “Our knowledge and practices must evolve with it. Through the Academy and its seminar series, we want to create a space in which participants and the wider CERN community can learn from leading experts, question established habits and prepare for the next generation of computing challenges.”

Modern scientific computing is not built by selecting a language once and then using it unchanged. It depends on communities that can evaluate new ideas and improve complex systems without discarding the knowledge embedded in them. For Stroustrup, CERN remains a particularly appropriate place for that conversation: “It’s one of the more interesting places on Earth.”

The CERN STEAM Academy Seminar Series continued on 28 July 2026 with Professor Maciej Besta of ETH Zurich and his seminar, “Towards Effective and Efficient Reasoning Language Models”. For more information about the complete programme you are invited to visit the official website:  https://steamacademy.web.cern.ch/