October 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] FocusFrog

by Sean P. DeNigris

Steven R. Baker wrote > I am not sure how to manage projects, or even how someone goes about > importing this stuff. It looks like you've already grasped package management. The next level up in project management is Metacello, which let's you declare the dependency relationships between packages and outside projects. For git repos, one creates a BaselineOf instead of the old ConfigurationOf. The difference between a baseline and a config is that the latter needs to have additional metadata because for example, the config itself could be hosted anywhere (e.g. in a different repo than the project), and it also needs to specify which package/dependency versions make up a particular version of your project. For git, the baseline relies on some assumptions to eliminate some declarations. For example, the baseline gets committed right with the rest of the project. Thus, if you have the baseline, you already know the repo, so that is omitted. Also, since git defines a snapshot of package versions via a particular commit, so you don't need that additional version info. ATM, you might still create a ConfigurationOf for integration with some tools, so for example, your project could appear and be loadable via the Project Catalog tool. But the configuration would be a thin wrapper which probably just delegates by declaring a baseline from a particular commit. Also, it would be good to provide an obvious access point to open the tool. `FocusFrogMainModel new openWithSpec` is a basic snippet that does the trick. You might want to document that with a class-side method (if you tag it with <script> it will be run-able from the code browser UI) and/or make it available from the World Menu. Lastly, when I tried to open the tool, I got errors because the icons were not initialized properly. HTH! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 7, 2017

So how do you use Live Coding ?

by Dimitris Chloupis

I think this deserves a seperate thread by itself, I was wondering what tricks , ideas and workflows you guys have come up with using live coding in Pharo ? What you like ? what you dont like ? What kinda of libraries you have made to enhance your live coding workflow ? What ideas you have that could enhance live coding workflow , inside and outside Pharo ? Any opinion is welcomed whether you just started coding in Pharo or coding in it for many years , I welcome any kind of brainstorming as long as it is relevant to live coding itself. Offray already was kind enough to share his workflow but I am sure other have something to add as well Its important to share because I am thinking of making a special mention in the Pharo wiki about live coding workflows so anything you share will be copy pasted there to help other people to get deeper into live coding If you can please offer practical examples , will make it easier for me and others to understand. So dont be shy, sharing is caring ;)

Oct. 7, 2017

FocusFrog

by Steven R. Baker

Hey all! Thanks for the help on all of my little issues. I've been plugging away at FocusFrog, my application for Getting Things Done.Â I have pushed the current code (mostly UI stuff in there just now) to GitLab: https://gitlab.com/srbaker/FocusFrog I am not sure how to manage projects, or even how someone goes about importing this stuff. If anyone of you cares to pull that down and provide suggestions, I will be more than happy to take them! Currently, I'm fixing up the view switching when you click the sidebar buttons, and improving the task item views. Is there a document somewhere about how you're supposed to publish things for Pharo? I'd like to make sure this follows the "established best practices." Cheers! -Steven

Oct. 7, 2017

Re: [Pharo-users] FileReference#entries caching?

by Steven R. Baker

On 07/10/17 14:22, Peter UhnÃ¡k wrote: > On Sat, Oct 7, 2017 at 1:02 PM, Steven R. Baker > <steven(a)stevenrbaker.com <mailto:steven@stevenrbaker.com>> wrote: > > Is it cached or something? How do I guarantee that I'm *definitely* > getting the current state of the directory on disk? > > > This looks extremely strange, I've never seen that inspecting > files/directories would be somehow "out of sync" with the disk, > because it is always asking the disk. > > > > Should I not even be using FileReference for this? > > > If you are loading png icons into Pharo, you can consider > usingÂ https://github.com/peteruhnak/IconFactory/ instead (shameless > self promotion :) ) Will definitely switch to this; I wasn't aware of the pattern, but obviously I want to follow them where possible. :) > Peter

Oct. 7, 2017

Re: [Pharo-users] Equals and HashCode Builder

by Sean P. DeNigris

Noury Bouraqadi-2 wrote > The code + tests are here > http://smalltalkhub.com/#!/~CAR/ReusableBricks/packages/Equals I forked to https://github.com/seandenigris/Pharo-Equals with a baseline to make it easier to try out/possibly-integrate. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 7, 2017

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

