On 13/10/17 08:52, Vitor Medina Cruz wrote: > I completely agree with Ben. > > As for Dimitris, I have some points: > [...] > > The fact is , we love pain, we love barriers, we love doors that > slam into our face. We love challange. But only if we find it > interesting. > > > See, I think that’s not the point, the point is that people are very > resistant to any change in their habits, so much that’s usually better > to short-circuit into their habits to make a change instead of trying > to force a hard change on them. That is why I think Ben point of view > is not flawed at all, on the contrary, removing barriers is a way to > make Pharo seems more like what people are habituated, > short-circuiting peoples habits into Pharo usage. Withing time, people > better understanding of Pharo may trigger small, but incremental, > changes to it’s habits to get the “A-ha!!!” moment where live code and > all wonders of Pharo make sense. > > I frankly read very loosely the rest of you answer ( :) :P ), but I > get you are not interested in making Pharo popular rather than get > really interested, open minded people on borad so to make it even more > amazing, but I also disagree here (in part :) ). There are lot’s of > people who could do better for the community if the entrance were > easier, more popularity could means more opportunity in job field and, > in a more philosophical matter, a way to make the whole current > programming field better. Of course, with more popularity comes > disadvantages as well, some of which you already said, which can be > addressed, but if this is price to pay I personally think it is worth it. >
[...] > On Fri, Oct 13, 2017 at 4:00 AM, Dimitris Chloupis > <kilon.al...@gmail.com <mailto:kilon.al...@gmail.com>> wrote: > > > That is a familiar path, but still an obstacle for people to > get over in trying Pharo - i.e. its a barrier of entry. I've > previously referred to this article by JoelOnSoftware, but to > pull out a key part... "Think of these barriers as an obstacle > course that people have to run before you can count them as > your customers. If you start out with a field of 1000 runners, > about half of them will trip on the tires; half of the > survivors won’t be strong enough to jump the wall; half of > those survivors will fall off the rope ladder into the mud, > and so on, until only 1 or 2 people actually overcome all the > hurdles. With 8 or 9 barriers, everybody will have one > non-negotiable deal killer. This calculus means that > eliminating barriers to switching is the most important thing > you have to do if you want to take over an existing market, > because eliminating just one barrier will likely double your > sales. Eliminate two barriers, and you’ll double your sales > again." > > [...] > > > The learning curve of Smalltalk and Lisp are plain insane. Made > learningh DOS Assembly a walk in the park in comparison. > > But frankly thats half of the fun. > > Many obstacles, many challanges. > > And there lies my point that an obstacle is a good thing when it > becomes an interesting challange. You have to have at least a > degree of masochism to learn how to code in any language. Of > course the question is what makes an interesting challange and > welcome to the abyss that is called "human brain". None knows and > we are not anywhere close in finding out. > > What we know is that documentation is super important , whether > you are a masochist or not, you need it to progress. Problems is > that documentation is hard to create and maintain, again masochism > required. So we should not just worry about making it easier for > people to reach documentation we should make it easier for people > to maintain it. Because even masochism has its limits. Those > limits are as far it is a pleasureable pain. > > So congratulations to anyone reading this long post , you already > proven my point. > I read it the same way as Vitor did also (I don't know why my mail client marked some part of this thread as unread), so answering Dimitris mail is not a probe of being pain lovers ( :-P ). > A huge plus also for Pharo is the community and how welcoming it > is, we take for granted but my experience with Python was not the > best either. I joined the IRC channel, other than having to endure > the stupidity of "say lol 3 times and you are banned" , too many > wars over languages and how superior Python is than anything else. > Guido is god and blah blah blah... No thanks. > > People here are open minded, still "religious" about Smaltalk but > they actually want to help , not to teach, actually help. > > I think we are a bit too obsessed on how to make Pharo popular, > Smalltalkers suffer from this insecurity of the "failure" of the > "best language of the world" not only to become popular but also > to convince coders that "is not a a relic of the past". > > But we are fine, documentation is doing grear, Pharo is improving > rapidly , the community is welcoming as ever. All we need is > embrace our successes and our failures, reject the hype, consider > the crticism and accept it or reject it and generally carry on > doing what we all love. > > Improving Pharo. > > ;) > > I think, as I have said and mentioned in the thread, that the issue is having the proper community size (but I don't know how to calculate that). This, in my case means to show Pharo to non-developers (like myself): activists, journalist, (non-software) researchers and so on, and show them something similar (not equal) to what they know, but with advantages. So we start by learning Markdown, using Grafoscopio to write structured documents with markdown, then using it to learn how to create the same visualizations that you could do in a spreadsheet (pie and bar charts), , but with coding and then using coding to create visualization you can not get in as premade in any point and click interface. That path from what they know (mostly spreed sheets and word processing) to what is possible with coding has being worthy and more pleasant to traverse that the classical (and dumb) "hello world!" introductions to programming or even other "data science" course that are tools focused. We use the idea of moldable tools to "escape the tools". That means that you need to learn how to think symbolically (coding) to express the features you want the tool to have. Documentation is going well. In fact the stuff that kept me away of Squeak, despite of its potential was the lack of documentation. "The artifact is the curriculum" was to powerful but too heavy. You need a way to understand how to deconstruct and navigate the artifact that is usually anchored with the culture you have (books and reading) instead of only launching inspectors os browsing the code. Grafoscopio is my attempt to fill that gap between the world of objects/simulations and the world of scripts/documents. Cheers, Offray
