the impact of moldability
Locked
 
|
Hi,
There were a couple of emails in the recent period that questioned the 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. I put together a couple of thoughts of why we think that moldability is actually a competitive advantage: http://www.humane-assessment.com/blog/the-impact-of-moldability/ Please read it and provide feedback. Cheers, Doru -- www.tudorgirba.com www.feenk.com "Reasonable is what we are accustomed with." _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
|
|
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 <[hidden email]> wrote: > Hi, > > There were a couple of emails in the recent period that questioned the 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. > > I put together a couple of thoughts of why we think that moldability is actually a competitive advantage: > http://www.humane-assessment.com/blog/the-impact-of-moldability/ > > Please read it and provide feedback. > > Cheers, > Doru > > -- > www.tudorgirba.com > www.feenk.com > > "Reasonable is what we are accustomed with." > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
|
|
Hi,
> On Jun 4, 2016, at 7:34 PM, Ben Coman <[hidden email]> wrote: > > Nice read and some interesting statistics. Thanks > It makes sense when laid > out like that, but its a question of internalising the knowledge to > make use of moldability more often. Indeed. This is a challenge. In this regard, picking specific scenarios and asking questions about how to deal with them could help us build tutorials. > > One small edit... > We are the beginning > ==> We are at the beginning Fixed. Doru > > cheers -ben > > On Sun, Jun 5, 2016 at 12:45 AM, Tudor Girba <[hidden email]> wrote: >> Hi, >> >> There were a couple of emails in the recent period that questioned the 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. >> >> I put together a couple of thoughts of why we think that moldability is actually a competitive advantage: >> http://www.humane-assessment.com/blog/the-impact-of-moldability/ >> >> Please read it and provide feedback. >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Reasonable is what we are accustomed with." >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.list.inf.unibe.ch/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com www.feenk.com "Being happy is a matter of choice." _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba-2
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 |
|
|
Hi Evan,
Thanks for sharing this. This sounds very interesting. If it is possible, it would be great to turn your experience in a case study. Would you like to connect and provide more details? If you have questions about how to extend the debugger, please do not hesitate to ask. It would help us guide the documentation effort. Cheers, Doru > On Jun 5, 2016, at 5:35 AM, Evan Donahue <[hidden email]> 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 > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com www.feenk.com "Reasonable is what we are accustomed with." _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: the impact of moldability
|
|
In reply to this post by Tudor Girba-2
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: > Hi, > > There were a couple of emails in the recent period that questioned the 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. > > I put together a couple of thoughts of why we think that moldability is actually a competitive advantage: > http://www.humane-assessment.com/blog/the-impact-of-moldability/ > > Please read it and provide feedback. > > Cheers, > Doru > > -- > www.tudorgirba.com > www.feenk.com > > "Reasonable is what we are accustomed with." > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev -- Nicolas Anquetil RMod team -- Inria Lille _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
|
Tools need time to mature as the English say you cannot have an omelette without braking some eggsOn Sun, Jun 5, 2016 at 11:02 AM Nicolas Anquetil <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |