[ann] gtdebugger in pharo 5.0
Locked
12
12
 
|
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. 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.   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. Cheers, Doru |
Re: [Pharo-dev] [ann] gtdebugger in pharo 5.0
|
|
Hi,
with a moldable debugger we should (in the future) be able to support debugging also different/other programming languages/DSLs in Pharo :) - although usually one does necessary have such a use case. So I guess GTInspector or other will be adopted to own needs more than GTDebugger. However: The only objection so far is that I dislike the order/size of the panes. The placement of the panes in GTDebugger (as for instance found in Moose) requires often to use the scrollbars of the pane showing the stack because of the text length. In GTDebugger the stack is at the top left, the source at the top right with a common splitter beneath the two panes: therefore the height (depth) of the stack pane is always the height of the code pane. When you have a long method to debug on the right much space is wasted for a deep stack on the left although you might only be interested in a few top frames. Contrary when you have are interested in a deep/full stack and you increase the height of the stack pane on the left you directly increase the height of the code pane and for short methods you waste a lot of space in the source pane as well. This is much better solved with the positioning in the traditinal Debugger: - Stack - Source - other So in my opinion We should preserve: - TOP: the stack at the top (using the full width of the window, so only vertical scrolling has to be done to "roll" on the stack, no need for horizontal scrolling as the area is wide enough) - MIDDLE: the source code pane in the middle (also using the full width of the window and there fore in alignment with code pane in the the usual tools like Nautilus, change sorter, ...) - BOTTON: one or more panel for inspection at the bottom It would be OK for me if others like the new layout better - but at least there should be an option to support the traditional layout as well (or support pane movemen/docking as in other IDEs) Also the debugger window in Moose wastes a lot of space/has unused space within the windows client are itself. For instance the splitters are very thick which might be an issue of the moose theme. Thanks T. Gesendet: Freitag, 08. Januar 2016 um 11:24 Uhr Von: "Tudor Girba" <[hidden email]> An: "Pharo Development List" <[hidden email]>, "Moose-dev Moose Dev" <[hidden email]>, "Any question about pharo is welcome" <[hidden email]> Betreff: [Pharo-dev] [ann] gtdebugger in pharo 5.0 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. 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. Cheers, Doru -- www.tudorgirba.com[http://www.tudorgirba.com] www.feenk.com[http://www.feenk.com] "Beauty is where we see it." |
|
|
I second Torsten’s comment with regard to the use of space, I also think the original positioning of stack and code panes is more efficient. > On Jan 8, 2016, at 14:28, Torsten Bergmann <[hidden email]> wrote: > > Hi, > > with a moldable debugger we should (in the future) be able to support > debugging also different/other programming languages/DSLs in Pharo :) > - although usually one does necessary have such a use case. So I guess > GTInspector or other will be adopted to own needs more than GTDebugger. > > However: > The only objection so far is that I dislike the order/size of the panes. > The placement of the panes in GTDebugger (as for instance found in Moose) > requires often to use the scrollbars of the pane showing the stack because > of the text length. > > In GTDebugger the stack is at the top left, the source at the top right with > a common splitter beneath the two panes: therefore the height (depth) of the > stack pane is always the height of the code pane. > When you have a long method to debug on the right much space is wasted for > a deep stack on the left although you might only be interested in a few top frames. > > Contrary when you have are interested in a deep/full stack and you increase the > height of the stack pane on the left you directly increase the height of the code > pane and for short methods you waste a lot of space in the source pane as well. > > This is much better solved with the positioning in the traditinal Debugger: > - Stack > - Source > - other > > So in my opinion We should preserve: > > - TOP: the stack at the top (using the full width of the window, so only vertical scrolling > has to be done to "roll" on the stack, no need for horizontal scrolling as the area > is wide enough) > - MIDDLE: the source code pane in the middle (also using the full width of the window and there > fore in alignment with code pane in the the usual tools like Nautilus, change sorter, ...) > - BOTTON: one or more panel for inspection at the bottom > > It would be OK for me if others like the new layout better - but at least there should be an > option to support the traditional layout as well (or support pane movemen/docking as in other IDEs) > > Also the debugger window in Moose wastes a lot of space/has unused space within the > windows client are itself. For instance the splitters are very thick which might be an issue of > the moose theme. > > Thanks > T. > > Gesendet: Freitag, 08. Januar 2016 um 11:24 Uhr > Von: "Tudor Girba" <[hidden email]> > An: "Pharo Development List" <[hidden email]>, "Moose-dev Moose Dev" <[hidden email]>, "Any question about pharo is welcome" <[hidden email]> > Betreff: [Pharo-dev] [ann] gtdebugger in pharo 5.0 > > 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. 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. > > Cheers, > Doru > > > -- > www.tudorgirba.com[http://www.tudorgirba.com] > www.feenk.com[http://www.feenk.com] > > "Beauty is where we see it." ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile |
Re: [Pharo-dev] [ann] gtdebugger in pharo 5.0
|
|
In reply to this post by Torsten Bergmann
Hi, Thanks a lot for the detailed feedback. On Jan 8, 2016, at 7:28 PM, Torsten Bergmann <[hidden email]> wrote: Yes. This would work quite well if the language would project on the AST of Pharo, like Helvetia does. - although usually one does necessary have such a use case. So I guess The debugger can be specialized for specific libraries or frameworks, not only languages. For example, we currently have extensions for PetitParser, Glamour, Announcements and they are meaningful. However: That is actually encouraging :). The placement of the panes in GTDebugger (as for instance found in Moose) The horizontal bar could also be prevented by making the items in the list wrapped (so, they might occupy multiple lines). In GTDebugger the stack is at the top left, the source at the top right with The reason for this choice was to expose the developer to more of the stack, but it is not an essential design choice. This is much better solved with the positioning in the traditinal Debugger: We will play with this a bit. Or does anyone else would like to give it a try? It would be OK for me if others like the new layout better - but at least there should be an Movement would be certainly interesting and I would be happy if someone would implement this in Morphic. Also the debugger window in Moose wastes a lot of space/has unused space within the It’s actually an issue in Glamour, but it can be adapted. Cheers, Doru Thanks |
Re: [Pharo-dev] [ann] gtdebugger in pharo 5.0
|
|
In reply to this post by Torsten Bergmann
Hi, On Jan 8, 2016, at 7:28 PM, Torsten Bergmann <[hidden email]> wrote: Yes. This would work quite well if the language would project on the AST of Pharo, like Helvetia does. - although usually one does necessary have such a use case. So I guess The debugger can be specialized for specific libraries or frameworks, not necessarily only languages. For example, we currently have extensions for PetitParser, Glamour, Announcements. I expect that every framework would benefit from a specialized debugger. This would not be an odd behavior at all. However: Thanks. We took this into account. Also the debugger window in Moose wastes a lot of space/has unused space within the Thanks. We reduced the splitter size in Glamour. Doru Thanks |
Re: [Pharo-dev] [ann] gtdebugger in pharo 5.0
|
|
In reply to this post by jfabry
Thanks. What do you think of the new solution? Is it sufficient?
Doru > On Jan 8, 2016, at 8:05 PM, Johan Fabry <[hidden email]> wrote: > > > I second Torsten’s comment with regard to the use of space, I also think the original positioning of stack and code panes is more efficient. > >> On Jan 8, 2016, at 14:28, Torsten Bergmann <[hidden email]> wrote: >> >> Hi, >> >> with a moldable debugger we should (in the future) be able to support >> debugging also different/other programming languages/DSLs in Pharo :) >> - although usually one does necessary have such a use case. So I guess >> GTInspector or other will be adopted to own needs more than GTDebugger. >> >> However: >> The only objection so far is that I dislike the order/size of the panes. >> The placement of the panes in GTDebugger (as for instance found in Moose) >> requires often to use the scrollbars of the pane showing the stack because >> of the text length. >> >> In GTDebugger the stack is at the top left, the source at the top right with >> a common splitter beneath the two panes: therefore the height (depth) of the >> stack pane is always the height of the code pane. >> When you have a long method to debug on the right much space is wasted for >> a deep stack on the left although you might only be interested in a few top frames. >> >> Contrary when you have are interested in a deep/full stack and you increase the >> height of the stack pane on the left you directly increase the height of the code >> pane and for short methods you waste a lot of space in the source pane as well. >> >> This is much better solved with the positioning in the traditinal Debugger: >> - Stack >> - Source >> - other >> >> So in my opinion We should preserve: >> >> - TOP: the stack at the top (using the full width of the window, so only vertical scrolling >> has to be done to "roll" on the stack, no need for horizontal scrolling as the area >> is wide enough) >> - MIDDLE: the source code pane in the middle (also using the full width of the window and there >> fore in alignment with code pane in the the usual tools like Nautilus, change sorter, ...) >> - BOTTON: one or more panel for inspection at the bottom >> >> It would be OK for me if others like the new layout better - but at least there should be an >> option to support the traditional layout as well (or support pane movemen/docking as in other IDEs) >> >> Also the debugger window in Moose wastes a lot of space/has unused space within the >> windows client are itself. For instance the splitters are very thick which might be an issue of >> the moose theme. >> >> Thanks >> T. >> >> Gesendet: Freitag, 08. Januar 2016 um 11:24 Uhr >> Von: "Tudor Girba" <[hidden email]> >> An: "Pharo Development List" <[hidden email]>, "Moose-dev Moose Dev" <[hidden email]>, "Any question about pharo is welcome" <[hidden email]> >> Betreff: [Pharo-dev] [ann] gtdebugger in pharo 5.0 >> >> 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. 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. >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com[http://www.tudorgirba.com] >> www.feenk.com[http://www.feenk.com] >> >> "Beauty is where we see it." > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > > -- www.tudorgirba.com www.feenk.com "It's not how it is, it is how we see it." |
|
|
In reply to this post by Tudor Girba-2
On Fri, Jan 8, 2016 at 6:24 PM, Tudor Girba <[hidden email]> wrote:
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
|
Re: [ann] gtdebugger in pharo 5.0
|
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. 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. 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. On Sun, Jan 10, 2016 at 4:10 PM Ben Coman <[hidden email]> wrote:
|
Re: [ann] gtdebugger in pharo 5.0
|
|
> On 10 Jan 2016, at 15:48, Dimitris Chloupis <[hidden email]> 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 <[hidden email]> wrote: > On Fri, Jan 8, 2016 at 6:24 PM, Tudor Girba <[hidden email]> 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. > > > > |
Re: [ann] gtdebugger in pharo 5.0
|
|
"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 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 ?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 ?" 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. On Sun, Jan 10, 2016 at 5:22 PM Sven Van Caekenberghe <[hidden email]> wrote:
|
Re: [ann] gtdebugger in pharo 5.0
|
|
In reply to this post by Sven Van Caekenberghe-2
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. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin Bähr working in china http://societyserver.org/mbaehr/ |
|
|
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. > |
|
|
In reply to this post by kilon.alios
How come?
It would be nice to think that such statements will be read by people not from our world and such statements are WRONG! > 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 |
|
|
In reply to this post by Tudor Girba-2
It looks much better to me, yes. I would need to use it some time before I could give more detailed feedback. (And I can’t really do that until the FFI is fixed, because all my development crashes the VM since I am using Roassal. So I am still on the last Pharo version before the VM switch.)
One last thing is that I am not convinced on having the ‘proceed’, ‘step into’, ‘step over’ et cetera buttons on the stack pane. To me they are more related to the source code pane, as you always see the results of pressing those buttons there, but on the stack not always, e.g. the ‘step over’ actions. > On Jan 9, 2016, at 19:06, Tudor Girba <[hidden email]> wrote: > > Thanks. What do you think of the new solution? Is it sufficient? > > Doru > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile |
Re: [ann] gtdebugger in pharo 5.0
|
|
In reply to this post by Ben Coman
Sent from my iPad
|
Re: [ann] gtdebugger in pharo 5.0
|
|
In reply to this post by Tudor Girba-2
Latest update: #50524 ) 2016-01-08 11:24 GMT+01:00 Tudor Girba <[hidden email]>:
|
Re: [ann] gtdebugger in pharo 5.0
|
|
In reply to this post by Tudor Girba-2
2016-01-08 11:24 GMT+01:00 Tudor Girba <[hidden email]>:
Accept and Cancel buttons shouldn't be there or should not act on if the codepane hasn't changed. (every press on "accept" writes a new method version, although the contents didn't changed - tested on Latest update: #50524 ) Most (all?) other tools don't have Accept/Cancel buttons. - I really miss the "List Methods using 'varname'/List Methods storing into 'varname' - is "stackTop" now gone ? I thought you wanted to add it to the stack ? - thisContext is gone as well ? - the Bytecode/GT button is badly placed, it looks like the "downarrow" window menu icon is a dropdown menu with label "Bytecode" (since when do we put buttons in the title pane? - the evaluator pane is shown as "dirty", as it does not make a difference if we accept the text in this pane, there shouldn't be a dirty indicator. - you can not use the inspector pane to change inst var values - there is no way to refresh the inspector pane I don't open bugtracker entries now, I 'll wait maybe this issues aren't bugs but features. nicolai |
|
|
no, I’m quite sure they are bugs :)
I also believe the other tools do not have accept/cancel visible (they are in contextual menus), so maybe they should be there. Esteban
|
Re: [ann] gtdebugger in pharo 5.0
|
|
In reply to this post by Nicolai Hess-3-2
Hi Nicolai, Thanks for reporting these issues. They are indeed bugs and we are working on fixing them. Cheers, Andrei On Tue, Jan 12, 2016 at 11:24 PM, Nicolai Hess <[hidden email]> wrote:
|
Re: [Moose-dev] [ann] gtdebugger in pharo 5.0
|
|
Hi,
Thanks indeed for the feedback. I think not quite all are bugs, but see more details inside. > On Jan 14, 2016, at 12:59 PM, Andrei Chis <[hidden email]> wrote: > > Hi Nicolai, > > Thanks for reporting these issues. They are indeed bugs and we are working on fixing them. > > Cheers, > Andrei > > On Tue, Jan 12, 2016 at 11:24 PM, Nicolai Hess <[hidden email]> wrote: > > > 2016-01-08 11:24 GMT+01:00 Tudor Girba <[hidden email]>: > 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. 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. > > Accept and Cancel buttons shouldn't be there > or should not act on if the codepane hasn't changed. > (every press on "accept" writes a new method version, although the contents didn't changed - tested on > Latest update: #50524 ) Good catch. This will happen even if the button would not be present. > Most (all?) other tools don't have Accept/Cancel buttons. The logic is that these are actions that do not depend on the selection, so in Glamour we map these on actions that are applicable to the entire presentation. A similar approach is present in the inspector, although probably it does not appear so prominently because there is no text. We could try to add them in a dropdown menu. Would that help? > - I really miss the "List Methods using 'varname'/List Methods storing into ‘varname' Please open an issue for this. > - is "stackTop" now gone ? I thought you wanted to add it to the stack ? > - thisContext is gone as well ? These were removed due to emergency mail exchange that happened during the last weekend. > - the Bytecode/GT button is badly placed, it looks like the "downarrow" window menu icon > is a dropdown menu with label “Bytecode" We could try to fix by adding more space to the left of the menu bar in the theme. Could you open an issue? > (since when do we put buttons in the title pane? Since Glamour makes it easy to have them there :). The GTPlayground and GTInspector have them, too. > - the evaluator pane is shown as "dirty", as it does not make a difference if we > accept the text in this pane, there shouldn't be a dirty indicator. This is a problem that seems to exist with basically every pharoScript in Glamour. You commented on an issue for this: https://pharo.fogbugz.com/f/cases/16757/GLMHighlighterTextRubEditingMode-always-indicates-text-was-changed-even-when-it-wasn-t > - you can not use the inspector pane to change inst var values This is a problem but it is not specific to the debugger. > - there is no way to refresh the inspector pane Indeed. Would it be enough if we added a refresh for the whole debugger? Cheers, Doru > I don't open bugtracker entries now, I 'll wait maybe this issues aren't bugs but > features. > > > nicolai > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com www.feenk.com "Not knowing how to do something is not an argument for how it cannot be done." |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |