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,

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





Reply via email to