A new episode of “Beyond Parsing” is online!
DSLs help shorten development time and reduce errors. This is true for many domains, including safety-critical ones. Yet, as they say, with great power comes great responsibility. What process do you need to follow to use DSLs in safety-critical contexts? How can you make sure that errors in your tools do not harm or kill people? We invited Oscar to find out.
Some quotes from the interview that are particularly interesting:
“Tools are always helping to improve things, but they are also the source of risks, additional risks. If you have a model from which you generate code, then those code generators can also introduce new errors even if they are quite helpful. The same holds of course for DSL. If you have a DSL that enables you to do cool things, then those cool things cannot go wrong (…). You have to discuss and analyze the risks.”
“If the tool is classified as being critical, then it has to be qualified somehow and there are different qualification methods around depending on different risk classes (…). If you have a tool that needs qualification, then you have to test it intensively.”
“That’s the benefit for tool providers: the tool user has something like a driver’s license, and the tool provider can provide qualification kits or any other support to make his tool usable in a new market.”
“The risk analysis is done in two steps. The first step is to define whether the tool has an impact on the safety of the developed product (…). The second step is then if there is an impact, we need to think of all potential tool errors. A potential tool error is not a real or a known tool error, that’s everything that can go wrong in the tool. And that’s typically very hard to find out.”
If you want to listen and read more, you can go here.