=Paper=
{{Paper
|id=Vol-2019/mdebug_keynote
|storemode=property
|title=None
|pdfUrl=https://ceur-ws.org/Vol-2019/mdebug_keynote.pdf
|volume=Vol-2019
|dblpUrl=https://dblp.org/rec/conf/models/ChisG17
}}
==None==
https://ceur-ws.org/Vol-2019/mdebug_keynote.pdf
Moldable Debugging
Andrei Chiş Tudor Gı̂rba
feenk gmbh feenk gmbh
Bern, Switzerland Bern, Switzerland
andreichis.com tudorgirba.com
Abstract—Programming languages evolved towards letting de- Whittle et al. [4] observed that in the context of model-
velopers design software applications in terms of domain abstrac- driven engineering many developers build their own tools or
tions. What about development tools? While developers express make heavy adaptations to off-the-shelf tools, even if this
software using programming languages, they craft software
exclusively by interacting with development tools. Unfortunately, requires significant effort. Smith et al. [5] further noticed
all too often developers rely on rigid development tools, focused that developers take the initiative to build tools to solve the
on programming language constructs, unaware of application problems they face, especially when their organization’s culture
domains. On the one hand, we educate developers to shape promotes this activity.
custom and rich domain models. On the other hand, we still Hence, developers are willing to extend their tools. Support-
force them to use a one-size-fits-all-paradigm when it comes to
development tools. ing them in doing this implies not a focus on providing ready-
One way to approach this abstraction gap is to empower made functionality, but a focus on offering rich programabil-
developers to shape their development tools together with their ity [6]. Consider testing. With frameworks like SUnit, testing
domain models. In this extended abstract we explore how this frameworks focused explicitly on significantly decreasing the
can transform debugging and debuggers, and delve into what is cost of creating tests, encouraging the adoption of testing as
needed to make this view a reality. We argue that to achieve this,
debugging infrastructures need to support the straightforward an integral activity of the software development process. The
and inexpensive creation of custom debuggers by leveraging the same should happen for debugger extensions.
explicit representation of the underlying application domains.
III. ENABLING MOLDABILITY
I. PROGRAMMING IS MODELING Extending debuggers to capture domain-specific aspects
Software applications capture abstract models of the real should be as obvious as writing unit tests. Attaining this goal
world as executable models (i.e., programs) within the design is a challenging endeavour as it raises many questions: What
space of a programming language. Model-driven engineering are the right extension mechanisms? How inexpensive can
provides developers with different mechanisms for facilitat- the creation of a domain-specific debugger really be? Let us
ing the creation of models, like domain-specific modelling explore next the first of these questions in more details.
languages [1]. Object-oriented programming in particular sup- Understanding a domain model requires first and foremost
ports this desideratum by allowing developers to model their reasoning about its individual domain objects. Traditional
domains in terms of objects and message sends. debuggers support this through the use of object inspectors
Debugging software applications requires developers to that favor a generic view showing only the state of an object.
(i) navigate between domain abstractions and the code that While universally applicable, this solution does not take into
addresses those abstractions, and (ii) understand domain ab- account the varying needs of developers that could benefit
stractions together with their interactions. Traditional debug- from domain-specific views and exploration possibilities [7].
gers support this activity by focusing on generic stack-based For example, we should display an object representing a parser
operations, line breakpoints, and generic user interfaces. This using a view that shows its grammar productions, and a widget
impedes the ability of developers to take direct advantage using a view that shows its actual graphical representation
of the domain, leading to a fragmentation of their domain- or its containment structure. Hence, a moldable debugging
specific questions into low-level ones that can be answered with infrastructure should start by enabling developers to view
available tools [2]. To eliminate this abstraction gap developers model elements using multiple tailored views, and facilitate
should rely on debuggers that work at the level of abstraction the creation and integration of new views.
of an application’s domain and enable domain-specific views, Understanding domain objects in isolation is not enough.
queries and analyses [3]. While this goal is clear, it is not Depending on the application domain and their task, developers
always straightforward to reach. need to correlate information from multiple sources. For
example, when debugging a parser both the grammar rules
II. DEVELOPERS AS TOOL BUILDERS and the input being parsed are of interest; when debugging
When developers encounter domain-specific questions for an event-driven system, the publisher, the subscriber, and the
which their debuggers or development tools do not offer event are of interest. A moldable debugging infrastructure
a direct answer, they have the option to adapt those tools. should support the creation of multiple domain-specific user
interfaces for debugging that extract and highlight relevant data of views. On average creating a view requires 9 lines of code.
from application domains. A tailored user interface consists Combining these views to form custom user interfaces and
in multiple widgets, each showing custom views for domain adding debugging actions increases the cost. Moose also ships
objects. with six custom debuggers. By providing internal DSLs for
Once developers have custom user interfaces offering constructing user interfaces and specifying debugging actions,
domain-specific views, they also need to navigate through the a debugger can be created in under 500 LOC of code, on
execution at the level of abstraction of those domains. If the top of a base implementation of 1500 LOC. Certainly, the
domain is that of a parser, stepping through the execution LOC metric must be taken with care as it does not indicate
at the level of grammar production or the input string is the time and expertise needed to write the lines. Nevertheless,
what is needed. If it is an event-driven system, the right it does provide a good indication of the small size of these
level of abstraction is given by the propagation of events domain-specific debuggers. By supporting each step of the
through the system. To enable this, a moldable debugging customisation through an internal DSL, developers do not have
infrastructure needs to allow developers to create debugging to learn new syntaxes, only dedicated APIs.
operations that express and automate high-level abstractions Given the difficulty of debugging, improving how developers
from application domains. Debugging operations are then view and navigate their models is needed, even if the cost
attached to the appropriate widgets. of creating custom debuggers is high. A low cost can make
While addressing the basic information needs in a debugger, this activity even more appealing. In today’s world, we rarely
the aforementioned mechanisms are not enough. During de- develop an application without tests, or depend on external
bugging, developers cannot know in advance in what situations components without tests. In tomorrow’s world, we should be
they will find themselves in [8]. Hence, they might begin with as demanding when it comes to debugger extensions.
the wrong user interface and set of actions. If they do not
REFERENCES
know that certain views and actions are applicable for their
current debugging context, they will not use them. A moldable [1] B. Combemale, J. Deantoni, B. Baudry, R. B. France, J.-M. Jézéquel,
and J. Gray, “Globalizing modeling languages,” Computer, vol. 47, no. 6,
debugging infrastructure can address this by attaching to every pp. 68–71, 2014.
view, widget and action an activation predicate, i.e., a boolean [2] J. Sillito, G. C. Murphy, and K. De Volder, “Asking and answering
condition over the state of the program capturing those states questions during a programming change task,” IEEE Trans. Softw. Eng.,
vol. 34, pp. 434–451, Jul. 2008.
in which the extension is applicable. Then, only extensions [3] O. Nierstrasz, “The death of object-oriented programming,” in FASE
applicable in the current debugging context are made available; 2016, ser. LNCS, P. Stevens and A. Wasowski, Eds., vol. 9633. Springer-
if two or more user interfaces are applicable a developer should Verlag, 2016, pp. 3–10.
[4] J. Whittle, J. Hutchinson, M. Rouncefield, H. Burden, and R. Heldal,
be able to switch at run time between them. Model-Driven Engineering Languages and Systems: 16th International
Conference, (MODELS 2013). Berlin, Heidelberg: Springer Berlin
I V. O N T H E C O S T O F T O O L B U I L D I N G Heidelberg, 2013, ch. Industrial Adoption of Model-Driven Engineering:
Are the Tools Really the Problem?, pp. 1–17.
For developers to extend their debuggers, the cost associated [5] E. K. Smith, C. Bird, and T. Zimmermann, “Build it yourself! Home-
with creating extensions should be small. How we define cost, grown tools in a large software company,” in Proceedings of the 37th
and the way to reduce it, depends on the mechanism for International Conference on Software Engineering. IEEE – Institute of
Electrical and Electronics Engineers, May 2015.
defining extensions. If we automatically generate debugging [6] T. Gı̂rba and A. Chiş, “Pervasive Software Visualizations,” in Proceed-
extensions from a model’s specification [9], [10], the cost ings of 3rd IEEE Working Conference on Software Visualization, ser.
goes into creating well-formed specifications for models. If we VISSOFT’15. IEEE, Sep. 2015, pp. 1–5.
[7] A. Chiş, T. Gı̂rba, O. Nierstrasz, and A. Syrel, “The Moldable Inspector,”
provide developers with a toolset for constructing debugger in Proceedings of the 2015 ACM International Symposium on New Ideas,
extensions on top of their models, cost is related to the effort New Paradigms, and Reflections on Programming and Software, ser.
needed to develop and maintain these extra extensions. Onward! 2015. New York, NY, USA: ACM, 2015, pp. 44–60.
[8] R. DeLine, A. Bragdon, K. Rowan, J. Jacobsen, and S. P. Reiss,
Through the Moldable Debugger1 we explored the second di- “Debugger canvas: industrial experience with the code bubbles paradigm,”
rection, in the context of object-oriented programming [11], as in Proceedings of the 2012 International Conference on Software
object-oriented programming provides developers with a direct Engineering, ser. ICSE 2012. Piscataway, NJ, USA: IEEE Press, 2012,
pp. 1064–1073.
way of expressing domain models using objects. Debuggers [9] P. R. Henriques, M. J. V. Pereira, M. Mernik, M. Lenic, J. Gray, and
however rarely take those models into account. H. Wu, “Automatic generation of language-based tools using the LISA
We observed that the cost of creating custom views for system,” Software, IEE Proceedings -, vol. 152, no. 2, pp. 54–69, 2005.
[10] E. Bousse, J. Corley, B. Combemale, J. Gray, and B. Baudry, “Supporting
domain objects can be significantly reduced. Moose,2 a plat- Efficient and Advanced Omniscient Debugging for xDSMLs,” in 8th
form for software and data analysis comes with more than International Conference on Software Language Engineering (SLE) ,
230 extensions for visualising objects, ranging from parsers Pittsburg, United States, Oct. 2015.
[11] A. Chiş, M. Denker, T. Gı̂rba, and O. Nierstrasz, “Practical domain-
and compiled code to graphical widgets. Custom views are specific debuggers using the Moldable Debugger framework,” Computer
expressed using an internal DSL that supports different kinds Languages, Systems & Structures, vol. 44, Part A, pp. 89–113, 2015.
1 The Moldable Debugger is a model of an extensible debugger. GTDebugger
is an implementation of this model in Pharo (pharo.org) as part of the GToolkit
(gtoolkit.org).
2 moosetechnology.org