by Dimitris Chloupis

Indeed if you google "live coding" you get a lot of audio visual related tools. I have to confess because I am working with graphics, live coding is pretty much bread and butter of my workflow , cannot imagine myself working without it. When you step out of audio visual and other live performance arts you barely see "live coding" mentioned if not at all. The only exception I know is RunRev's LiveCode , similar to Pharo in the general idea, used to be closed source but now there is an open source version and Apple's Swift's Playgrounds which were inspired by a Smalltalk like demo. Fragmantation is indeed an issue with all programming languages including Pharo but on the other hand is a necessarily evil for innovation because my experience is that where there is unity there is also stagnation of progress but this enters philosophical ground I rather not venture into. On Sat, Oct 7, 2017 at 6:18 PM Offray Vladimir Luna CÃ¡rdenas < offray.luna(a)mutabit.com> wrote: > I think that there are some communities that are more receptive of live > coding, beyond programmers. Scientist, journalists, hacktivists, data > visualizers, musicians, come to mind and I have a better experience and > more openness to live coding with them that with the "classical > programmer/coder". With our recent Data Journalism Handbook, adaptation in > Grafoscopio [1] and our recurrent Data Week hackathon+workshops[2], we're > trying to reach new audiences and communities. > [1] http://mutabit.com/repos.fossil/mapeda/ > [2] http://mutabit.com/dataweek/ > > Cheers, > > Offray > > > On 07/10/17 07:40, Dimitris Chloupis wrote: > > Yes I agree with this > > Pharo is a live coding BASED enviroment. For Pharo live coding is not just > an easy to use feature it based its entire mentality around the idea of > live coding. > > Even though Smalltalk borrowed live coding and image format from Lisp we > are more "pure" in that regard even compared to Lisp. > > But one thing to note here is that live coding is not really that useful > when used always. At least for me I rely a lot on it for debugging and > experimenting. But when I work based on a plan , or code just works I do > not care so much about it. > > So my workflow in the end is semi-live coding because I dont feel I need > live coding 24/7 to be super productive. > > Of course that creates some barriers in the end when tools are not made to > work 24/7 on a live coding context. To that extend Pharo is definetly > superior and a true live coding enviroment. > > You are suprised that you can do live coding in C++ but I was trully > shocked. > > My saga to do live coding in C++ started as a joke, something to use to > mock C++ ugliness and weakness. But oh boy it did slap it back to my face. > > The process is again simple, you wrap eveything inside a main loop,and > call in this loop functions (C has no objects obvious) or methods if you > use C++ from DLLs. Those DLLs obviously contain 99.9% of your code. Because > a DLL can be reloaded it allows you not to stop executing and replace code > on the fly. The main loop is wrapped inside an exception to make sure the > an error will never crash your application, C/C++ exceptions are more > powerful than Pharo live coding in that regard because in Pharo if you do > anything bad with UFFI and crash it , it will crash for sure. > > If you keep the DLL small and you use tons of small dlls your compile > times will be almost instantenous. You can also with very view lines detect > date signature change in source file and trigger background compilation. > Again few lines of code. The last mountain is live state, in this case the > executable pass a single pointer and instead of the executable handling the > memory its actually the dlls that handle it but the executable because it > cannot crash or exit will keep the live state running. You can also use > memory mapped file to store live state as they perform pure memory dumps. > > All in all you will end up with 100 lines of code that can be wrapped into > a library and reused in the next project with zero setup. Its an one time > pain. > > Will I would recommend C++ over Pharo for live coding .... helll no.... > C++ obviously misses a hugely important live coding ingredient which is > reflection. We do live coding because we want to interact with those > objects ask questions about what is going on and why our code does not work > as intended > > However Python has no such limitation following a very similar design to > Smalltalk and being much more powerful language than C++. Python follow > very closely the Smalltalk paradigm even though there is not a single > mention of Smalltalk , anywhere in the Python community or of live coding. > > Live coding in C++ has become a huge deal in game development mainly > because game development tend to want to change things on the fly and games > are so big with extremely long compile times. Unreal has made a huge deal > over its ability to hot reload C++ code in its editor , though I do not > like its approach so much. > > Bottom line is yes its easy and simple to do live coding in other > languages, not recommended so much in C++ because of its static compiled > nature and lack of reflection but for dynamic language like Python it can > come pretty close and I speak from experience. > > At least I have not found something in Python that made me wish I was > live coding in Pharo so far, but then yes I still think its better to have > a full blown live coding. Also from my limited understanding I have figured > out that pretty much every language out there allows for reloading code > which is pretty much a very large requirement for live coding. > > So yes you can live code to an extend, lesser in languages like C++ , more > so in language like Python, Ruby etc. Can you get the Pharo experience ? In > a dynamic language with the creation of a live coding library you could get > pretty close but never exactly the same. > > Pharo still is the undisputed king of live coding. > > Why live coding is not a huge thing in coding in general, I am willing to > bet it has more to do with coder mentality than language limitation. When > you are used to "dead code" workflow it difficult to switch. I struggle a > lot to get use to the live coding workflow of Pharo because I had to rewire > my brain. But in the end you cannot avoid live coding, there will be always > scenarios you would want to change things on the fly, reload code, store > live state etc. > > In the end it more a coder flaw than it is a language flaw. I know we love > to blame languages for our mistakes. > > But in our back of our head we all know we debate over languages that we > barely use only 0.000001% of their true potential. We are too lazy and > sometimes we need someone to slam our face to the truth to actually see it. > And by we I dont mean the Pharo community but human nature by itself. > That's exactly what Pharo did for me that motivated me exploring live > coding in other languages. > > If it was not for Pharo I would still be doing the old slow method of > correct, compile, restart and repeat till you hate yourself. > > On Sat, Oct 7, 2017 at 1:57 PM horrido <horrido.hobbies(a)gmail.com> wrote: > >> > My point is that indeed you can do with EASE live coding in a numerous >> languages, at least to my experience. I have tried only Python and C/C++. >> >> Until I came upon this thread, I never knew you could do live coding in >> Python and C/C++. And I was a professional C/C++ programmer for over 15 >> years! >> >> It is certainly a well-kept secret. I have found very little information >> on >> the web about doing live coding in these languages (in fact, none). This >> leads me to believe that the vast majority of Python and C/C++ developers >> don't know about, or don't do, live coding. >> >> Whether it's "easy" is rather subjective. I suspect it's not as easy nor >> as >> convenient as in Pharo. If it were, then live coding ought to be much more >> prevalent in the Python and C/C++ communities. After all, what developer >> doesn't want to improve their productivity or increase their velocity of >> development? >> >> The key differentiator here, I think, is that live coding is baked into >> Pharo/Smalltalk, thus making it natural to use. It is not natural for >> Python >> and C/C++ programmers. It would be difficult to convince the IT industry >> to >> adopt live coding en masse. >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> >

