Personally I dont mind if its the default or not and I dont judge things unless i try them for a considerably amount of time.
Pharo is not and will not be begineer friendly for at least the not so distant future. Its not a matter of whether the GTDebugger becomes the default or not. There are a lot of issues Pharo has to face like most small community projects: a) Lack of substantial documentation b) Complete lack of begineer orientated documentation c) Lack of substantial begineer friendly libraries d) Lack of Libraries in general e) Small community with limited support f) Lack of support of other languages g) Completely diffirent coding paradigm from familar approaches etc etc Python is an excelent example of a programming language which is probably the most begineer friendly out there and the one that I recommend the most, for one new to coding and ones coming from another language. Unfortunately begineer friendly approaches on IDE and language level require big resources that pharo does not possess. For me pharo is an advanced coder orientated tool, with a steep learning curve, targeted at coder already familiar with OOP and the pitfalls of regular coding with considerable experience that look for a new way of coding that is radically different to what they are used to. Again I cannot really say if the old debugger is more begineer friendly than the new, I will have to try it for a week to offer an educated opinion. Also as I have already said I will be building my own workflow and guis with pharo because in many cases I dont like the design of old and new pharo tools, so for me at least I dont care if GTDebugger will become the default on this release or the other, what I do care is that is moldable, a design I have praised Spotter as well about, which means its easier for me to change take off its GUI , use my own GUI in place and maybe customize it a bit here and there. Thus I wont be pushing for anything since I will be fine with any scenario as long as the new debugger is integrated. I am coding with pharo because I am interested in making tools that fit like a glove to my needs and desires and help me automate my workflow as a 3d artists. I dont feel the need to impose my preference on other people since its easy enough to customise to great extend how Pharo looks and behaves and none else is going to build the tools I want to use since my desires are so specific and not what the average coder wants. For example ChronosManager is a tool I use on daily basis. This is why I am a coder, because I find it fun to create my own tools even if those tools are based on tools others created. So I have zero intention in getting in the way of such decisions. But I cannot deny also that I am in favor of a debugger that allows me with ease to change its GUI and it behavior. On Sun, Jan 10, 2016 at 4:10 PM Ben Coman <b...@openinworld.com> wrote: > On Fri, Jan 8, 2016 at 6:24 PM, Tudor Girba <tu...@tudorgirba.com> wrote: > >> Hi, >> >> We are about to integrate in Pharo a new member of the Glamorous Toolkit: >> the GTDebugger. As this is a significant change that might affect your >> workflow, here is some background information to help you deal with the >> change. >> >> First, you should know that the change is not irreversible and it is >> easily possible to disabled the new debugger through a setting. >> > > Can we do it the other way for Pharo 5 "Release"? Keeping the existing > debugger as default and as desired people can enable GTDebugger. I know > this limits exposure and slows uptake and feedback, but prior to this > announcement there has been *zero* community discussion of making this the > default. I can't find the Pharo 5 roadmap/plan, but I don't remember > GTDebugger being mentioned at all. I worry how it looks to people > considering Pharo for big changes like this to be dropped out of the sky > without *public* forward *planning*. > > A big UI change like this should happen *early* in a release cycle - > because then you have a *long* time for it to become stable for > documentation. Even though Dimitris is keen, I can understand why its > disheartening for Stef. I'd hope the way is to introduce such big changes > is as a technology preview and have the *default* match the recently > developed documentation. > > Note my problem is only with the default for the Pharo 5 "Release", so it > could be default now to kick start its exposure and revert the default a > few weeks before the Pharo 5 Release. And its not like you lose a whole > year of feedback by not being default in Pharo 5 Release. The > documentation using newcomers who are most likely to use Pharo 5 "Release" > probably wouldn't have the confidence (or care) to provide the feedback you > want anyway. Many of those in the community who would normally provide > feedback will be follow Pharo 6 bleeding edge anyway, so they'll that won't > be stuck with the old debugger. Making GTDebugger the default early in > Pharo 6 should still get plenty of feedback from those that usually > contribute. > > btw, I am looking forward to using it for myself. > > cheers -ben > > > >> However, please do take the time to provide us feedback if something does >> not work out for you. We want to know what can be improved and we try to >> react as fast as we can. >> >> A practical change comes from the fact that the variables are manipulated >> through a GTInspector, which makes it cheaper to maintain in the longer run. >> >> While the first thing that will capture the attention is the default >> generic interface, the real power comes from the moldable nature of the >> debugger. Like all other GT tools, GTDebugger is also moldable by design. >> This means that we can construct custom debuggers for specific libraries at >> small costs (often measured in a couple of hundred lines of code). >> >> Here is an introductory overview blog post that also includes some links >> for further reading: >> http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ >> >> Please let us know what you think. >> >> >> >> >>
