the impact of moldability

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."

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



--
www.tudorgirba.com
www.feenk.com

"Being happy is a matter of choice."

I like the way you react to my criticisms. In fact each time I complain
you make progress. You should really thank me in fact.

And you can name me if it makes you feel better. ;)


Now what you should measure is the ratio

     over engineering - complexity of the solution vs. spread of usage.

     because over engineering means more code to maintain, more complex
logic


For example, I think that the GTinspector is a success because the pane
are nice and useful.

Now EyeInspector was also extensible so this is not the extensibility
the point that is the difference in adoption:

     this is the way people can extend it

     the good widget support and better look


Now for Spotter I'm questionning the other scenarios that are not the
main ones:
     - find a class
     - implementors
     - refs
     - senders
In fact on the 50 that you can find I have problems to see the others
useful. You can argue and brainwash me still
when I look at me coding sessions I do not need more (do not tell me
that this is because I do not how to use Spotter - I should be
the one that produces mooc videos showing this great tool).

For the debugger I looked at the code and this is less a problem than I
thought (but this is based on Glamour and I do not like Glamour
with blocks with multiple arguments and dataflow).

Now the question is if you would have invested the time you spent in
moldable but in an advanced debugger
with object based breakpoints, concurrent support, alias support (like
the wormhole debugger of the phd of adrian) and back in time debugging
which ones people would really choose: because so far I do not debug
bytecode, nor petitparser.
And what I got is basically not much more than before. This is not
because you show the test setup on the side of the stack that it is
useful to me.

Note that my remark is not incompatible with the fact that you could
have a debugger framework that you can use
to support bytecode and petitparser debugging.

Stef

So you can claim what you feel and justify your actions still there are
other ways to measure success.

Stef

Le 4/6/16 à 18:45, Tudor Girba a écrit :

Hi Stef,

> On Jun 4, 2016, at 8:38 PM, stepharo <[hidden email]> wrote:
>
> I like the way you react to my criticisms. In fact each time I complain you make progress. You should really thank me in fact.

Thanks for reading.

I try my best to welcome criticism even when the tone is not appropriate. I do not always succeed.


> And you can name me if it makes you feel better. ;)

I do not take any pleasure in talking about persons. I take pleasure in talking about arguments. This is a post that I am writing since about 4 months. I have about 50 more in the pipeline. But, yes, you pushed me to finish this one and I am happy.


> Now what you should measure is the ratio
>
>    over engineering - complexity of the solution vs. spread of usage.
>
>    because over engineering means more code to maintain, more complex logic

I think we did that, too. For example, the GTInspector has 800 lines of code (including all utilities and several smaller browsers) which is less than the EyeInspector. At the same time Glamour (if you take away Brick which is a widget set) is about 10k lines of code which is the same as Spec.

For the domain of browsers, I think it proved to be quite appropriate and it made the code on top be tiny. Still, I think it’s too much code, and I think we can do a better job in Bloc to support workflows.


> For example, I think that the GTinspector is a success because the pane are nice and useful.

It is a success because there is a fundamental need for it. And because the design process that produced it looked at that fundamental need.


> Now EyeInspector was also extensible so this is not the extensibility the point that is the difference in adoption:
>
>    this is the way people can extend it

That is what the post says. Interestingly, it is the “scripting” thin API of the Glamour components which made this way of extending possible.


>    the good widget support and better look

The look is important, but you are forgetting the interaction. This is key.


> Now for Spotter I'm questionning the other scenarios that are not the main ones:
>    - find a class
>    - implementors
>    - refs
>    - senders
> In fact on the 50 that you can find I have problems to see the others useful. You can argue and brainwash me still
> when I look at me coding sessions I do not need more (do not tell me that this is because I do not how to use Spotter - I should be
> the one that produces mooc videos showing this great tool).

But, I never argued for that. I only argued that if you do not need it does not mean that others do not need it. In fact, the existence of extensions shows exactly the contrary.

You get a similar dynamics in the apps on the phone. Some people have a ton of apps, some people have very few apps, and the vast majority of people do not use the vast majority of apps. Yet, this does not mean that the apps are not useful. It simply means that when context plays an important role, you will get this type of distribution.

For example, last week I remember navigating Moose models, file systems, senders, implementors, packages, playground pages, remote snippets, examples, pragmas, loading from the catalog. So, for me, these are useful, but I do not need to convince you that they are useful. Now you can choose to have exactly the 4 searches you want. Spotter allows you to do just that.


> For the debugger I looked at the code and this is less a problem than I thought

Thanks for looking at it.


> (but this is based on Glamour and I do not like Glamour
> with blocks with multiple arguments and dataflow).

Well … it happens that this strange design made the other tools cheap enough to produce a shift in the way we build tools. It is not perfect at all, in fact we do not want this code (only the essence) in the Bloc world anymore, but there is some quality in there I guess.


> Now the question is if you would have invested the time you spent in moldable but in an advanced debugger
> with object based breakpoints, concurrent support, alias support (like the wormhole debugger of the phd of adrian) and back in time debugging which ones people would really choose

You seem to position this as an either/or type of problem. I do not think it is like that.

A key aspect in the GT Debugger is that it has no logic. All logic is in the DebuggerModel and was integrated a long time ago. That was about laying out the foundation for playing with all sorts of debuggers, including the ones you mention.

The result is that if people want to play they can and we will not have to choose either one or the other. We can have both at the same time and choose between them at runtime.


> : because so far I do not debug bytecode, nor petitparser.

You do not debug those because you do not develop with those packages :). I happen to have the need of debugging parsers, and this debugger makes a difference. The Glamour debugger also makes a difference for complicated workflows, but only if you have those workflows.

There are hundreds of extensions for the inspector. People said that they were not needed, yet . Many of those will be useful in only corner cases and for few people. But, now we can afford to have them. This is a workflow that never existed before. And we will get more of these possibilities.


> And what I got is basically not much more than before. This is not because you show the test setup on the side of the stack that it is
> useful to me.

Again. If you do not have the use case, you will not find the usefulness. That is because the workflow starts with a context, not with a tool.


> Note that my remark is not incompatible with the fact that you could have a debugger framework that you can use
> to support bytecode and petitparser debugging.

Of course not.


> Stef
>
> So you can claim what you feel and justify your actions still there are other ways to measure success.

Of course there are different types of success because there are many values we can pursue, and often the parts are much less than the sum.

I believe quite strongly in the value I argue for.  What you see here is the result of a hypothesis that I coined in 2009. I risked my career to explore it, and after 7 years it looks like there is enough evidence to indicate that that hypothesis might be true. I know companies that have a business on building tools that match the context of the problem. Now we are able to bring that business case to every little tiny problem. I think this is disruptive, I think this is important and I will continue to invest in this. It does not mean that other things are not important, though.

Cheers,
Doru


--
www.tudorgirba.com
www.feenk.com

"It's not what we do that matters most, it's how we do it."