Oct. 7, 2017

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

by Offray Vladimir Luna CÃ¡rdenas

Ok. Glad to help. In the thread I mentioned some of the specific difficulties I had implementing Grafoscopio's idea in Python[1] (in one word: fragmentation, of technologies and computing paradigms) [1] http://mutabit.com/offray/static/blog/output/posts/grafoscopio-idea-and-ini… Cheers, Offray On 07/10/17 10:17, Dimitris Chloupis wrote: > Well I was refering to live coding itself, but you are correct, I have > not tried combining with literate coding hence why I was curious about > the difficulties you ecountered. I did not know that you focused so > much Grafoscopio on iterate coding. Thanks for enlighting me.Â > > I never implied that Python was easier in everything compared to > Pharo. Afterall kinda misses a huge chunk which is the IDE itself.Â > > There lies the challange of live coding as I initially said that we > each use it in a diffirent way. Thanks for the link also very > enlighting and it is what i wanted, an actual use case.Â > > On Sat, Oct 7, 2017 at 5:49 PM Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: > > > > On 06/10/17 21:00, Dimitris Chloupis wrote: > > Again very generic statements , and I see you refer to tools and > > libraries instead of OOP. We talking here Pharo vs Python on the > > language level because Python obviously does not come with an > IDE. But > > then Pharo does not come with literate programming tools or > libraries > > as well. > > No. We were talking about things "that Pharo can do that Python > can't do > or is most difficult". And, for me that includes the (community & > computing) environment provided by Pharo that allow you to go from and > idea to its implementation. In my case the idea was to provide an > experience which mix outlining (a la Leo Editor) with literate > computing > (a la Jupyter, IPython) [1]. Even if the original pieces where already > there in Python, mixing them was a nighmare (at least 3 years ago) and > Pharo was more empowering for going from idea to prototype and now > Pharo > has literate *computing* (not literate programming [2]) tools. > Grafoscopio is one of them. GT Documenter, in alpha now, is promising. > You can not have a single document for complex books in Jupyter. You > need to split/storage a single work in a "pile of files" metaphor. You > can, today, with Grafoscopio put a 300 pages long PDF in a single > notebook. So yes, there are things that are more complex in one > technology that in other (of course all computer languages are the > same > at enough distance, because all them are Turing complete and all > that stuff) > > [1] > http://mutabit.com/offray/static/blog/output/posts/on-deepness-and-complexi… > [2] > http://blog.fperez.org/2013/04/literate-computing-and-computational.html > > > > > I rather not go down the rabbit hole of third party libraries > because > > obviously I cannot participate in a discussion about libraries and > > areas of coding, I know nothing about. Plus Python has countless of > > libraries which makes a very longer discussion even if I was > familiar > > with them and Pharo has much less but still quite a lot of libraries > > as well. > > One of the advantages of being in a community is learning from others > experiences. You said that in your experience you have not found a > place > where Python were more difficult that in Pharo. I have shown that in > *my* experience there are. And agree, is unwise to discuss about > places > where one has no experience, when is better to learn from those > who have it. > > Cheers, > > Offray > >

