> On 10 Jan 2016, at 15:48, Dimitris Chloupis <kilon.al...@gmail.com> wrote: > > 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
I know you mean well, that you only want to encourage people to work on these areas, but it hurts me (personally) quite a bit if you say it like that - because statements like that are like a self fulfilling prophecy and very bad advertising that is hard to counter. I have written many serious libraries with lot's of documentation and I have supported them for years, I have written standalone articles for various audiences and I am active on the ML's; I did my part for your points a) to e) - I cannot do more. Should I stop if even you cannot see it ? And many others did at least as much, if not more. You helped with PBE and did screencasts, which is b) - is that a 'complete' lack of beginner documentation ? Yes, Pharo (Smalltalk) is a bit strange, needs some getting used to, but basically it is like most other OO languages (but better ;-). Ever seen Haskel or Erlang, or C++ for that matter ? We should positively but honestly describe ourselves, not belittle our own work. > 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. I disagree, I once let one of my sons take some Python lessons on the Raspberry PI. We had quite a few WTF moments, not the least when things did not go as advertised (in other words, error messages and debugging is ugly as hell). But more importantly the course (one of the 'best') started explaining weird syntax from the beginning, that is not beginner friendly at all. The underlying model is not nice, you cannot hide that for long. Python is widespread, because it is better that some alternatives and has good C integration. > 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. > > > >
