2019 will see the MIT Ph. D. Ajay Brahmakshatriya, a student, came up with a straightforward but challenging objective. He wanted to make it possible for people with expertise in a specific field—like climate modeling, bioinformatics, or architecture—to write their own programming languages, known as domain-specific languages (or DSLs), even if they had little to no 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 concurred that this procedure for eliminating errors in software is crucial because they have dubbed the absence of debugging support “the Achilles heel for DSLs.”. “.
“Halide is very popular now, and it is used in many Adobe applications, including Photoshop, but it still lacks a debugger, which is due to the complexity of debuggers. Because they are difficult to create, most small DSLs lack debugging support.”
MIT Professor Saman Amarasinghe in the Institute’s Computer Science .
For both of them, the past few years have been fruitful. BuildIt, a software package that makes the process of developing DSLs incredibly simple, was introduced in 2021 by Brahmakshatriya and Amarasinghe. The pair also unveiled D2X last month at a global conference in Montreal that the Association for Computing Machinery was a co-sponsor of. D2X makes it simple to add debugging to any DSL and has been demonstrated to work particularly well with BuildIt. Even better, one of the conference’s two Distinguished Paper Awards went to their paper on the project.
According to Brahmakshatriya, the main goal of creating a language for a specialized field is to “promote ease of use. For instance, a DSL for image processing might have the function “blur the entire image. It would take many more lines of code to issue the same command in a general-purpose language, according to Brahmakshatriya. That is part of the reason to use a DSL. Performance is another. ” Because the operations are particular to that domain, they are more easily optimized—carried out in the right order—and therefore finished more quickly and efficiently.
BuildIt is a “DSL for creating DSLs,” according to Brahmakshatriya. It facilitates a multi-step process for taking an existing, all-purpose programming language and narrowing it down until it becomes precisely specialized. In order to write a program to solve a problem, he says, “Let’s say you have a problem.” You could create a larger program to address the entire problem or a more focused program to address the specific subclass that interests you. The speed of the program depends on how specialized you make it. These guiding principles are what led to the creation of BuildIt, which is used to build DSLs.
One of the first DSLs to come out of Amarasinghe’s team is Halide, an image processing language created in 2012—years before BuildIt existed. Jonathan Ragan Kelley, a graduate student at the time, and Andrew Adams, a postdoc at CSAIL, were responsible for leading its development. According to Amarasinghe, “Halide is very popular right now and is used in many Adobe applications, including Photoshop, but it still doesn’t have a debugger.”. He continues, “The reason for that is that debuggers are very complex. The majority of small DSLs lack debugging support because they are difficult to write.”.
Brahmakshatriya insists that every DSL should have its own debugger because he believes that this is an undesirable state of affairs. “Because they don’t comprehend the domain, existing debuggers cannot be used directly with your new language. Furthermore, he claims that it is impossible to create a program that is flawless the first time. ” Even though errors frequently don’t surface until much later in the development cycle, you always start with something that contains errors. Once you have 5,000 lines of code, it can be very challenging to find a bug if one does occur. Therefore, software engineers may have to devote more than half of their time to the laborious task of debugging once a program is “code complete”—deemed ready for testing by its developers.
But there is hope in the form of D2X, which is pronounced “detox” because it refers to the idea of purging your program of toxins or flaws. D2X is not a program in the traditional sense; rather, it is a library—a body of code that can be used by different programs. As a bridge between those tools and a specific DSL, it is made to function with already-in-use debuggers (like GDB or LLDB). A debugger requires details about the program or programming language that needs to be fixed. According to Amarasinghe, “each debugger needs that information in its own particular format, which can be a 400-page document.”. “That’s not something you need to be concerned about if you use D2X. For you, it has been handled.”.
According to Brahmakshatriya, using D2X as the interface, “your program can be debugged using popular debuggers without any modifications to the debuggers themselves.”. That, in his opinion, is the main benefit of combining D2X and BuildIt: “If you write a DSL using BuildIt, you don’t have to do any extra work. Without adding a single new line of code, you receive a debugger for nothing.”.
Adrian Sampson, an associate professor of computer science at Cornell University, states that “D2X addresses an inherent contradiction in high-performance software head-on.”. “On the one hand, domain-specific languages are the only thing standing in the way of significant advancements in computing efficiency in the contemporary era. The absence of a debugger is a valid justification for a programmer to choose a “worse” language over a “better” one because it is difficult to create a new debugger from scratch for a new language. D2X is fantastic because it makes it easier to create a practical DSL debugger.”.
Regarding Brahmakshatriya, however, that is not the end of the story. Debugging and editing, a feature that makes writing programs simpler, are additional features he’d like to incorporate into BuildIt. Editors, for instance, can highlight particular words in a document to make it easier to read. Other tasks are also possible with them, like autocomplete, which fills in text after a small amount of input.
Along with debuggers and editors, Brahmakshatriya wants to see profilers as a component of the BuildIt platform. According to him, profilers are similar to debuggers, but instead of finding bugs, they help you evaluate the performance problems in your program. You can use a profiler to identify the area of the program that is slowing things down if the program is operating slower than anticipated. In the future, he says, more beneficial features might be added.
Amarasinghe claims that all of these initiatives will make the idea of developing specialized languages much more appealing. According to him, a sizable population supports conventional languages; thousands of programmers are creating tools for C, C, or Java. However, I don’t have thousands of programmers to provide all that support if I’m just building a basic DSL. However, he continues, “the little guys can now get all the things the others get, including debuggers and ultimately editors and profilers—the same advantages that come with traditional languages. Furthermore, you can obtain that without hiring groups of engineers to write intricate code.
More information: Ajay Brahmakshatriya and Saman Amarasinghe, D2X: An eXtensible conteXtual Debugger for Modern DSLs. groups.csail.mit.edu/commit/pa … 3/ajay-cgo23-d2x.pdf
