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."
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@tudorgirba.com 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 Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Hi,
On Jun 4, 2016, at 7:34 PM, Ben Coman btc@openinworld.com 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 tudor@tudorgirba.com 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 Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com www.feenk.com
"Being happy is a matter of choice."
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.
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 emdonahu@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com www.feenk.com
"Reasonable is what we are accustomed with."
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 Moose-dev@list.inf.unibe.ch 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 eggs
If as you say "left naked in cold desert" is what it takes to push Pharo forward as fast as possible without compromising good design , then give me all the pain I can take it.
Fact is Pharo would be nowhere near to what it is today without the work of Moose team.
However as I am saying always we need more documentation, tools loose their moldability the less documented they are. To paraphrase another person " Documentation is not an obligation but is a necessity for success" . I love these blog posts but I would be willing to sacrifice some of the moldability to get documentation on how to use the tools and extend that goes far beyond a handful of blog posts. Though my recent effort to learn Unreal Engine which is made by team hundrends of time larger than the Moose team shown me that more people != more / better documentation. Modern software is suffering from 2 big curses
a) bad design, which was bad at the start but none never dared to improve it in order to not brake backward compatibility or familiarity b) and lack of documentation , good or bad.
With Moose at least we have got rid of the first one.
On Sun, Jun 5, 2016 at 11:02 AM Nicolas Anquetil nicolas.anquetil@inria.fr wrote:
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 Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- Nicolas Anquetil RMod team -- Inria Lille
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-
Ben Coman -
Dimitris Chloupis -
Evan Donahue -
Nicolas Anquetil -
Tudor Girba