"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." I am not dismiss your effort of course Pharo is 10 times more begineer friendly than it was 7 years ago, back then it was just a squeak fork , but it was mostly squeak. Of course you work hard and document your libraries, but you are not the rule , you are the exception. Most libraries dont come with documentation, most libraries dont come with enough class comments, hell most libraries dont even have a summary info in smalltalkhub. Esteban had to beg to get project descriptions. Does that look to you as begineer friendly ? "You helped with PBE and did screencasts, which is b) - is that a 'complete' lack of beginner documentation ?" See how I can even say that though like you I worked so hard on documenting things ? Am I a moron ? Maybe But the thing if there is one thing I love in my life the most is the truth. And the truth is even with my effort UPBE is not remotely close to being begineer friendly. The book itself in the Preface states that it requires knowledge of OOP and experience with other languages. My video tutorials are, but some of them are already outdated and I know even if I have the motivation to update them and thats definetly not begineer friendly. Its not about hurting your feelings, it about being realistic. We sit here and argue about the interface of the new debugger, and thats fine, of course we should keep working hard making pharo more begineer friendly but pharo wont become begineer friendly any time soon because we dont have the amount of people to get there. But our community grows because pharo improves and one of the improvement is that it becomes more begineer friendly? Should we stop ? should be discouraged about the difficulty of the whole task? Well if people are not discouraged from sending people to Mars why should I or you be discouraged from making pharo more beginner friendly. I never give up and surrender, but I dont try to advertise pharo as an easy to learn platform because when the student or beginner comes me and learns thisn and I tell them that Pharo is as easy to learn as python, ruby etc and hits those dead ends he/she will tell me "but you said it will be easy as X language" and it will not be. On Sun, Jan 10, 2016 at 5:22 PM Sven Van Caekenberghe <s...@stfx.eu> wrote: > > > 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. > > > > > > > > > > >