Oct. 7, 2017

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

by Offray Vladimir Luna CÃ¡rdenas

I think that there are some communities that are more receptive of live coding, beyond programmers. Scientist, journalists, hacktivists, data visualizers, musicians, come to mind and I have a better experience and more openness to live coding with them that with the "classical programmer/coder". With our recent Data Journalism Handbook, adaptation in Grafoscopio [1] and our recurrent Data Week hackathon+workshops[2], we're trying to reach new audiences and communities. [1] http://mutabit.com/repos.fossil/mapeda/ [2] http://mutabit.com/dataweek/ Cheers, Offray On 07/10/17 07:40, Dimitris Chloupis wrote: > Yes I agree with this > > Pharo is a live coding BASED enviroment. For Pharo live coding is not > just an easy to use feature it based its entire mentality around the > idea of live coding. > > Even though Smalltalk borrowed live coding and image format from Lisp > we are more "pure" in that regard even compared to Lisp.Â > > But one thing to note here is that live coding is not really that > useful when used always. At least for me I rely a lot on it for > debugging and experimenting. But when I work based on a plan , or code > just works I do not care so much about it.Â > > So my workflow in the end is semi-live coding because I dont feel I > need live coding 24/7 to be super productive.Â > > Of course that creates some barriers in the end when tools are not > made to work 24/7 on a live coding context. To that extend Pharo is > definetly superior and a true live coding enviroment. > > You are suprised that you can do live coding in C++ but I was trully > shocked.Â > > My saga to do live coding in C++ started as a joke, something to use > to mock C++ ugliness and weakness. But oh boy it did slap it back to > my face.Â > > The process is again simple, you wrap eveything inside a main loop,and > call in this loop functions (C has no objects obvious) or methods if > you use C++ from DLLs. Those DLLs obviously contain 99.9% of your > code. Because a DLL can be reloaded it allows you not to stop > executing and replace code on the fly. The main loop is wrapped inside > an exception to make sure the an error will never crash your > application, C/C++ exceptions are more powerful than Pharo live coding > in that regard because in Pharo if you do anything bad with UFFI and > crash it , it will crash for sure.Â > > If you keep the DLL small andÂ you use tons of small dlls your compile > times will be almost instantenous. You can also with very view lines > detect date signature change in source file and trigger background > compilation. Again few lines of code. The last mountain is live state, > in this case the executable pass a single pointer and instead of the > executable handling the memory its actually the dlls that handle it > but the executable because it cannot crash or exit will keep the live > state running. You can also use memory mapped file to store live state > as they perform pure memory dumps.Â > > All in all you will end up with 100 lines of code that can be wrapped > into a library and reused in the next project with zero setup. Its an > one time pain.Â > > Will I would recommend C++ over Pharo for live coding .... helll > no.... C++ obviously misses a hugely important live coding ingredient > which is reflection. We do live coding because we want to interact > with those objects ask questions about what is going on and why our > code does not work as intended > > However Python has no such limitation following a very similar design > to Smalltalk and being much more powerful language than C++. Python > follow very closely the Smalltalk paradigm even though there is not a > single mention of Smalltalk , anywhere in the Python community or of > live coding. > Â > Live coding in C++ has become a huge deal in game development mainly > because game development tend to want to change things on the fly and > games are so big with extremely long compile times. Unreal has made a > huge deal over its ability to hot reload C++Â code in its editor , > though I do not like its approach so much. > > Bottom line is yes its easy and simple to do live coding in other > languages, not recommended so much in C++ because of its static > compiled nature and lack of reflection but for dynamic language like > Python it can come pretty close and I speak from experience.Â > > At least I have not found something in Python that made me wish I was > liveÂ coding in Pharo so far, but then yes I still think its better to > have a full blown live coding. Also from my limited understanding I > have figured out that pretty much every language out there allows for > reloading code which is pretty much a very large requirement for live > coding.Â > > So yes you can live code to an extend, lesser in languages like C++ , > more so in language like Python, Ruby etc. Can you get the Pharo > experience ? In a dynamic language with the creation of a live coding > library you could get pretty close but never exactly the same. > > Pharo still is the undisputed king of live coding.Â > > Why live coding is not a huge thing in coding in general, I am willing > to bet it has more to do with coder mentality than language > limitation. When you are used to "deadÂ code" workflow it difficult to > switch. I struggle a lot to get use to the live coding workflow of > Pharo because I had to rewire my brain. But in the end you cannot > avoid live coding, there will be always scenarios you would want to > change things on the fly, reload code, store live state etc.Â > > In the end it more a coder flaw than it is a language flaw. I know we > love to blame languages for our mistakes.Â > > But in our back of our head we all know we debate over languages that > we barely use only 0.000001% of their true potential. We are too lazy > and sometimes we need someone to slam our face to the truth to > actually see it. And by we I dont mean the Pharo community but human > nature by itself.Â That's exactly what Pharo did for me that motivated > me exploring live coding in other languages.Â > > If it was not for Pharo I would still be doing the old slow method of > correct, compile, restart and repeat till you hate yourself.Â > > On Sat, Oct 7, 2017 at 1:57 PM horrido <horrido.hobbies(a)gmail.com > <mailto:horrido.hobbies@gmail.com>> wrote: > > > My point is that indeed you can do with EASE live coding in a > numerous > languages, at least to my experience. I have tried only Python and > C/C++. > > Until I came upon this thread, I never knew you could do live > coding in > Python and C/C++. And I was a professional C/C++ programmer for > over 15 > years! > > It is certainly a well-kept secret. I have found very little > information on > the web about doing live coding in these languages (in fact, > none). This > leads me to believe that the vast majority of Python and C/C++ > developers > don't know about, or don't do, live coding. > > Whether it's "easy" is rather subjective. I suspect it's not as > easy nor as > convenient as in Pharo. If it were, then live coding ought to be > much more > prevalent in the Python and C/C++ communities. After all, what > developer > doesn't want to improve their productivity or increase their > velocity of > development? > > The key differentiator here, I think, is that live coding is baked > into > Pharo/Smalltalk, thus making it natural to use. It is not natural > for Python > and C/C++ programmers. It would be difficult to convince the IT > industry to > adopt live coding en masse. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Oct. 7, 2017

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

