Developers rely on tooling for their language: linting, formatting, LSP, IDE integration. OpenEdge ABL has some tooling in the Progress IDE, but not on the command line or in popular editors.

What is ABL, and why does it need new tooling

Progress OpenEdge is a developer platform with its own programming language, ABL (Advanced Business Language). ABL was released in 1981 as 4GL and rebranded in 2006. Since the early 2000s, ABL hasn’t seen new tooling from outside the Progress suite of tools.

Many Progress teams have stopped using the Progress IDE and have switched to Visual Studio Code, losing the support they once had in exchange for a modern editor. Without these tools, code reviews take longer, more bugs make it to review and production, and the learning curve steepens for new hires.

Why hasn’t new tooling been created yet

ABL has approximately 560 keywords, both reserved and unreserved, documented and undocumented. JavaScript has 44 reserved keywords; Rust has 67 across strict, reserved, and weak categories.

ABL also supports any casing. The following are all valid and represent one keyword:

def
defi
define
Define
DEFINE
defINE

Combine that many keywords with that level of freedom and you have a complex grammar.

ABL was designed as an all-in-one platform: writing business logic, creating terminal user interfaces, and talking to the database, all in one syntax and one file, or split across many files. It was later adapted for graphical interfaces and finally web. Most shops now focus on the web and use a fraction of the language, but the full grammar remains. This size makes it difficult to design tooling for and has discouraged the open source community from building new tooling.

What Oxabl aims for

Oxabl, or oxidized tooling for ABL, aims to be the foundation for ABL tooling outside of the Progress suite. It currently comprises a lexer, parser, preprocessor, source mapping, and semantic analyses.

I opted to write Oxabl from scratch in Rust. The alternative would have been learning an existing tool like ANTLR or Tree Sitter. My main concern with leaning on existing tooling was speed. Those tools were designed for general purpose languages, not a niche language like ABL. Whatever tooling is created for a language as old as ABL needs to be fast. Fast enough to parse monorepos with a million lines of code that enterprises build up over decades.

Around the time I was planning Oxabl, Oxc, the JavaScript compiler, had gained traction for its speed. Oxc inspired me: if someone could make faster tooling for JavaScript, I could make a new toolchain for a language where almost none exists.

Oxc is also written in Rust, like other newer JavaScript toolchain components. I read The Rust Book and started writing my side projects in Rust to get more experience. By the time I started Oxabl, I could use Oxc as a reference for what works, not a tutorial.

What Oxabl does and doesn’t do

Oxabl parses the corpus codebase I use for validation with a 99.9% success rate. Its current throughput is 53 MiB/second without preprocessing on an 8-year-old laptop.

I started with the lexer, processing source code byte-by-byte into tokens. The goal was to tokenize 100% of a large ABL codebase with decades of history. Then came the parser. I started writing it by hand, handling one thing at a time. Variables, code blocks, functions, if statements. Once it started getting repetitive and I had a good structure to follow, I used AI for the remainder of the grammar. Now Oxabl can create tokens and parse code to generate an AST.

The semantic analysis layer is the newest and least refined, only adding a small portion of context to the AST.

Preprocessing adds an expensive extra step and is still in much earlier phases than the rest of the pipeline, so it doesn’t have concrete benchmarks yet.

I purposefully left finished tooling out of the initial goal. An LSP, linter, and formatter are planned but not immediate. Oxabl includes an analyze command that can output diagnostic results, like catching an unused variable.

Takeaway

The next milestone is real developer tooling. This will give ABL a toolchain that can support developers using whatever their preferred editor is, ensuring Progress shops can adhere to high code quality without rebuilding their codebase from scratch in a new language.

I had no prior compiler experience. AI walked me through concepts I’d never heard of and helped me write the repetitive parts of the grammar. That worked because compilers are well-studied and the output is mechanically verifiable: parse a corpus, compare the AST. AI works when the domain is well-mapped and the answer is checkable. Treat that as the criterion for handing AI a project, not novelty or scope. Oxabl’s first commit was January 21st, 2026, and I hope to ship something ABL developers can use by the end of the year.