On Jun 4, 2016, at 7:34 PM, Ben Coman <btc(a)openinworld.com> wrote: Nice read and some interesting statistics.

It makes sense when laid out like that, but its a question of internalising the knowledge to make use of moldability more often.

One small edit... We are the beginning ==> We are at the beginning

cheers -ben On Sun, Jun 5, 2016 at 12:45 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: _______________________________________________ Moose-dev mailing list Moose-dev(a)list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

On Jun 5, 2016, at 5:35 AM, Evan Donahue <emdonahu(a)gmail.com> wrote: 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. _______________________________________________ Moose-dev mailing list Moose-dev(a)list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

Hi, I beleive the complains were not about the usefulness of moldability, but rather the stability of the tools. The debugger is a central piece of Pharo and when it breaks we are left naked out in the desert (a very cold one). nicolas On 04/06/2016 18:45, Tudor Girba wrote: usefulness of moldability (the ability of developers to customize their tools deeply and inexpensively). More specifically, the question was about the moldability of the GTDebugger. actually a competitive advantage: -- Nicolas Anquetil RMod team -- Inria Lille _______________________________________________ Moose-dev mailing list Moose-dev(a)list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev