[Pharo-users] [ann] gtdebugger in pharo 5.0

Offray Vladimir Luna Cárdenas offray at riseup.net
Sun Jan 10 12:46:56 EST 2016


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.
>





More information about the Pharo-users mailing list