Altair SLC on Positron Pro: SAS, R, and Python in one IDE

If you have SAS-language code that has to keep running and you also want your team working in R and Python in a modern IDE, you can have both. Altair SLC inside Positron Pro on Posit Workbench is one way to do it today.

Author's note

Most pharma teams aren't choosing between SAS and open source. They're living with both. There's legacy code that still has to run, validated outputs that need to match exactly, and statisticians who'd rather not relearn a language. At the same time, new work is increasingly happening in R and Python, the AI tooling around them is expanding rapidly, and the SCE has to support all of it.

In a recent post on R, Python and SAS in a modern SCE, Rafael made the case that the language question is really an architecture question. This post is a practical follow-up to one line in that piece: if the concern is SAS-language compatibility, alternatives exist.

Altair SLC is the main one. And the most interesting place to run it right now is inside Positron, hosted on Posit Workbench.

Why SAS is the default in regulated work

SAS earned its position in pharma.

Regulators are familiar with it, a given procedure has been producing the same outputs since the 1980s, which in a regulated context is a feature, not a stagnation. A single vendor handles the validation documentation, the support contracts, and the qualification paperwork, which gives audit teams a known shape to work with. The DATA step, the building block in SAS for transforming row-level data, is well-suited to the kind of tabular preparation that clinical data demands. And the industry built itself around SAS-fluent statisticians, CROs whose SOPs reference SAS by name, and SOPs whose validated state assumes SAS is the language underneath.

The FDA never mandated SAS, but the institutional gravity that built up around SAS over thirty years is real, and it doesn't disappear because R and Python grew.

A quick vocabulary note

This post uses several pharma and SAS-specific terms that may not be obvious if you don't work directly with clinical programming:

• DATA step, macros, ODS: the three pieces of SAS most legacy code is built on. The DATA step is for transforming data row by row, macros are reusable parameterized code blocks, and ODS (Output Delivery System) controls how output is rendered into RTF, PDF, or other formats.
• SDTM, ADaM: CDISC data standards for clinical study data. SDTM is the standard format for collected data; ADaM is the analysis-ready derivative.
• ISS, ISE: Integrated Summary of Safety and Integrated Summary of Efficacy, the cross-study summary documents in a regulatory submission.
• CSR: Clinical Study Report, the main deliverable for a completed study.
• TLF: Tables, Listings, and Figures, the standardized output deliverables that go into a CSR.

The setup

Altair, now Siemens since being acquired in March 2025, is the company behind Altair SLC, which kept its name despite the corporate change.

Altair SLC is a SAS-language execution engine. Not a clone of the SAS Institute product, not a translation layer. It compiles and runs SAS-language programs directly, reads and writes .sas7bdat files, and supports the DATA step, macros, ODS, and the major procedures. Siemens pitches it at around 90% language coverage.

Positron is Posit's polyglot IDE. R and Python are first-class, and the editor is built on the same foundation as VS Code, which means it supports the broader VS Code extension ecosystem. An SLC extension is available in that ecosystem.

Positron Pro is Posit's commercial edition, delivered through Posit Workbench. It runs as a managed session inside Workbench's authentication, resource management, and audit framework.

SAS-language code keeps working

The DATA step works. Macros work. ODS works. Most major procedures work. For most legacy programs, the code runs against SLC without modification.

The caveat is the 90% number, and the inherently missing 10%. There are procedure options, language constructs, and edge cases that don't run. For migration planning, Siemens ships a Code Analyser tool inside their separate desktop Altair Analytics Workbench IDE. It scans existing SAS programs and produces a compatibility report flagging which parts use features SLC doesn't support. Running it across the codebase before committing to SLC is a reasonable starting point.

In practice this covers the bulk of clinical programming work: SDTM and ADaM conversion, ISS and ISE summaries, CSR tables and listings, and the RTF or PDF outputs that feed into regulatory submissions. A 2024 study by Veramed at PHUSE EU ran the CDISC pilot study through SLC and found existing SAS-language programs ran without adaptation. They flagged upfront work needed on RTF styles and templates and a small set of statistical procedure outputs to validate, with most of the specific gaps already on the development roadmap.

SAS, R, and Python in one session

What distinguishes Positron as the host is that it runs SAS alongside R and Python, in the same session, in the same project.

A statistician can prepare an ADaM dataset using the DATA step, where SAS is well-suited to tabular work, and then build the TLF output in R without leaving the editor. The .sas7bdat file written by the SAS code is read directly by the R code. No CSV export. No second IDE. No context switch.

SLC takes this further. The engine itself supports calling R and Python from inside SAS-language programs, exchanging data between them, and being called from R or Python through its API. A SAS macro can hand off to a Python script for a machine learning step and pull the results back into a SAS dataset. An R pipeline can invoke an SLC program for a regulated calculation that already has decades of validation behind it.

What's different about this combination

SAS Institute customers on Viya already have PROC PYTHON and equivalents. From inside a SAS program you can call Python, exchange dataframes, and get results back. Multi-language interop on its own isn't unique.

What's different is what SLC on Positron focuses on. It's a Python-and-R-first IDE that happens to also run SAS-language code. The polyglot IDE you spend your day in shapes which language gets the attention, the tooling investment, and the AI assistance.

The licensing model is also different. Whether it works out cheaper depends on the team's shape, but the model is different enough that it's worth running the numbers.

The deployment fits inside the same Kubernetes-native SCE that runs your R and Python work, with the same auth, governance, and image-based deployment. For teams whose long-term plan involves growing the open-source side of the stack, SLC on Positron is a compelling alternative worth considering.

Double programming on the same IDE

In pharma, "double programming" is the practice of writing the same calculation independently in two implementations and comparing the outputs. It's standard practice for validation, a way to catch errors that no single programmer would catch alone. Historically, both implementations are in SAS. Increasingly, one stays in SAS and the other moves to R or Python.

The combination of SLC and Positron makes that practice cheaper. You can run a SAS-language program and a new R or Python implementation against the same source data, in the same session, and compare the outputs directly. When a value disagrees, you trace it without leaving the IDE. The comparison becomes a normal part of development rather than a separately scheduled validation step.

AI assistance helps on the open-source side. Positron ships its own data-science assistant: Positron Assistant. It's bring-your-own-key: instead of tying you to one vendor, it connects to model providers you already have an agreement with, including Anthropic, OpenAI, GitHub Copilot, and Amazon Bedrock, or any OpenAI-compatible endpoint placed behind your own gateway. Because the session talks to the chosen provider directly, prompts and code don't pass through Posit, and admins can pin the configuration and restrict which models are available.

What the platform team gets

For the team running the SCE, SAS-language work stops being a special case.

Positron Pro sessions run inside Workbench's existing administrative envelope. The same authentication, the same resource limits and queues, the same audit logs, the same image-based deployment, the same extension governance policies introduced in recent Workbench releases. SAS-language sessions are launched the same way as R and Python sessions, by the same users, against the same infrastructure.

A sizeable fraction of the cost of supporting SAS in a regulated environment comes from it being its own thing, with its own server, its own auth, its own logging, its own backup and DR story. Folding it into the same envelope as the rest of your SCE removes a category of operational and compliance work, not just a license line item.

Three engines, one roof

What this combination brings is the connection between worlds that used to require their own dedicated infrastructure. SAS, R, and Python were each developed independently, each with their own runtime, their own conventions, their own enterprise tooling. For regulated work, this has typically meant separate environments, separate validation processes, and separate compliance posture for each language.

Seeing these three engines come together for regulated work under the same roof is the point.

That kind of arrangement has typically been delivered by a complete SCE solution tied to a specific vendor. Posit's philosophy is different: enterprise-grade modules and tools that combine into a custom-fit environment, with independent components rather than a monolith. That's what makes the SLC integration possible at all.

If you're thinking through what this might look like for your team, our SAS to open source migration practice is built around incremental, coexistence-first migrations.