Hi,I have taught with (I)Python and Pharo to non programmers or beginners and I would say, from that direct experience that Pharo is easier because it has an easier syntax, an uniform way of programming and a continuity between scripting, apps, code, code management and docs. So I will be talking about how I have dealt with a similar educative experience using pharo and python, where I think that is the pharo advantage and where I think, as a newbie and as a learner, are the weak spots to see how we can work on them.
The problem I had with python was that it is "just" the language, so even dealing with which is gonna be your IDE for editing code becomes an issue. We started with web2py for web development, which has a minimalist web IDE and comes with batteries included and is easier to learn that Django, Rails or Seaside, but when that IDE felt limited, supporting IDE on several Gnu/Linux distros (we used arch & debian based) and Windows and Mac started to make noise in the educative experience, even installing cross-platform solutions, because of the sightly differences in the tools and their tool chains. Then there was the issue with introspection of the models we declared on web2py, which required to create a list or some kind of view. Using web2py from IPython prompt shell was the most interactive experience we had, but then we need to use two separated interfaces for web2py: CLI (for interactive instrospection) and WUI for everything else. So we went with IPython interactive notebooks, which resolved some things on the idea of introducing newbies to modeling and computing via interactive documentation, but then there is the problem of source code management. We used fossil for documentation on our hackerspace workshops, what kept things simple, but because libraries where distributed with other source code management systems (usually git) we start to deal with git related issues on how to update the code, but the bigger issue was the lack of moldability of IPython notebook without a lot of cognitive overhead: If I want something like an interactive outliner combining features of Leo and IPython (like the proposed on [1]) I would need to go to a lot of different technologies and paradigms: JSON, JQuery, Javascript, python, ZeroMQ, server programming, client programming, HTML interfaces, scripting, object oriented (as listed in [2]).
[1] http://mutabit.com/offray/static/blog/output/posts/on-deepness-and-complexity-of-ipython-documents.html [2] http://mutabit.com/offray/static/blog/output/posts/grafoscopio-idea-and-initial-progress.html
In contrast, making the workshops with Pharo has been a lot more smooth experience: learning the basics of the language, models introspection, data visualization, scripting, interactive documentation, IDE, "apps", and code management, all happens from the same environment in a continuous fashion. Deep roots on Smalltalk as an environment for children and (de)constructive learning reveal themselves in this kind of setups, making learning easier for newbies and makes a sharp contrast with the Unix/OS tradition and programming languages made from programmers by programmers.
Of course, this experience has a lot of "band width" being a face to face workshop, so we can deal with any issue on real time, even without proper resources in knowledge (mostly all of us are newbies) or documentation (mostly all of it is directed towards programmers). But even with limited resources, the continuity of the environment, responsiveness of the community and moldability of tools beats almost everything else with bigger communities, more documentation, more (but inflexible) tools and a lot of "learning impedance". I have been able to prototype something in months, even with limited time, that in other environments, including python, would take orders of magnitude more time, effort and knowledge (at least in the kind of experience we had here, but YMMV)
It this experience, community has been the most valuable resource and binding experience for me. It's pretty supportive and friendly most of the time (including the git vs fossil or pillar vs markdown or ecstatic vs grav/anything-else healthy rants). So there is a lot of effort and advantage in Pharo for newbies, from increasing documentation & videos, to face to face workshops to MOOCs, mailing list and chat channels and I think that together we can deal with the challenges ahead.
The main concern for my is rhythm and interaction with the external world: being small means that not all the time we can be as supportive or proactive as we want. Some times I get quick, detailed and/or worked answers to my questions that I have not the time to experiment with, some times I'm working hard to learn something (like with my dynamic spec interface question[3]) and not getting feedback in days start to feel like eternity. Something similar applies to external world interaction, being small means that we don't have the time to implement stuff that bigger communities had: external libraries for supporting languages like yaml or markdown or a broader panoramic view on the state of affairs in a particular subject (i.e: flat file web generators or DVCS).
[3] http://forum.world.st/Spec-Binding-widgets-how-to-td4863742.html#a4870168
How can we deal with this rhythm issues to make the learning experience more continuous? How can we enrich the bridges with the external world (i.e: libraries, formats, data)?
Hope this helps. Offray On 10/01/16 11:04, Martin Bähr wrote:
Excerpts from Sven Van Caekenberghe's message of 2016-01-10 16:21:10 +0100: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) Should I stop if even you cannot see it ?maybe this is the part of the problem, there is a lot of stuff, but it is not always easy to find. the graphic last month with a list of interesting tools and libraries for various aspects of pharo was very informative. more of that would be nice. same goes for documentation, a lot of it exists, but it could maybe be structured better. what i mean here is, to group documentation by topic: what do you want to do? gui programming: from introduction to morphic/bloc/etc to serious complex gui applications web development: seaside tutorial zinc tutorial (that is an excellent beginner tutorial btw) rest, etc... data visualization: introduction to roassal, from simple example to advanced. most if not all of that is in the agile visualization book. etc...You helped with PBE and did screencasts, which is b) - is that a 'complete' lack of beginner documentation ?since last year i have observed several students from middle-school to university level, who all managed to learn pharo with little help, just by pointing them to a series of tutorials. the only extra motivation i have given them is a small task to solve on top of each tutorial. very rarely i had to answer extra questions. for the most part the students were able to work on their own with only the existing documentation available to them. while this is only anecdotal evidence, it shows that pharo is approachable by beginners. and i would claim, even complete beginners who have never programmed before, however i don't know if any of my students actually were complete beginners.Yes, Pharo (Smalltalk) is a bit strange, needs some getting used to, but basically it is like most other OO languages (but better ;-).and i would say it is only strange to those who are already somewhat experienced and have only seen and used curly-brace languages.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.what i like about python syntax for beginners is the indenting. it teaches clean code formatting. the rest is no better or worse than other similar languages. greetings, martin.
