[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
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 ) I would need to go to a lot of
ZeroMQ, server programming, client programming, HTML interfaces,
scripting, object oriented (as listed in ).
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) 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).
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.
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.
>> 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
>> 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
> greetings, martin.
More information about the Pharo-users