by Dimitris Chloupis

Well I was refering to live coding itself, but you are correct, I have not tried combining with literate coding hence why I was curious about the difficulties you ecountered. I did not know that you focused so much Grafoscopio on iterate coding. Thanks for enlighting me. I never implied that Python was easier in everything compared to Pharo. Afterall kinda misses a huge chunk which is the IDE itself. There lies the challange of live coding as I initially said that we each use it in a diffirent way. Thanks for the link also very enlighting and it is what i wanted, an actual use case. On Sat, Oct 7, 2017 at 5:49 PM Offray Vladimir Luna CÃ¡rdenas < offray.luna(a)mutabit.com> wrote: > > > On 06/10/17 21:00, Dimitris Chloupis wrote: > > Again very generic statements , and I see you refer to tools and > > libraries instead of OOP. We talking here Pharo vs Python on the > > language level because Python obviously does not come with an IDE. But > > then Pharo does not come with literate programming tools or libraries > > as well. > > No. We were talking about things "that Pharo can do that Python can't do > or is most difficult". And, for me that includes the (community & > computing) environment provided by Pharo that allow you to go from and > idea to its implementation. In my case the idea was to provide an > experience which mix outlining (a la Leo Editor) with literate computing > (a la Jupyter, IPython) [1]. Even if the original pieces where already > there in Python, mixing them was a nighmare (at least 3 years ago) and > Pharo was more empowering for going from idea to prototype and now Pharo > has literate *computing* (not literate programming [2]) tools. > Grafoscopio is one of them. GT Documenter, in alpha now, is promising. > You can not have a single document for complex books in Jupyter. You > need to split/storage a single work in a "pile of files" metaphor. You > can, today, with Grafoscopio put a 300 pages long PDF in a single > notebook. So yes, there are things that are more complex in one > technology that in other (of course all computer languages are the same > at enough distance, because all them are Turing complete and all that > stuff) > > [1] > > http://mutabit.com/offray/static/blog/output/posts/on-deepness-and-complexi… > [2] > http://blog.fperez.org/2013/04/literate-computing-and-computational.html > > > > > I rather not go down the rabbit hole of third party libraries because > > obviously I cannot participate in a discussion about libraries and > > areas of coding, I know nothing about. Plus Python has countless of > > libraries which makes a very longer discussion even if I was familiar > > with them and Pharo has much less but still quite a lot of libraries > > as well. > > One of the advantages of being in a community is learning from others > experiences. You said that in your experience you have not found a place > where Python were more difficult that in Pharo. I have shown that in > *my* experience there are. And agree, is unwise to discuss about places > where one has no experience, when is better to learn from those who have > it. > > Cheers, > > Offray > > >

