D2X: A New Tool for Detecting Bugs in Coding

Developed at MIT, D2X is a new tool for detecting bugs in coding that works with most debuggers

Ajay Brahmakshatriya, an MIT Ph.D. student, came up with a straightforward yet difficult objective sometime in 2019. He aimed to enable those with knowledge in a certain field, such as climate modeling, bioinformatics, or architecture, to build their programming languages, known as domain-specific languages (or DSLs), even if they had little or no prior experience doing so.

Brahmakshatriya wanted these languages to include all the auxiliary functions people would need to comfortably use them, including tools for debugging. He was a member of the research team led by MIT Professor Saman Amarasinghe in the Institute's Computer Science and Artificial Intelligence Laboratory (CSAIL). He and Amarasinghe felt that this procedure for eliminating software defects is crucial since they have labeled the absence of debugging help "the Achilles heel for DSLs."

For both of them, the last several years have been fruitful. A software package called BuildIt was released in 2021 by Brahmakshatriya and Amarasinghe. It significantly streamlines the process of developing DSLs. The pair also unveiled D2X last month at a global conference in Montreal that the Society for Computing Machinery was a co-sponsor of. D2X makes it simple to add debugging to any DSL and has been demonstrated to function particularly well with BuildIt. One of the two Distinguished Paper Awards granted during the conference went to their paper on the project.

According to Brahmakshatriya, the primary goal of creating a language for a specific field is "to improve ease of use." For instance, a DSL for image processing may offer a method like "blurting the entire image." Brahmakshatriya points out that issuing the identical command in a general-purpose language would need writing many more lines of code. "That's a factor in why a DSL should be used. Performance is the alternative. The processes may be more easily optimized since they are exclusive to that area; as a result, they can be carried out in the right order and finished more quickly and efficiently.

BuildIt is referred to be "a DSL for constructing DSLs" by Brahmakshatriya. It makes it possible to take an already-existing, all-purpose programming language and reduce it until it becomes precisely specialized through a series of step-by-step processes. He continues, "Let's imagine you want to develop a program to address a problem. You might create a larger program to address the overall problem or a more focused program to address the specific subclass that interests you. The software runs more quickly the more specialized it is. These guiding concepts are taken into consideration while designing DSLs using BuildIt.

One of the earliest DSLs to emerge from Amarasinghe's team is Halide, an image-processing language created in 2012, years before BuildIt was available. Jonathan-Ragan Kelley, a graduate student at the time, and Andrew Adams, a postdoc at CSAIL, were responsible for leading its development. Halide is now widely used in many Adobe apps, including Photoshop, however, Amarasinghe notes that it still lacks a debugger. He continues, "The reason for that is because debuggers are highly difficult. Most tiny DSLs lack debugging functionality because they are difficult to create.

According to Brahmakshatriya, who maintains that each DSL should have its debugger, it is not a desirable state of affairs. Because they don't comprehend the domain, existing debuggers cannot be used directly with your new language. Furthermore, he asserts that it is impossible to design software that is 100 percent accurate the first time. "Even though faults frequently don't surface until much later in the development cycle, they always exist at the beginning. At that point, with 5,000 lines of code, it might be exceedingly challenging to detect a flaw. Software engineers may therefore be required to spend more than half of their time on the laborious task of debugging once a program is "code complete"—a designation given to it by its developers—and ready for testing.

D2X, which is called "detox" since it refers to the idea of purging your software of toxins or flaws, is here to help. D2X is a library—a piece of computer code that may be used by other programs—rather than a program in and of itself. It is made to function with current debuggers (such as GDB or LLDB), acting as a link between those tools and a specific DSL. Information regarding the program or programming language that has to be fixed is necessary for a debugger. According to Amarasinghe, "Each debugger needs that information in its specialized format, which may be a 400-page document." You won't need to worry about it if you utilize D2X. You are taken care of.

According to Brahmakshatriya, "your software may be debugged using common debuggers without any changes to the debuggers itself" utilizing D2X as the interface. The biggest benefit, in his opinion, of integrating D2X with BuildIt is that "you don't have to do any more effort if you develop a DSL using BuildIt. Without adding any more code, you receive a debugger for free.

Adrian Sampson, an associate professor of computer science at Cornell University, claims that "D2X confronts a fundamental contradiction in high-performance software head-on." Domain-specific languages are, on the one hand, our sole chance for significant advancements in computer efficiency in the contemporary period. Nevertheless, creating a new debugger from scratch for a new language is challenging, and the lack of a debugger is a valid justification for a programmer to choose a "worse" language over a "better" one. The beautiful thing about D2X is that it makes it easier to create a practical DSL debugger.

Yet in terms of Brahmakshatriya, that is not the conclusion of the narrative. In addition to debugging, he also wants to incorporate editing, which facilitates program writing, into BuildIt. Editors, for instance, might highlight particular words in a manuscript to make it easier to read. They can also carry out additional tasks, such as autocomplete, which fills in the text once a tiny amount has been typed.

Together with debuggers and editors, Brahmakshatriya would want to see profilers added to the BuildIt platform. According to him, profilers are similar to debuggers in that they allow you to evaluate the performance problems in your application rather than find faults. "You can use a profiler to discover which component of the software is slowing things down if the program is operating slower than planned." In the future, he thinks, more beneficial characteristics may be included.

Amarasinghe claims that all of these initiatives will make the idea of developing specialist languages considerably more appealing. According to him, a sizable population supports conventional languages; hundreds of programmers are creating tools for C, C++, or Java. On the other hand, "I don't have hundreds of programmers to give all that support if I am designing a basic DSL." Yet, he continues, "The little folks can now have all the stuff the big guys get, like debuggers and ultimately editors and profilers — the same advantages that come with traditional languages. And you may obtain it without needing teams of engineers to write intricate code.