D2X is a debugging tool that can be easily added to any domain-specific language (DSL) developed by CSAIL Professor Saman Amarasinghe and PhD student Ajay Brahmakshatriya at the Massachusetts Institute of Technology.
Brahmakshatriya claims that D2X is the answer to the difficulty of debugging DSLs. Software programmers may spend up to two-thirds of their time debugging once a programme has reached “code complete” and is ready for testing. D2X is the interface that gives the debugger access to the information it needs to fix a messed-up programme or language.
“Each debugger requires that information in its particular format, which can be a 400-page document,” explains Amarasinghe. If you choose the D2X route, you won’t have that problem. It’s already been handled for you.
D2X is not a standalone programme but a library that may be integrated into other applications. It’s meant to function as an intermediary between a debugger and a specific domain-specific language. The programme integrates exceptionally smoothly with BuildIt. The D2X called “the Achilles heel for DSLs”, just won the Distinguished Paper Award.
In 2019, Brahmakshatriya and Amarasinghe released a programme called BuildIt that simplifies developing DSLs. He aimed to make it easier for experts in fields like climate modelling, bioinformatics, and architecture to create their domain-specific languages (DSLs), even if they had no prior experience with language design.
Ease of use is a significant motivation when developing a DSL for a niche market. The “blur the entire image” function is an example of a function that may be included in a domain-specific language for image processing. More lines of code would be needed to accomplish the same task in a general-purpose programming language. DSLs’ efficiency is yet another selling point. Since the functions are only performed in one domain, they may be optimised and completed rapidly.
Users can create their domain-specific languages with BuildIt, as described by Brahmakshatriya. It streamlines the process of developing a DSL from a high-level language. Moreover, it assists in condensing the language to its most efficient level of specialisation.
Imagine, he continues, that you need a programme to fix a problem. You could develop a programme to solve the whole thing or write a minor programme to solve only the subclass of the problem that interests you. The more narrowly tailored the programme, the quicker it will execute. BuildIt was created to create DSLs according to these standards.
In 2012, Amarasinghe’s team developed Halide, a domain-specific language for processing images. Jonathan-Ragan Kelley, a graduate student at the time, and Andrew Adams, a postdoc at CSAIL, spearheaded its creation.
Halide needs a debugger despite its widespread use across Adobe products like Photoshop. Since writing a debugger is complex and challenging, most tiny DSLs must provide debugging capabilities.
Brahmakshatriya said each DSL needs its debugger. Software programmers may spend up to two-thirds of their time fixing bugs after a programme has been judged fit for testing.
D2X is a library that can be used in conjunction with other debuggers. A snippet of code that can be used in multiple applications. It was made to function as an intermediary between a certain DSL and popular debuggers like GDB and LLDB.
Each debugger has its own data set that must be removed before use. D2X makes it simpler to debug this 400-page document without learning how to utilise any debuggers. When you couple D2X with BuildIt, you effectively eliminate any additional labour. Without adding any more code, a debugger is included in the package.
According to Cornell computer science assistant professor Adrian Sampson, “D2X addresses an inherent contradiction in high-performance software head-on.”