Oct. 7, 2017

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

by Offray Vladimir Luna CÃ¡rdenas

On 06/10/17 21:00, Dimitris Chloupis wrote: > Again very generic statements , and I see you refer to tools and > libraries instead of OOP. We talking here Pharo vs Python on the > language level because Python obviously does not come with an IDE. But > then Pharo does not come with literate programming tools or libraries > as well. No. We were talking about things "that Pharo can do that Python can't do or is most difficult". And, for me that includes the (community & computing) environment provided by Pharo that allow you to go from and idea to its implementation. In my case the idea was to provide an experience which mix outlining (a la Leo Editor) with literate computing (a la Jupyter, IPython) [1]. Even if the original pieces where already there in Python, mixing them was a nighmare (at least 3 years ago) and Pharo was more empowering for going from idea to prototype and now Pharo has literate *computing* (not literate programming [2]) tools. Grafoscopio is one of them. GT Documenter, in alpha now, is promising. You can not have a single document for complex books in Jupyter. You need to split/storage a single work in a "pile of files" metaphor. You can, today, with Grafoscopio put a 300 pages long PDF in a single notebook. So yes, there are things that are more complex in one technology that in other (of course all computer languages are the same at enough distance, because all them are Turing complete and all that stuff) [1] http://mutabit.com/offray/static/blog/output/posts/on-deepness-and-complexi… [2] http://blog.fperez.org/2013/04/literate-computing-and-computational.html > > I rather not go down the rabbit hole of third party libraries because > obviously I cannot participate in a discussion about libraries and > areas of coding, I know nothing about. Plus Python has countless of > libraries which makes a very longer discussion even if I was familiar > with them and Pharo has much less but still quite a lot of libraries > as well. One of the advantages of being in a community is learning from others experiences. You said that in your experience you have not found a place where Python were more difficult that in Pharo. I have shown that in *my* experience there are. And agree, is unwise to discuss about places where one has no experience, when is better to learn from those who have it. Cheers, Offray

Oct. 7, 2017