An easier way to eliminate bugs in programming languages ​​MIT News

Sometime in 2019, MIT doctoral student Ajay Brahmakshatriya set a simple but still quite challenging goal. He wants to enable people with expertise in a specific field (such as climate modeling, bioinformatics or architecture) to write their own programming languages, so-called domain-specific languages ​​(or DSLs), even if they have little or no knowledge. Or have no experience creating programming languages. Brahmakshatriya, who is part of a research team led by MIT Computer Science and Artificial Intelligence Laboratory (CSAIL) professor Saman Amarasinghe, wants these languages ​​to come with all the accessibility features people need to easily use them, including debugging tools. He and Amarasinghe agree that the process of eliminating software bugs is critical, as they call the lack of debugging support “the Achilles heel of DSLs.”

It’s been a productive few years for both of them. In 2021, Brahmakshatriya and Amarasinghe launched BuildIt, a software package that greatly simplifies the task of creating DSLs. Last month, at the International Conference in Montreal, co-sponsored by the Association for Computing Machinery, the pair unveiled D2X, a tool that makes it easy to add debugging to any DSL and has proven to work particularly well with BuildIt. Their paper even won one of two Outstanding Paper Awards from the conference.

Brahmakshatriya explains that the main reason for developing languages ​​in specialized areas is “to improve ease of use.” For example, an image processing DSL might have a feature that “blurs the entire image.” Brahmakshatriya points out that issuing the same command in a common language would require more lines of code. “That’s part of the reason for using a DSL. The other is performance.” Because the operations are specific to the domain, they can be more easily optimized – executed in the correct order so they are completed more efficiently and faster.

Brahmakshatriya describes BuildIt as “a DSL for creating DSLs.” It facilitates the multi-step process of taking an existing general-purpose programming language and streamlining it until it becomes specialized in just the right way. “Suppose you have a problem and you want to write a program to solve it,” he said. “You can write a program that solves it entirely, or you can write a smaller program that solves a subclass of the problem that interests you. The more specialized you make the program, the faster it will run.” BuildIt is designed to Build your DSL with these guidelines in mind.

Halide – an image processing language invented in 2012, several years before BuildIt – was one of the first DSLs launched by Amarasinghe’s team. Its development was led by then-graduate student Jonathan-Ragan Kelley and then-CSAIL postdoc Andrew Adams. “Halide is very popular now and is used in many Adobe applications, including Photoshop, but it still doesn’t have a debugger,” Amarasinghe said. The reason, he adds, is that “debuggers are very complex. Writing them is very difficult, which is why most small DSLs have no debugging support.”

Brahmakshatriya believes that this is not an ideal situation, and he insists that each DSL should have its own debugger. “You can’t just use existing debuggers for the new language because they don’t understand the domain.” Not to mention it’s not possible, Write a program that works exactly right the first time, he said. “You always start with something that has bugs, although they usually don’t show up until later in the development cycle. If a bug occurs at this point, when you have 5,000 lines of code, it’s very difficult to find it.” So once the program “Code is complete” – when developers feel it is ready for testing – software engineers may have to devote more than half their time to the heavy lifting of debugging.

But help is coming in the form of D2X (pronounced “detox” as it relates to eliminating poisons or flaws in programs). D2X is not a program itself, but is classified as a library—a piece of computer code that can be reused by other programs. It is designed to work with existing debuggers such as GDB or LLDB, acting as a bridge between these tools and a given DSL. The debugger needs information about the program or programming language to be cleaned. “Each debugger requires information in its own specific format, which might be a 400-page document,” Amarasinghe said. “If you use D2X, you don’t have to worry about that. It’s all taken care of for you.”

Brahmakshatriya says that with D2X as an interface, “your program can be debugged using popular debuggers without any modifications to the debugger itself.” In his opinion, this is the main advantage of combining D2X with BuildIt: “If you With BuildIt you don’t have to do any extra work to write a DSL. You get a debugger for free and don’t have to write any extra code.”

“D2X addresses the inherent contradictions of high-performance software head-on,” commented Adrian Sampson, associate professor of computer science at Cornell University. “On the one hand, domain-specific languages ​​are our only hope for dramatically improving computational efficiency in the modern era. However, making a new debugger for a new language from scratch is difficult, and the lack of a debugger is something that programmers may reject A legitimate reason to choose a “worse” language over a “better” language. The great thing about D2X is that it lowers the barrier to building useful debuggers for DSLs.”

But as far as Brahma is concerned, the story is not over yet. In addition to debugging, another feature he hopes to incorporate with BuildIt is editing, which would make writing programs easier. For example, editors can highlight certain keywords in a document, which can improve its readability. They can perform other functions such as autocomplete, automatically filling in text after a small portion of the input.

Brahmakshatriya hopes to incorporate the analyzer into the BuildIt platform along with the debugger and editor. “Profilers are like debuggers, but instead of helping you find bugs, they let you evaluate performance issues in your program,” he said. “If a program is running slower than expected, you can use the profiler to understand which part of the program is stuck.” Other useful features may be added in the future, he said.

Amarasinghe believes that all these efforts will make the prospect of creating a dedicated language more attractive. “It seems to me that there is a huge amount of support for traditional languages ​​- thousands of programmers building tools for C, C++ or Java,” he said. “On the other hand, if I’m building a simple DSL, I don’t have thousands of programmers to provide all the support.” But now, with BuildIt and D2X, he adds, “small companies can get what other companies can do Everything you get, including the debugger and ultimately the editor and profiler – the same benefits you get with a traditional language. And you don’t need a team of engineers to write all kinds of complex code to achieve this.”

This work was supported by the Application Driven Architecture Research Center, the Defense Advanced Projects Agency (DARPA), the Semiconductor Research Corporation, and the Joint University Microelectronics Program Center co-sponsored by DARPA; the National Science Foundation (NSF); and Intel/U.S. National Science Foundation Award.

Source link

Leave a Reply

Your email address will not be published. Required fields are marked *