For what it's worth, the moldable debugger/inspector framework has been an excellent fit for my current project, which involves an embedding of a domain specific logic programming language in Pharo. Since all of the internal computation is done using placeholder "logic variables" that don't actually contain any meaningful Smalltalk values, attempting to step through the execution just shows you an endless sea of "a Var, a Var, a Var." The custom inspector can look up the logic variables' current bindings and display meaningful information at any point in the computation.
Moreover, as I start to move from building the low level framework to building applications using that framework, it has become increasingly difficult to debug, since between every pair of significant domain-specific events lies a vast cascade of calls down into the low level infrastructure that tells me nothing about the logic of the program written on top of that infrastructure. It is not obvious that a more powerful generic debugger would solve this problem, since the program's "code" isn't actual Pharo code that a debugger can affix breakpoints to and step through, but rather a syntax tree made of vanilla Pharo objects that is only meaningful to the "interpreter." I have only just started playing with debugger extensions, but it seems promisingly like it will be able to do what I need.
This would be a significant accomplishment, since this particular DSL is notoriously hard to debug in other languages for the above stated reasons, and the standard debugging procedure usually involves a certain amount of "staring harder" at the code.
Cheers, Evan
-- View this message in context: http://forum.world.st/the-impact-of-moldability-tp4899177p4899225.html Sent from the Moose mailing list archive at Nabble.com.