Yes, the "updated" angle was the crucial tactic. Thanks. I just wanted to inform you that in just 48 hours since publication, this article has gathered over 11,000 views! This is a new record for me. Fastest rising. I am astounded by the number; I really didn't expect it. It's a very, very nice way to end my campaign on a high note. Hopefully, Pharo (and Smalltalk) will become more popular. Cheers. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Thanks I think that this is really nice. Thanks for your time. On Fri, Oct 6, 2017 at 2:42 AM, Offray Vladimir Luna Cárdenas <offray.luna@mutabit.com> wrote:

Cool! Waiting for the updated version with this mailing list feedback on it.

Cheers,

Offray

On 05/10/17 19:35, horrido wrote:

...

Yes, the "updated" angle was the crucial tactic. Thanks.

I just wanted to inform you that in just 48 hours since publication, this article has gathered over 11,000 views! This is a new record for me. Fastest rising.

I am astounded by the number; I really didn't expect it. It's a very, very nice way to end my campaign on a high note. Hopefully, Pharo (and Smalltalk) will become more popular.

Cheers.

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

I received this comment from someone who complained: *What about the lack of documentation? From time to time I’ve checked some SmallTalk implementations like Squeak, GNU-Smalltalk and now Pharo. Of these, only GNU-SmallTalk appears to have a free, official programming guide and core library reference that any serious programmer expects from a language. https://www.gnu.org/software/smalltalk/manual-base/html_node/* I pointed to Pharo's documentation but then he came back with: *Then show me a link of the free, maintained reference documentation for the classes that form “the core library”, like this one for Python (https://docs.python.org/3/library/index.html)* It's true, most Smalltalks do not have a core library reference, not even VisualWorks! So what is the proper response to this complaint? Thanks. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

On 6 Oct 2017, at 14:54, horrido <horrido.hobbies@gmail.com> wrote:

I received this comment from someone who complained:

*What about the lack of documentation? From time to time I’ve checked some SmallTalk implementations like Squeak, GNU-Smalltalk and now Pharo. Of these, only GNU-SmallTalk appears to have a free, official programming guide and core library reference that any serious programmer expects from a language.

https://www.gnu.org/software/smalltalk/manual-base/html_node/*

I pointed to Pharo's documentation but then he came back with:

*Then show me a link of the free, maintained reference documentation for the classes that form “the core library”, like this one for Python (https://docs.python.org/3/library/index.html)*

It's true, most Smalltalks do not have a core library reference, not even VisualWorks! So what is the proper response to this complaint?

The first answer is that Pharo/Smalltalk is unique in that a running system/IDE contains _all_ source code, _all_ documentation (class, method, help, tutorial), _all_ unit tests and _all_ runnable examples in a very easy, accessible way. It takes some getting used to, but this is actually better and much more powerful than any alternative. The second answer is that there are lots of books and articles that take the classic/structured book/paper approach. There is http://books.pharo.org, http://themoosebook.org, http://book.seaside.st/book, http://medium.com/concerning-pharo and many more.

Thanks.

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

I saw this comment, and wonder if we might have an intro video (or cartoon) of how to run the ProfStef tutorial in the first few minutes of opening your first image.

They need to work on the presentation. How do you get started ? How does the code look like ? etc. Not just "download this program and buy this book" reply

yes, time, resources, someoneHasToDoIt all apply. just a random thought, cheers -ben On Fri, Oct 6, 2017 at 9:47 PM, horrido <horrido.hobbies@gmail.com> wrote:

Thanks. I gave your answer verbatim. I also added the following paragraph:

The problem I find with today’s developers is that they are rather closed-minded. They are rigid and inflexible, and not willing to adapt to new and different ways of doing things. In my generation (circa 1980–1990), people didn’t have a problem with trying different technologies. That’s why I had no issue with learning Smalltalk 10 years ago, after I had retired from a 20-year-long career in C systems programming and FORTRAN scientific programming.

Sven Van Caekenberghe-2 wrote

...

...

On 6 Oct 2017, at 14:54, horrido <

...

horrido.hobbies@

...

> wrote:

...

I received this comment from someone who complained:

*What about the lack of documentation? From time to time I’ve checked some SmallTalk implementations like Squeak, GNU-Smalltalk and now Pharo. Of these, only GNU-SmallTalk appears to have a free, official programming guide and core library reference that any serious programmer expects from a language.

https://www.gnu.org/software/smalltalk/manual-base/html_node/*

I pointed to Pharo's documentation but then he came back with:

*Then show me a link of the free, maintained reference documentation for the classes that form “the core library”, like this one for Python (https://docs.python.org/3/library/index.html)*

It's true, most Smalltalks do not have a core library reference, not

even

...

VisualWorks! So what is the proper response to this complaint?

The first answer is that Pharo/Smalltalk is unique in that a running system/IDE contains _all_ source code, _all_ documentation (class, method, help, tutorial), _all_ unit tests and _all_ runnable examples in a very easy, accessible way. It takes some getting used to, but this is actually better and much more powerful than any alternative.

The second answer is that there are lots of books and articles that take the classic/structured book/paper approach. There is http://books.pharo.org, http://themoosebook.org, http://book.seaside.st/book, http://medium.com/concerning-pharo and many more.

...

Thanks.

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Hey, guys, I'm mentioned in this O'Reilly newsletter <http://post.oreilly.com/form/oreilly/viewhtml/9z1zgj2l150hp80ah3enjvhjhqcnr2...> !!! All because of the Pharo article. I wonder, is my campaign /actually/ succeeding? If so, I can die happy. ;-) -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Interestingly, I'm getting a fair amount of pushback on this. Personally, I think it would be very helpful to have a live (updatable, so as to keep it current) reference page for the class library, something that developers can easily look up what they need. After all, most of the power of Pharo comes from the class library and we need to make it as accessible as possible to less experienced Pharoers (i.e., beginners). Exploring the class library through the System Browser is very inefficient. This is further exacerbated by the fact that many classes and methods are simply not well-documented (containing a cursory remark which is just barely useful). I realize that creating a live reference page is not easy to do. In fact, it's a lot of work. But the absence of such a page is a real obstacle to Pharo acceptance. horrido wrote

Thanks. I gave your answer verbatim. I also added the following paragraph:

The problem I find with today’s developers is that they are rather closed-minded. They are rigid and inflexible, and not willing to adapt to new and different ways of doing things. In my generation (circa 1980–1990), people didn’t have a problem with trying different technologies. That’s why I had no issue with learning Smalltalk 10 years ago, after I had retired from a 20-year-long career in C systems programming and FORTRAN scientific programming.

Sven Van Caekenberghe-2 wrote

...

...

On 6 Oct 2017, at 14:54, horrido <

...

horrido.hobbies@

...

> wrote:

...

I received this comment from someone who complained:

*What about the lack of documentation? From time to time I’ve checked some SmallTalk implementations like Squeak, GNU-Smalltalk and now Pharo. Of these, only GNU-SmallTalk appears to have a free, official programming guide and core library reference that any serious programmer expects from a language.

https://www.gnu.org/software/smalltalk/manual-base/html_node/*

I pointed to Pharo's documentation but then he came back with:

*Then show me a link of the free, maintained reference documentation for the classes that form “the core library”, like this one for Python (https://docs.python.org/3/library/index.html)*

It's true, most Smalltalks do not have a core library reference, not even VisualWorks! So what is the proper response to this complaint?

The first answer is that Pharo/Smalltalk is unique in that a running system/IDE contains _all_ source code, _all_ documentation (class, method, help, tutorial), _all_ unit tests and _all_ runnable examples in a very easy, accessible way. It takes some getting used to, but this is actually better and much more powerful than any alternative.

The second answer is that there are lots of books and articles that take the classic/structured book/paper approach. There is http://books.pharo.org, http://themoosebook.org, http://book.seaside.st/book, http://medium.com/concerning-pharo and many more.

...

Thanks.

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

On Tue, Oct 10, 2017 at 3:58 PM, horrido <horrido.hobbies@gmail.com> wrote:

Interestingly, I'm getting a fair amount of pushback on this. Personally, I think it would be very helpful to have a live (updatable, so as to keep it current) reference page for the class library, something that developers can easily look up what they need. After all, most of the power of Pharo comes from the class library and we need to make it as accessible as possible to less experienced Pharoers (i.e., beginners).

This is why I started to comment even the classes that we all know You see having a lovely comment on Association, Array, OrderedCollection with all the love we can is the best welcoming.

Exploring the class library through the System Browser is very inefficient. This is further exacerbated by the fact that many classes and methods are simply not well-documented (containing a cursory remark which is just barely useful).

Totally agree. Now the good aspect is that ANY pharoers can help making such class/method comments great. It takes 5 to 10 min. And I started to add executable examples " 3 + 2

...

...

5 "

I realize that creating a live reference page is not easy to do. In fact, it's a lot of work. But the absence of such a page is a real obstacle to Pharo acceptance.

In the past we generate a javadoc but nobody looked at it.

horrido wrote

...

Thanks. I gave your answer verbatim. I also added the following paragraph:

The problem I find with today’s developers is that they are rather closed-minded. They are rigid and inflexible, and not willing to adapt to new and different ways of doing things. In my generation (circa 1980–1990), people didn’t have a problem with trying different technologies. That’s why I had no issue with learning Smalltalk 10 years ago, after I had retired from a 20-year-long career in C systems programming and FORTRAN scientific programming.

Sven Van Caekenberghe-2 wrote

...

...

On 6 Oct 2017, at 14:54, horrido <

...

horrido.hobbies@

...

> wrote:

...

I received this comment from someone who complained:

*What about the lack of documentation? From time to time I’ve checked some SmallTalk implementations like Squeak, GNU-Smalltalk and now Pharo. Of these, only GNU-SmallTalk appears to have a free, official programming guide and core library reference that any serious programmer expects from a language.

https://www.gnu.org/software/smalltalk/manual-base/html_node/*

I pointed to Pharo's documentation but then he came back with:

*Then show me a link of the free, maintained reference documentation for the classes that form “the core library”, like this one for Python (https://docs.python.org/3/library/index.html)*

It's true, most Smalltalks do not have a core library reference, not even VisualWorks! So what is the proper response to this complaint?

The first answer is that Pharo/Smalltalk is unique in that a running system/IDE contains _all_ source code, _all_ documentation (class, method, help, tutorial), _all_ unit tests and _all_ runnable examples in a very easy, accessible way. It takes some getting used to, but this is actually better and much more powerful than any alternative.

The second answer is that there are lots of books and articles that take the classic/structured book/paper approach. There is http://books.pharo.org, http://themoosebook.org, http://book.seaside.st/book, http://medium.com/concerning-pharo and many more.

...

Thanks.

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

I dunno, maybe I’m weird, but I find the System Browser a fantastic way to explore the class library. If you find a class or method that isn’t well documented, write a comment and send a change request. Stef told me this ages ago. I might add, if you find a bug you should write a test that exercises the bug and submit it on fogbugz (the bug tracking system). I will reference of response of mine to a similar opinion made by Richard: https://medium.com/@vitormcruz/i-disagree-it-is-much-harder-to-find-anything... My 2 cents. On Tue, Oct 10, 2017 at 11:59 PM, john pfersich <jpfersich@gmail.com> wrote:

...

On Oct 10, 2017, at 09:58, horrido <horrido.hobbies@gmail.com> wrote:

Interestingly, I'm getting a fair amount of pushback on this. Personally, I think it would be very helpful to have a live (updatable, so as to keep it current) reference page for the class library, something that developers can easily look up what they need. After all, most of the power of Pharo comes from the class library and we need to make it as accessible as possible to less experienced Pharoers (i.e., beginners).

Exploring the class library through the System Browser is very inefficient. This is further exacerbated by the fact that many classes and methods are simply not well-documented (containing a cursory remark which is just barely useful).

I dunno, maybe I’m weird, but I find the System Browser a fantastic way to explore the class library. If you find a class or method that isn’t well documented, write a comment and send a change request. Stef told me this ages ago. I might add, if you find a bug you should write a test that exercises the bug and submit it on fogbugz (the bug tracking system).

...

I realize that creating a live reference page is not easy to do. In fact, it's a lot of work. But the absence of such a page is a real obstacle to Pharo acceptance.

horrido wrote

...

Thanks. I gave your answer verbatim. I also added the following paragraph:

The problem I find with today’s developers is that they are rather closed-minded. They are rigid and inflexible, and not willing to adapt to new and different ways of doing things. In my generation (circa 1980–1990), people didn’t have a problem with trying different technologies. That’s why I had no issue with learning Smalltalk 10 years ago, after I had retired from a 20-year-long career in C systems programming and FORTRAN scientific programming.

Sven Van Caekenberghe-2 wrote

...

...

On 6 Oct 2017, at 14:54, horrido <

...

horrido.hobbies@

...

> wrote:

...

I received this comment from someone who complained:

*What about the lack of documentation? From time to time I’ve checked some SmallTalk implementations like Squeak, GNU-Smalltalk and now Pharo. Of these, only GNU-SmallTalk appears to have a free, official programming guide and core library reference that any serious programmer expects from a language.

https://www.gnu.org/software/smalltalk/manual-base/html_node/*

I pointed to Pharo's documentation but then he came back with:

*Then show me a link of the free, maintained reference documentation

for

...

the classes that form “the core library”, like this one for Python (https://docs.python.org/3/library/index.html)*

It's true, most Smalltalks do not have a core library reference, not even VisualWorks! So what is the proper response to this complaint?

The first answer is that Pharo/Smalltalk is unique in that a running system/IDE contains _all_ source code, _all_ documentation (class, method, help, tutorial), _all_ unit tests and _all_ runnable examples in a very easy, accessible way. It takes some getting used to, but this is actually better and much more powerful than any alternative.

The second answer is that there are lots of books and articles that take the classic/structured book/paper approach. There is http://books.pharo.org, http://themoosebook.org, http://book.seaside.st/book, http://medium.com/concerning-pharo and many more.

...

Thanks.

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

The more I use Pharo, the less I use web documentation. For me seems pretty suboptimal compared to live environment with code browser and GT-Spotter. Regarding the comment on Medium, it also took me little to find #raisedTo:, so the millage can vary. What I was missing was proper books for particular domains, but Pharo books are covering that. I don't know if a Q&A site could improve search-ability for newbies (certainly you can find little stuff in Stack Overflow). My bet is about trying to create more "end user" tools (Grafoscopio is kind of this), besides tools for developers. There is a broad community of people who can be active contributors and members of the community, welcome Pharo and live coding a lot and don't complain that much about stuff that is not already pretty similar to what they already know (being that only English MOOC or online static html docs). Cheers, Offray On 11/10/17 07:34, Dimitris Chloupis wrote:

for me it is a yes and no situation, yes its very coold to have your entire system in your fingertips but Pharo has serious issues with code organisation and I find the lack of namespaces quite inconvenient. You have to be careful how to name your classes which does not sound to me very OOP friendly. 

Also the IDE does not handle spaggetification very well, sure you can find implementors , senders etc but if the execution chain is complex , welcome to spaggeti hell. But that is a problem with most other IDEs if not all as well. Problem is in this case that we have the very good rule of using sort methods which multiplies this problem and makes navigation even harder. Code becomes much easier to read per method and messages but much harder to understand in a bird eye view.

Some of that pain has been aleviated with the introduction of GTSpotter which I have praised quite a lot and I will continue to do so. But yeah there are more needed to be done in the department to make Pharo code navigation a more comfortable task. 

On Wed, Oct 11, 2017 at 2:57 PM Vitor Medina Cruz <vitormcruz@gmail.com <mailto:vitormcruz@gmail.com>> wrote:

I dunno, maybe I’m weird, but I find the System Browser a fantastic way to explore the class library. If you find a class or method that isn’t well documented, write a comment and send a change request. Stef told me this ages ago. I might add, if you find a bug you should write a test that exercises the bug and submit it on fogbugz (the bug tracking system).

I will reference of response of mine to a similar opinion made by Richard: https://medium.com/@vitormcruz/i-disagree-it-is-much-harder-to-find-anything...

My 2 cents.

On Tue, Oct 10, 2017 at 11:59 PM, john pfersich <jpfersich@gmail.com <mailto:jpfersich@gmail.com>> wrote:

> On Oct 10, 2017, at 09:58, horrido <horrido.hobbies@gmail.com <mailto:horrido.hobbies@gmail.com>> wrote: > > Interestingly, I'm getting a fair amount of pushback on this. Personally, I > think it would be very helpful to have a live (updatable, so as to keep it > current) reference page for the class library, something that developers can > easily look up what they need. After all, most of the power of Pharo comes > from the class library and we need to make it as accessible as possible to > less experienced Pharoers (i.e., beginners). > > Exploring the class library through the System Browser is very inefficient. > This is further exacerbated by the fact that many classes and methods are > simply not well-documented (containing a cursory remark which is just barely > useful). > I dunno, maybe I’m weird, but I find the System Browser a fantastic way to explore the class library. If you find a class or method that isn’t well documented, write a comment and send a change request. Stef told me this ages ago. I might add, if you find a bug you should write a test that exercises the bug and submit it on fogbugz (the bug tracking system).

> I realize that creating a live reference page is not easy to do. In fact, > it's a lot of work. But the absence of such a page is a real obstacle to > Pharo acceptance. > > > > horrido wrote >> Thanks. I gave your answer verbatim. I also added the following paragraph: >> >> The problem I find with today’s developers is that they are rather >> closed-minded. They are rigid and inflexible, and not willing to adapt to >> new and different ways of doing things. In my generation (circa >> 1980–1990), >> people didn’t have a problem with trying different technologies. That’s >> why >> I had no issue with learning Smalltalk 10 years ago, after I had retired >> from a 20-year-long career in C systems programming and FORTRAN scientific >> programming. >> >> >> >> Sven Van Caekenberghe-2 wrote >>>> On 6 Oct 2017, at 14:54, horrido < >> >>> horrido.hobbies@ >> >>> > wrote: >>>> >>>> I received this comment from someone who complained: >>>> >>>> *What about the lack of documentation? From time to time I’ve checked >>>> some >>>> SmallTalk implementations like Squeak, GNU-Smalltalk and now Pharo. Of >>>> these, only GNU-SmallTalk appears to have a free, official programming >>>> guide >>>> and core library reference that any serious programmer expects from a >>>> language. >>>> >>>> https://www.gnu.org/software/smalltalk/manual-base/html_node/* >>>> >>>> I pointed to Pharo's documentation but then he came back with: >>>> >>>> *Then show me a link of the free, maintained reference documentation for >>>> the >>>> classes that form “the core library”, like this one for Python >>>> (https://docs.python.org/3/library/index.html)* <https://docs.python.org/3/library/index.html%29*> >>>> >>>> It's true, most Smalltalks do not have a core library reference, not >>>> even >>>> VisualWorks! So what is the proper response to this complaint? >>> >>> The first answer is that Pharo/Smalltalk is unique in that a running >>> system/IDE contains _all_ source code, _all_ documentation (class, >>> method, >>> help, tutorial), _all_ unit tests and _all_ runnable examples in a very >>> easy, accessible way. It takes some getting used to, but this is actually >>> better and much more powerful than any alternative. >>> >>> The second answer is that there are lots of books and articles that take >>> the classic/structured book/paper approach. There is >>> http://books.pharo.org, http://themoosebook.org, >>> http://book.seaside.st/book, http://medium.com/concerning-pharo and many >>> more. >>> >>>> Thanks. >>>> >>>> >>>> >>>> -- >>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>> >> >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Ah and my static website was built with Pillar and Bootstrap, using bootstrap templates was easy because Pillar supports mustache that makes html manipulation much easier http://www.kilon-alios.com Pillar of course is not made for generating websites but it’s an awesome Pharo library that allows for great degree of freedom so I thought , why not ? On Wed, 11 Oct 2017 at 17:48, Dimitris Chloupis <kilon.alios@gmail.com> wrote:

Docs are available in static online html format , at least the book I was working on

Pharo By Example

You can find those links here

https://github.com/SquareBracketAssociates/UpdatedPharoByExample

Our documentation system , Pillar , outputs pdf , html and markdown files.

If the book in question is built like PBE with CI of Inria where most Pharo related official projects are built then it should have at least pdf and html with online access so you can easily link to.

Don’t quote me on this but I think the html output of pillar generate links even for paragraphs you can do an even more process linking to the documentation. On Wed, 11 Oct 2017 at 17:40, Offray Vladimir Luna Cárdenas < offray.luna@mutabit.com> wrote:

...

The more I use Pharo, the less I use web documentation. For me seems pretty suboptimal compared to live environment with code browser and GT-Spotter. Regarding the comment on Medium, it also took me little to find #raisedTo:, so the millage can vary. What I was missing was proper books for particular domains, but Pharo books are covering that. I don't know if a Q&A site could improve search-ability for newbies (certainly you can find little stuff in Stack Overflow).

My bet is about trying to create more "end user" tools (Grafoscopio is kind of this), besides tools for developers. There is a broad community of people who can be active contributors and members of the community, welcome Pharo and live coding a lot and don't complain that much about stuff that is not already pretty similar to what they already know (being that only English MOOC or online static html docs).

Cheers,

Offray

On 11/10/17 07:34, Dimitris Chloupis wrote:

for me it is a yes and no situation, yes its very coold to have your entire system in your fingertips but Pharo has serious issues with code organisation and I find the lack of namespaces quite inconvenient. You have to be careful how to name your classes which does not sound to me very OOP friendly.

Also the IDE does not handle spaggetification very well, sure you can find implementors , senders etc but if the execution chain is complex , welcome to spaggeti hell. But that is a problem with most other IDEs if not all as well. Problem is in this case that we have the very good rule of using sort methods which multiplies this problem and makes navigation even harder. Code becomes much easier to read per method and messages but much harder to understand in a bird eye view.

Some of that pain has been aleviated with the introduction of GTSpotter which I have praised quite a lot and I will continue to do so. But yeah there are more needed to be done in the department to make Pharo code navigation a more comfortable task.

On Wed, Oct 11, 2017 at 2:57 PM Vitor Medina Cruz <vitormcruz@gmail.com> wrote:

...

I dunno, maybe I’m weird, but I find the System Browser a fantastic way to explore the class library. If you find a class or method that isn’t well documented, write a comment and send a change request. Stef told me this ages ago. I might add, if you find a bug you should write a test that exercises the bug and submit it on fogbugz (the bug tracking system).

I will reference of response of mine to a similar opinion made by Richard: https://medium.com/@vitormcruz/i-disagree-it-is-much-harder-to-find-anything...

My 2 cents.

On Tue, Oct 10, 2017 at 11:59 PM, john pfersich <jpfersich@gmail.com> wrote:

...

...

On Oct 10, 2017, at 09:58, horrido <horrido.hobbies@gmail.com> wrote:

Interestingly, I'm getting a fair amount of pushback on this. Personally, I think it would be very helpful to have a live (updatable, so as to keep it current) reference page for the class library, something that developers can easily look up what they need. After all, most of the power of Pharo comes from the class library and we need to make it as accessible as possible to less experienced Pharoers (i.e., beginners).

Exploring the class library through the System Browser is very inefficient. This is further exacerbated by the fact that many classes and methods are simply not well-documented (containing a cursory remark which is just barely useful).

I dunno, maybe I’m weird, but I find the System Browser a fantastic way to explore the class library. If you find a class or method that isn’t well documented, write a comment and send a change request. Stef told me this ages ago. I might add, if you find a bug you should write a test that exercises the bug and submit it on fogbugz (the bug tracking system).

...

I realize that creating a live reference page is not easy to do. In fact, it's a lot of work. But the absence of such a page is a real obstacle to Pharo acceptance.

horrido wrote

...

Thanks. I gave your answer verbatim. I also added the following paragraph:

The problem I find with today’s developers is that they are rather closed-minded. They are rigid and inflexible, and not willing to adapt to new and different ways of doing things. In my generation (circa 1980–1990), people didn’t have a problem with trying different technologies. That’s why I had no issue with learning Smalltalk 10 years ago, after I had retired from a 20-year-long career in C systems programming and FORTRAN scientific programming.

Sven Van Caekenberghe-2 wrote

...

...

On 6 Oct 2017, at 14:54, horrido <

...

horrido.hobbies@

...

> wrote:

...

I received this comment from someone who complained:

*What about the lack of documentation? From time to time I’ve

checked

...

some SmallTalk implementations like Squeak, GNU-Smalltalk and now Pharo. Of these, only GNU-SmallTalk appears to have a free, official programming guide and core library reference that any serious programmer expects from a language.

https://www.gnu.org/software/smalltalk/manual-base/html_node/*

I pointed to Pharo's documentation but then he came back with:

*Then show me a link of the free, maintained reference documentation for the classes that form “the core library”, like this one for Python (https://docs.python.org/3/library/index.html)*

It's true, most Smalltalks do not have a core library reference, not even VisualWorks! So what is the proper response to this complaint?

The first answer is that Pharo/Smalltalk is unique in that a running system/IDE contains _all_ source code, _all_ documentation (class, method, help, tutorial), _all_ unit tests and _all_ runnable examples in a very easy, accessible way. It takes some getting used to, but this is actually better and much more powerful than any alternative.

The second answer is that there are lots of books and articles that take the classic/structured book/paper approach. There is http://books.pharo.org, http://themoosebook.org, http://book.seaside.st/book, http://medium.com/concerning-pharo and many more.

...

Thanks.

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

What about a seaside-based system browser oriented towards code documentation? That would fit both paradigms: html-like reference + live browsing. You could even make it buzzword compliant: have a REST interface to documentation and code. Note how the panes in a system browser could make for a nice URI: just look for pharo://Kernel/Number/mathematical%20functions/raisedTo: And we could even include version numbers, etc.... pharo://6.1/Kernel/Number/mathematical%20functions/raisedTo: Not very different from the github url for the pharo project relevant file... https://github.com/pharo-project/pharo/blob/development/src/Kernel.package/N... Thierry 2017-10-11 17:01 GMT+02:00 Offray Vladimir Luna Cárdenas < offray.luna@mutabit.com>:

Yes. I know them. I mean API docs as static files. I don't really sold on them compared with a live system and I don't think static API docs are critical for Pharo success.

Cheers,

Offray

On 11/10/17 09:52, Dimitris Chloupis wrote:

Ah and my static website was built with Pillar and Bootstrap, using bootstrap templates was easy because Pillar supports mustache that makes html manipulation much easier

http://www.kilon-alios.com

Pillar of course is not made for generating websites but it’s an awesome Pharo library that allows for great degree of freedom so I thought , why not ? On Wed, 11 Oct 2017 at 17:48, Dimitris Chloupis <kilon.alios@gmail.com> wrote:

...

Docs are available in static online html format , at least the book I was working on

Pharo By Example

You can find those links here

https://github.com/SquareBracketAssociates/UpdatedPharoByExample

Our documentation system , Pillar , outputs pdf , html and markdown files.

If the book in question is built like PBE with CI of Inria where most Pharo related official projects are built then it should have at least pdf and html with online access so you can easily link to.

Don’t quote me on this but I think the html output of pillar generate links even for paragraphs you can do an even more process linking to the documentation. On Wed, 11 Oct 2017 at 17:40, Offray Vladimir Luna Cárdenas < offray.luna@mutabit.com> wrote:

...

The more I use Pharo, the less I use web documentation. For me seems pretty suboptimal compared to live environment with code browser and GT-Spotter. Regarding the comment on Medium, it also took me little to find #raisedTo:, so the millage can vary. What I was missing was proper books for particular domains, but Pharo books are covering that. I don't know if a Q&A site could improve search-ability for newbies (certainly you can find little stuff in Stack Overflow).

My bet is about trying to create more "end user" tools (Grafoscopio is kind of this), besides tools for developers. There is a broad community of people who can be active contributors and members of the community, welcome Pharo and live coding a lot and don't complain that much about stuff that is not already pretty similar to what they already know (being that only English MOOC or online static html docs).

Cheers,

Offray

On 11/10/17 07:34, Dimitris Chloupis wrote:

for me it is a yes and no situation, yes its very coold to have your entire system in your fingertips but Pharo has serious issues with code organisation and I find the lack of namespaces quite inconvenient. You have to be careful how to name your classes which does not sound to me very OOP friendly.

Also the IDE does not handle spaggetification very well, sure you can find implementors , senders etc but if the execution chain is complex , welcome to spaggeti hell. But that is a problem with most other IDEs if not all as well. Problem is in this case that we have the very good rule of using sort methods which multiplies this problem and makes navigation even harder. Code becomes much easier to read per method and messages but much harder to understand in a bird eye view.

Some of that pain has been aleviated with the introduction of GTSpotter which I have praised quite a lot and I will continue to do so. But yeah there are more needed to be done in the department to make Pharo code navigation a more comfortable task.

On Wed, Oct 11, 2017 at 2:57 PM Vitor Medina Cruz <vitormcruz@gmail.com> wrote:

...

I dunno, maybe I’m weird, but I find the System Browser a fantastic way to explore the class library. If you find a class or method that isn’t well documented, write a comment and send a change request. Stef told me this ages ago. I might add, if you find a bug you should write a test that exercises the bug and submit it on fogbugz (the bug tracking system).

I will reference of response of mine to a similar opinion made by Richard: https://medium.com/@vitormcruz/i-disagree-it-is- much-harder-to-find-anything-in-the-environment-c6bdd44f6eea

My 2 cents.

On Tue, Oct 10, 2017 at 11:59 PM, john pfersich <jpfersich@gmail.com> wrote:

...

...

On Oct 10, 2017, at 09:58, horrido <horrido.hobbies@gmail.com> wrote:

Interestingly, I'm getting a fair amount of pushback on this. Personally, I think it would be very helpful to have a live (updatable, so as to keep it current) reference page for the class library, something that developers can easily look up what they need. After all, most of the power of Pharo comes from the class library and we need to make it as accessible as possible to less experienced Pharoers (i.e., beginners).

Exploring the class library through the System Browser is very inefficient. This is further exacerbated by the fact that many classes and methods are simply not well-documented (containing a cursory remark which is just barely useful).

I dunno, maybe I’m weird, but I find the System Browser a fantastic way to explore the class library. If you find a class or method that isn’t well documented, write a comment and send a change request. Stef told me this ages ago. I might add, if you find a bug you should write a test that exercises the bug and submit it on fogbugz (the bug tracking system).

...

I realize that creating a live reference page is not easy to do. In fact, it's a lot of work. But the absence of such a page is a real obstacle to Pharo acceptance.

horrido wrote

...

Thanks. I gave your answer verbatim. I also added the following paragraph:

The problem I find with today’s developers is that they are rather closed-minded. They are rigid and inflexible, and not willing to adapt to new and different ways of doing things. In my generation (circa 1980–1990), people didn’t have a problem with trying different technologies. That’s why I had no issue with learning Smalltalk 10 years ago, after I had retired from a 20-year-long career in C systems programming and FORTRAN scientific programming.

Sven Van Caekenberghe-2 wrote

...

...

On 6 Oct 2017, at 14:54, horrido <

...

horrido.hobbies@

...

> wrote:

...

I received this comment from someone who complained:

*What about the lack of documentation? From time to time I’ve

checked

...

some SmallTalk implementations like Squeak, GNU-Smalltalk and now Pharo. Of these, only GNU-SmallTalk appears to have a free, official programming guide and core library reference that any serious programmer expects from a language.

https://www.gnu.org/software/smalltalk/manual-base/html_node/*

I pointed to Pharo's documentation but then he came back with:

*Then show me a link of the free, maintained reference documentation for the classes that form “the core library”, like this one for Python (https://docs.python.org/3/library/index.html)*

It's true, most Smalltalks do not have a core library reference, not even VisualWorks! So what is the proper response to this complaint?

The first answer is that Pharo/Smalltalk is unique in that a running system/IDE contains _all_ source code, _all_ documentation (class, method, help, tutorial), _all_ unit tests and _all_ runnable examples in a very easy, accessible way. It takes some getting used to, but this is actually better and much more powerful than any alternative.

The second answer is that there are lots of books and articles that take the classic/structured book/paper approach. There is http://books.pharo.org, http://themoosebook.org, http://book.seaside.st/book, http://medium.com/concerning-pharo and many more.

...

Thanks.

-- Sent from: http://forum.world.st/Pharo- Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo- Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

On 11 Oct 2017, at 17:18, Thierry Goubier <thierry.goubier@gmail.com> wrote:

What about a seaside-based system browser oriented towards code documentation? That would fit both paradigms: html-like reference + live browsing.

You could even make it buzzword compliant: have a REST interface to documentation and code.

Note how the panes in a system browser could make for a nice URI: just look for

pharo://Kernel/Number/mathematical%20functions/raisedTo:

And we could even include version numbers, etc....

pharo://6.1/Kernel/Number/mathematical%20functions/raisedTo:

Not very different from the github url for the pharo project relevant file...

https://github.com/pharo-project/pharo/blob/development/src/Kernel.package/N... <https://github.com/pharo-project/pharo/blob/development/src/Kernel.package/N...>

There is http://files.pharo.org/doc/ <http://files.pharo.org/doc/>, too. Marcus

Well there is a move towards Pillar for class and method commands so who knows maybe we will have that soon enough ;) There is a solution, not a great solution but it can do this. You can kinda do this via metacello and filetree, because when you export to git , it coverts class and method comments to markdown that can be viewed like online documentation . They are saved as README.md which is the standard for github. That means you can use markdown inside the class and method comments , and then convert that to HTML . Tons of markdown to html coverters out there so it would not be a problem. Of course Pharo users may not be happy to read comments in markdown but then markdown has minimal syntax so it should not be such a major issue. The real problem is the class comments itself, if you lack comments talking about automated API reference documentation sounds the least of the problems. Cannot blame developers, documentation is as much work as writting the code and I can understand that some may find it much less pleasant than I do :) I tried my best to help on the documentation department but we need more people because its an effort not only to document but also to keep the documentation updated. One of the perk working in an enviroment improving very fast, but you wont get any complain from me about this ;) On Wed, Oct 11, 2017 at 6:02 PM Offray Vladimir Luna Cárdenas < offray.luna@mutabit.com> wrote:

Yes. I know them. I mean API docs as static files. I don't really sold on them compared with a live system and I don't think static API docs are critical for Pharo success.

Cheers,

Offray

On 11/10/17 09:52, Dimitris Chloupis wrote:

Ah and my static website was built with Pillar and Bootstrap, using bootstrap templates was easy because Pillar supports mustache that makes html manipulation much easier

http://www.kilon-alios.com

Pillar of course is not made for generating websites but it’s an awesome Pharo library that allows for great degree of freedom so I thought , why not ? On Wed, 11 Oct 2017 at 17:48, Dimitris Chloupis <kilon.alios@gmail.com> wrote:

...

Docs are available in static online html format , at least the book I was working on

Pharo By Example

You can find those links here

https://github.com/SquareBracketAssociates/UpdatedPharoByExample

Our documentation system , Pillar , outputs pdf , html and markdown files.

If the book in question is built like PBE with CI of Inria where most Pharo related official projects are built then it should have at least pdf and html with online access so you can easily link to.

Don’t quote me on this but I think the html output of pillar generate links even for paragraphs you can do an even more process linking to the documentation. On Wed, 11 Oct 2017 at 17:40, Offray Vladimir Luna Cárdenas < offray.luna@mutabit.com> wrote:

...

The more I use Pharo, the less I use web documentation. For me seems pretty suboptimal compared to live environment with code browser and GT-Spotter. Regarding the comment on Medium, it also took me little to find #raisedTo:, so the millage can vary. What I was missing was proper books for particular domains, but Pharo books are covering that. I don't know if a Q&A site could improve search-ability for newbies (certainly you can find little stuff in Stack Overflow).

My bet is about trying to create more "end user" tools (Grafoscopio is kind of this), besides tools for developers. There is a broad community of people who can be active contributors and members of the community, welcome Pharo and live coding a lot and don't complain that much about stuff that is not already pretty similar to what they already know (being that only English MOOC or online static html docs).

Cheers,

Offray

On 11/10/17 07:34, Dimitris Chloupis wrote:

for me it is a yes and no situation, yes its very coold to have your entire system in your fingertips but Pharo has serious issues with code organisation and I find the lack of namespaces quite inconvenient. You have to be careful how to name your classes which does not sound to me very OOP friendly.

Also the IDE does not handle spaggetification very well, sure you can find implementors , senders etc but if the execution chain is complex , welcome to spaggeti hell. But that is a problem with most other IDEs if not all as well. Problem is in this case that we have the very good rule of using sort methods which multiplies this problem and makes navigation even harder. Code becomes much easier to read per method and messages but much harder to understand in a bird eye view.

Some of that pain has been aleviated with the introduction of GTSpotter which I have praised quite a lot and I will continue to do so. But yeah there are more needed to be done in the department to make Pharo code navigation a more comfortable task.

On Wed, Oct 11, 2017 at 2:57 PM Vitor Medina Cruz <vitormcruz@gmail.com> wrote:

...

I dunno, maybe I’m weird, but I find the System Browser a fantastic way to explore the class library. If you find a class or method that isn’t well documented, write a comment and send a change request. Stef told me this ages ago. I might add, if you find a bug you should write a test that exercises the bug and submit it on fogbugz (the bug tracking system).

I will reference of response of mine to a similar opinion made by Richard: https://medium.com/@vitormcruz/i-disagree-it-is-much-harder-to-find-anything...

My 2 cents.

On Tue, Oct 10, 2017 at 11:59 PM, john pfersich <jpfersich@gmail.com> wrote:

...

...

On Oct 10, 2017, at 09:58, horrido <horrido.hobbies@gmail.com> wrote:

Interestingly, I'm getting a fair amount of pushback on this. Personally, I think it would be very helpful to have a live (updatable, so as to keep it current) reference page for the class library, something that developers can easily look up what they need. After all, most of the power of Pharo comes from the class library and we need to make it as accessible as possible to less experienced Pharoers (i.e., beginners).

Exploring the class library through the System Browser is very inefficient. This is further exacerbated by the fact that many classes and methods are simply not well-documented (containing a cursory remark which is just barely useful).

I dunno, maybe I’m weird, but I find the System Browser a fantastic way to explore the class library. If you find a class or method that isn’t well documented, write a comment and send a change request. Stef told me this ages ago. I might add, if you find a bug you should write a test that exercises the bug and submit it on fogbugz (the bug tracking system).

...

I realize that creating a live reference page is not easy to do. In fact, it's a lot of work. But the absence of such a page is a real obstacle to Pharo acceptance.

horrido wrote

...

Thanks. I gave your answer verbatim. I also added the following paragraph:

The problem I find with today’s developers is that they are rather closed-minded. They are rigid and inflexible, and not willing to adapt to new and different ways of doing things. In my generation (circa 1980–1990), people didn’t have a problem with trying different technologies. That’s why I had no issue with learning Smalltalk 10 years ago, after I had retired from a 20-year-long career in C systems programming and FORTRAN scientific programming.

Sven Van Caekenberghe-2 wrote

...

...

On 6 Oct 2017, at 14:54, horrido <

...

horrido.hobbies@

...

> wrote:

...

I received this comment from someone who complained:

*What about the lack of documentation? From time to time I’ve

checked

...

some SmallTalk implementations like Squeak, GNU-Smalltalk and now Pharo. Of these, only GNU-SmallTalk appears to have a free, official programming guide and core library reference that any serious programmer expects from a language.

https://www.gnu.org/software/smalltalk/manual-base/html_node/*

I pointed to Pharo's documentation but then he came back with:

*Then show me a link of the free, maintained reference documentation for the classes that form “the core library”, like this one for Python (https://docs.python.org/3/library/index.html)*

It's true, most Smalltalks do not have a core library reference, not even VisualWorks! So what is the proper response to this complaint?

The first answer is that Pharo/Smalltalk is unique in that a running system/IDE contains _all_ source code, _all_ documentation (class, method, help, tutorial), _all_ unit tests and _all_ runnable examples in a very easy, accessible way. It takes some getting used to, but this is actually better and much more powerful than any alternative.

The second answer is that there are lots of books and articles that take the classic/structured book/paper approach. There is http://books.pharo.org, http://themoosebook.org, http://book.seaside.st/book, http://medium.com/concerning-pharo and many more.

...

Thanks.

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

On ven. 13 oct. 2017 at 12:05, Gour <gour@atmarama.com> wrote:

On Wed, 11 Oct 2017 17:18:54 +0000 Dimitris Chloupis <kilon.alios@gmail.com> wrote:

...

Well there is a move towards Pillar for class and method commands so who knows maybe we will have that soon enough ;)

Let me say that I'm very happy seeing that Pillar is moving forward (e.g. addition of support for footnotes) as well as plan for the future (*.epub support) since I'm considering whether it could serve as single-source markup for all of one's writings?

After migrating from Python-powered static-site-generator (to Hugo) and rst markup I was considering to use AsciiDoc(tor) markup for all my content, but, so far, due to using Emacsm settled to use org-mode instead. Haven't tried with slides (yet), but there is Pandoc support for it.

Therefore, I'd rather see Pillar support in Pandoc which would buy us even more import/export capabilities for free instead of focusing on single formats like *.odt, *.epub etc.

Pillar with 1st class support in Pandoc would, imho, improve status of Pharo itself making it along with Pillar exceelent tool for development as well as for all writing needs - articles, books, documentation, slide-presentations.

But it would be nice to make it more transparent where/how can one submit feature request for Pillar?

Hi, I don't have much time so, fast answer: https://github.com/pillar-markup/pillar/issues

Fogbugs issue trakcer is certainly not the ideal place these days...

Sincerely, Gour

-- Everyone is forced to act helplessly according to the qualities he has acquired from the modes of material nature; therefore no one can refrain from doing something, not even for a moment.

--

Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France

On Fri, 13 Oct 2017 10:43:27 +0000 Dimitris Chloupis <kilon.alios@gmail.com> wrote:

Why exporting to latex, html and markdown is not enough for you ?

Well, I usuallyconsider latex/html as more suitable as output formats, while standard markdown is semantically too poor for input format, but I'll test how Pillar's outputs are suitable as Pandoc's inputs. Sincerely, Gour -- It is far better to discharge one's prescribed duties, even though faultily, than another's duties perfectly. Destruction in the course of performing one's own duty is better than engaging in another's duties, for to follow another's path is dangerous.

Hi, I have created a document in Grafoscopio. The source file is a single Grafoscopio notebook in STON [1] (~600kb), the output is a single Pandoc's Markdown file[2] (~500kb), and you can produce the output as a PDF file like in [3] (~13Mb). Pandoc has a lot of maturity and a community with a lot of momentum, dedicated mainly to light documentation. If we have support for Pandoc's Markdown on Pharo, we can leverage on that knowledge and tools without reinventing the wheel. Of course using AST and a lot of infrastructure behind Pillar can be used, without falling in love with its syntax. [1] http://mutabit.com/repos.fossil/mapeda/doc/tip/mapeda.ston [2] http://mutabit.com/repos.fossil/mapeda/doc/tip/mapeda.markdown [3] http://mutabit.com/repos.fossil/mapeda/uv/mapeda.pdf Cheers, Offray On 13/10/17 08:21, H. Hirzel wrote:

Interoperability with pandoc is desirable

Some people want MSWord documents and they provide input in the form of MSWord documents. Or LibreOffice ODT.

pandoc handles that well for a subset of MSWord options.

pandoc allows you as well to write a custom output format -- in this case Pillar.

E.g. conversion from MSWord docx to Pillar is possible.

It would need somebody to look into the issue of doing some Lua scripting. pandoc has Lua embedded for output generation.

--Hannes

P.S. I will have some time later for Pillar issues (not Lua), but the document model and generation of slides. Still open issue on my list is rendering Pillar on Morphic, in particular slide.

On 10/13/17, Dimitris Chloupis <kilon.alios@gmail.com> wrote:

...

Why exporting to latex, html and markdown is not enough for you ?

On Fri, Oct 13, 2017 at 1:05 PM Gour <gour@atmarama.com> wrote:

...

On Wed, 11 Oct 2017 17:18:54 +0000 Dimitris Chloupis <kilon.alios@gmail.com> wrote:

...

Well there is a move towards Pillar for class and method commands so who knows maybe we will have that soon enough ;) Let me say that I'm very happy seeing that Pillar is moving forward (e.g. addition of support for footnotes) as well as plan for the future (*.epub support) since I'm considering whether it could serve as single-source markup for all of one's writings?

After migrating from Python-powered static-site-generator (to Hugo) and rst markup I was considering to use AsciiDoc(tor) markup for all my content, but, so far, due to using Emacsm settled to use org-mode instead. Haven't tried with slides (yet), but there is Pandoc support for it.

Therefore, I'd rather see Pillar support in Pandoc which would buy us even more import/export capabilities for free instead of focusing on single formats like *.odt, *.epub etc.

Pillar with 1st class support in Pandoc would, imho, improve status of Pharo itself making it along with Pillar exceelent tool for development as well as for all writing needs - articles, books, documentation, slide-presentations.

But it would be nice to make it more transparent where/how can one submit feature request for Pillar?

Fogbugs issue trakcer is certainly not the ideal place these days...

Sincerely, Gour

-- Everyone is forced to act helplessly according to the qualities he has acquired from the modes of material nature; therefore no one can refrain from doing something, not even for a moment.

I can't remember ever using API docs in any language, dynamic or not.  They give you the method signatures, but if you have, say, methodX(int, int, String), how are you supposed to guess what ints and what String the method actually needs, unless the methods are nothing but getters and setters (which I've never understood the point of) ?  (I know, most give (int somename, int someothername, String whatever), but how often do are method names well thought through enough to imply definitively what the method needs?.   It's my biggest issue with Algol-style syntax - the method caller is supposed to know how it works, rather than whoever actually wrote it.  It's probably at least one of the reasons for the amount of OSS in Java, and more recently in JavaScript (though the latter is more no- style than Algol-style).  I nearly always download the source to OSS libs although I rarely ever bother building it, so I know what a method does with the params, and I can be sure what params to give it. One of my favourite language fails can be reproduced by doing this:  Declare a field private final in Java, initializing it either in the declaration or the constructor, and provide only a getter.  Use the getter from another class and change the value of the local variable. Then use the getter again, but assign the value to a new local variable, and check the value.   Guess what? The value is whatever you changed it to in your other local variable, although the API docs claim javac won't compile it. I tested this with Java 8,  I haven't bothered to see if it was always like that or if they took the rule out of javac because it interfered with some syntactic parmesan, such as lambdas.  I should copy my test code into VisualAge for Java and see if in fact it compiles with JDK 1.4.2, or if javac was changed in between 4 and 8, since the addition of various flavours of syntactic parmesan mostly started with Java 5. Not that it's all that important in one sense.  If 'private' and 'final' were supposed to be guides for other developers to be careful if they're thinking about changing it, fine, anyone who doesn't isn't all that good a developer.  But given the number of 'not very good' developers I've had the misfortune to work with in Java, it's more problematic than it should be.  It also makes the pattern of a private field with a public setter even more useless, since the setter isn't needed to change the value.  I always get dinged by whatever lint companies use for not bothering with that pattern, though, and pointing out that declaring the fields public accomplishes exactly the same thing never helps my case, because whatever lint they use, it has to be right, there's no way a non-lint developer might be right. Andrew Glynn -----Original Message----- Date: Wed, 11 Oct 2017 10:01:20 -0500Subject: Re: [Pharo-users] Behold Pharo: The Modern SmalltalkTo: pharo-users@lists.pharo.orgReply-to: Any question about pharo is welcome <pharo-users@lists.pharo.org>From: Offray Vladimir Luna Cárdenas <offray.luna@mutabit.com>                   Yes. I know them. I mean API docs as static files. I don't really       sold on them compared with a live system and I don't think static       API docs are critical for Pharo success.     Cheers,     Offray               On 11/10/17 09:52, Dimitris Chloupis       wrote:          

Ah       and my static website was built with Pillar and Bootstrap, using       bootstrap templates was easy because Pillar supports mustache that       makes html manipulation much easier 

      

      http://www.kilon-alios.com

      

      Pillar of course is not made for generating websites but it’s an       awesome Pharo library that allows for great degree of freedom so I       thought , why not ?

               On Wed, 11 Oct 2017 at 17:48, Dimitris Chloupis           <kilon.alios@gmail.com> wrote:

                 

...

Docs are           available in static online html format , at least the book I           was working on 

          

          Pharo By Example 

          

          You can find those links here

          

          https://github.com/SquareBracketAssociates/UpdatedPharoBy Example

          

          Our documentation system , Pillar , outputs pdf , html and           markdown files. 

          

          If the book in question is built like PBE with CI of Inria           where most Pharo related official projects are built then it           should have at least pdf and html with online access so you           can easily link to.

          

          Don’t quote me on this but I think the html output of pillar           generate links even for paragraphs you can do an even more           process linking to the documentation. 

                       On Wed, 11 Oct 2017 at 17:40, Offray Vladimir               Luna Cárdenas <offray.luna@mutabit.com>               wrote:

                         

...

                               The more I use Pharo, the less I use web                   documentation. For me seems pretty suboptimal compared                   to live environment with code browser and GT- Spotter.                   Regarding the comment on Medium, it also took me                   little to find #raisedTo:, so the millage can vary.                   What I was missing was proper books for particular                   domains, but Pharo books are covering that. I don't                   know if a Q&A site could improve search-ability                   for newbies (certainly you can find little stuff in                   Stack Overflow).                 My bet is about trying to create more "end user"                   tools (Grafoscopio is kind of this), besides tools for                   developers. There is a broad community of people who                   can be active contributors and members of the                   community, welcome Pharo and live coding a lot and                   don't complain that much about stuff that is not                   already pretty similar to what they already know                   (being that only English MOOC or online static html                   docs).                 Cheers,                 Offray

                                               

                On                   11/10/17 07:34, Dimitris Chloupis wrote:

                                 

...

                  for me it is a yes and no situation,                     yes its very coold to have your entire system in                     your fingertips but Pharo has serious issues with                     code organisation and I find the lack of namespaces                     quite inconvenient. You have to be careful how to                     name your classes which does not sound to me very                     OOP friendly.                      

                                         Also the IDE does not handle spaggetification                       very well, sure you can find implementors ,                       senders etc but if the execution chain is complex                       , welcome to spaggeti hell. But that is a problem                       with most other IDEs if not all as well. Problem                       is in this case that we have the very good rule of                       using sort methods which multiplies this problem                       and makes navigation even harder. Code becomes                       much easier to read per method and messages but                       much harder to understand in a bird eye view.                     

                                         Some of that pain has been aleviated with the                       introduction of GTSpotter which I have praised                       quite a lot and I will continue to do so. But yeah                       there are more needed to be done in the department                       to make Pharo code navigation a more comfortable                       task.                                       

                                       On Wed, Oct 11, 2017 at 2:57 PM Vitor                       Medina Cruz <vitormcruz@gmail.com>                       wrote:

                                         

...

                                                                          I dunno, maybe I’m weird, but I find                           the System Browser a fantastic way to explore                           the class library. If you find a class or                           method that isn’t well documented, write a                           comment and send a change request. Stef told                           me this ages ago. I might add, if you find a                           bug you should write a test that exercises the                           bug and submit it on fogbugz (the bug tracking                           system).

                                                 

                                                                      I will reference of response of                           mine to a similar opinion made by Richard: https://medium.com/@vitormcruz/i-disagree-it-is-much -harder-to-find-anything-in-the-environment-c6bdd44f6eea                         My 2 cents.                         

                                                 

                                             

                        On Tue, Oct 10, 2017 at                           11:59 PM, john pfersich <jpfersich@ gmail.com>                           wrote:

                          

...

                              > On Oct 10, 2017, at 09:58, horrido                               <horrido.hobbies@gmail.com>                               wrote:

                              >

                              > Interestingly, I'm getting a fair                               amount of pushback on this. Personally, I

                              > think it would be very helpful to                               have a live (updatable, so as to keep it

                              > current) reference page for the class                               library, something that developers can

                              > easily look up what they need. After                               all, most of the power of Pharo comes

                              > from the class library and we need to                               make it as accessible as possible to

                              > less experienced Pharoers (i.e.,                               beginners).

                              >

                              > Exploring the class library through                               the System Browser is very inefficient.

                              > This is further exacerbated by the                               fact that many classes and methods are

                              > simply not well-documented                               (containing a cursory remark which is just                               barely

                              > useful).

                              >

                            I dunno, maybe I’m weird, but I find                             the System Browser a fantastic way to                             explore the class library. If you find a                             class or method that isn’t well documented,                             write a comment and send a change request.                             Stef told me this ages ago. I might add, if                             you find a bug you should write a test that                             exercises the bug and submit it on fogbugz                             (the bug tracking system).

                                                           

                                > I realize that creating a live                                 reference page is not easy to do. In                                 fact,

                                > it's a lot of work. But the absence                                 of such a page is a real obstacle to

                                > Pharo acceptance.

                                >

                                >

                                >

                                > horrido wrote

                                >> Thanks. I gave your answer                                 verbatim. I also added the following                                 paragraph:

                                >>

                                >> The problem I find with today’s                                 developers is that they are rather

                                >> closed-minded. They are rigid                                 and inflexible, and not willing to adapt                                 to

                                >> new and different ways of doing                                 things. In my generation (circa

                                >> 1980–1990),

                                >> people didn’t have a problem                                 with trying different technologies.                                 That’s

                                >> why

                                >> I had no issue with learning                                 Smalltalk 10 years ago, after I had                                 retired

                                >> from a 20-year-long career in C                                 systems programming and FORTRAN                                 scientific

                                >> programming.

                                >>

                                >>

                                >>

                                >> Sven Van Caekenberghe-2 wrote

                                >>>> On 6 Oct 2017, at                                 14:54, horrido <

                                >>

                                >>> horrido.hobbies@

                                >>

                                >>> > wrote:

                                >>>>

                                >>>> I received this comment                                 from someone who complained:

                                >>>>

                                >>>> *What about the lack of                                 documentation? From time to time I’ve                                 checked

                                >>>> some

                                >>>> SmallTalk                                 implementations like Squeak,                                 GNU-Smalltalk and now Pharo. Of

                                >>>> these, only                                 GNU-SmallTalk appears to have a free,                                 official programming

                                >>>> guide

                                >>>> and core library                                 reference that any serious programmer                                 expects from a

                                >>>> language.

                                >>>>

                                >>>> https://www.gnu.org/so ftware/smalltalk/manual-base/html_node/*

                                >>>>

                                >>>> I pointed to Pharo's                                 documentation but then he came back                                 with:

                                >>>>

                                >>>> *Then show me a link of                                 the free, maintained reference                                 documentation for

                                >>>> the

                                >>>> classes that form “the                                 core library”, like this one for Python

                                >>>> (https://docs.python.o rg/3/library/index.html)*

                                >>>>

                                >>>> It's true, most                                 Smalltalks do not have a core library                                 reference, not

                                >>>> even

                                >>>> VisualWorks! So what is                                 the proper response to this complaint?

                                >>>

                                >>> The first answer is that                                 Pharo/Smalltalk is unique in that a                                 running

                                >>> system/IDE contains _all_                                 source code, _all_ documentation (class,

                                >>> method,

                                >>> help, tutorial), _all_ unit                                 tests and _all_ runnable examples in a                                 very

                                >>> easy, accessible way. It                                 takes some getting used to, but this is                                 actually

                                >>> better and much more                                 powerful than any alternative.

                                >>>

                                >>> The second answer is that                                 there are lots of books and articles                                 that take

                                >>> the classic/structured                                 book/paper approach. There is

                                >>> http://books.pharo.org,                                 http://themoosebook.org,

                                >>> http://book.seaside.st/ book,                                 http://medium.com/concernin g-pharo                                 and many

                                >>> more.

                                >>>

                                >>>> Thanks.

                                >>>>

                                >>>>

                                >>>>

                                >>>> --

                                >>>> Sent from: http://foru m.world.st/Pharo-Smalltalk-Users-f1310670.html

                                >>>>

                                >>

                                >>

                                >>

                                >>

                                >>

                                >> --

                                >> Sent from: http://forum. world.st/Pharo-Smalltalk-Users-f1310670.html

                                >

                                >

                                >

                                >

                                >

                                > --

                                > Sent from: http://forum.w orld.st/Pharo-Smalltalk-Users-f1310670.html

                                >

                                

                                                                                      

                                                 

                                           

                                   

                

                           

                   

           

       

I understand why it occurs, both the private and the final keyword affect the reference rather than the object. However, to quote someone else "That the value of a private field can be changed without a public setter implies that encapsulation is weak at best, and shouldn't be counted on to protect key values, even in combination with the final keyword."  Even that comment, though, brings in the notion of a 'value' that's not an object. My point initially was not about the code, but about the Java API doc that also claims attempting to change the value will result in a compile error. Although keywords affect references, the documentation states that it affects 'the value', which is at best ambiguous. There's inevitably a conflation of passing by value and passing by reference in Java by former C/C++ programmers, since it looks like PBV to a C/C++ programmer while always in fact being PBR.  When copying syntax inverting the meaning of the syntax is counterproductive.  There are also numerous issues around type erasure (mainly that it works for collections, even simple collections such as vectors, but not for arrays) and the resulting need for Java to allow invalid type casts in certain cases even though they can result in uncaught runtime exceptions. Since the fact that they are invalid is explicit in the API doc, that they are allowed because there's no other way to do it is problematic. Using lambdas or the streaming API within Java EE is another undocumented problem, or set of problems ( it was good fortune for me personally - when some software using the streaming API in an EE container consistently failed and the developer had no idea why, the company gave me the project I implemented it in Pharo, ☺ ).  Oracle did at one point have a note on the Java EE 7 download page to the effect that Java EE 7 shouldn't be used with Java SE 8, but that was 'disappeared' when Java SE 7 was no longer supported and Java EE 7 was still the latest version.  Since Java EE 8 is not even on the horizon, while SE 9 is due 'any minute now', I have to wonder if EE is simply dead.  The requests from IBM, SAP and others to take over EE imply they at least suspect the same. I'd rather have no API documentation than documentation of the sort represented by the Java API doc.  Not that I think it's all intentional, though perhaps the primitives and scalars that are in fact objects and collections may have been to muffle wailing from C/C++ programmers that the lack of primitives and scalars would kill performance.  I suspect it's more often a result of unsuccessfully mode-switching, though, between the rules of the language you're implementing and those of the language you're implementing in, but that only makes the case for languages implemented in themselves stronger. Andrew -----Original Message----- Date: Fri, 13 Oct 2017 18:39:59 +0200 Subject: Re: [Pharo-users] Behold Pharo: The Modern Smalltalk To: Any question about pharo is welcome <pharo-users@lists.pharo.org> Reply-to: Any question about pharo is welcome <pharo- users@lists.pharo.org> From: Nicolai Hess <nicolaihess@gmail.com> Am 13.10.2017 5:50 PM schrieb "Andrew Glynn" <aglynn42@gmail.com>: I can't remember ever using API docs in any language, dynamic or not.  They give you the method signatures, but if you have, say, methodX(int, int, String), how are you supposed to guess what ints and what String the method actually needs, Isn't this exactly what an apidoc is for? Additional documentation to describe the methods and   arguments purpose.  Maybe you have just seen poorly documented libraries? One of my favourite language fails can be reproduced by doing this:  Declare a field private final in Java, initializing it either in the declaration or the constructor, and provide only a getter. Use the getter from another class and change the value of the local variable. Then use the getter again, but assign the value to a new local variable, and check the value.   Maybe you should re-read about javas  final keyword. It is not to meant making something immutable , you can just not reassign a new value. Java final != c++ const

Well oh Well, Python is stupid.... Very, very stupid To my suprise live coding in Python its actually easier to what I expected and almost the same, from user perspective to that of pharo.Minus the IDE conveiniece of course. But a pain in the hat to find the proper way to do it. I was reloading modules, was thining of implementing become to python , which basically means replacing references to old instance object with references to new objects , then I thought that it would be more efficient to just reference the new methods to the instances and after a TON of testing I realized this is dead simple and for some reason python hides it very well. All the above were completely unecessary. Insance methods are referencing functions in the class object. Apparently functions in a class are taken as class methods and functions with self as first argument are considered instance methods. Which means I just copy paste the code of the method to the debugger, and assign it back to the existing live class and all instances are updated automagically. No need for become, no need to update instances manually no need to even reload the module. Similarly you can delete methods and add methods on the fly always live. Renaming a method is basically deleting and assigning . Renaming the class is the same. As is for class and instance variables. So anything can change on the fly. Names are there for your pleasure, in the end all that matters are the references.Its objects all the way down. The equivelant of a python instance method defiition and live updae , the python way, on Pharo would be MyClass instanceMethodName:= myMessage firstArg:self arg2: foo1 arg3: foo2.... |locals| code stuff and you python "call it" or message it MyClass insanceMethodName arg2:foo1 arg3: foo2 , no need to use self when calling it. Self is automatically passed because from the definition python knows this is suppose to be an insance method. or you could put a block after the assigment , because the name of the message is assigned by the assignment anyway, for class method you ommit the first argument of self. Calling is the same. This replaces a method or adds it if does not exist. All instances of that live class are immediately poitining to the new method. So the class is basically a collection of references. So all I have to do now is to wrap the copy paste and assignment in a single shortcut or button and I am ready to fly to live coding land. Days wasted chasing my tail but at least I learned a lot about python objects which are basically dictionaries objects (for variables) plus function objects (for class and instance methods) wrap inside an object, or rather referenced, called a class. Storing the live state , similar to fuel, is supported by the pickle library. Why on earth python made it so hard something so simple to understand ? no idea .I dont even need to make a live coding enviroment library as I assumed, its already there, hiding under the cover too scared to come out. Now I know why none or almost none does live coding in Python.

On 12-10-17 08:30, Markus Stumptner wrote:

Just to lead this back to the original question.  What you say is undoubtedly true.  It is not, however, necessarily something that a beginner will understand or be able to share in.

That is a very important point. It also explains a lot of why we are missing certain things that developers coming from other environments take for granted: they simply provide less value to experienced smalltalkers. And that is indeed a barrier to entry. I remember sharply my first looking at squeak, and just not understanding how I could create a new class or method in a browser. Another was that I have been programming in seaside for a year without using senders and implementers. Pair programming for an hour with Philippe Marschall showed me so much invisible/hidden functionality. Other (mainstream) environments don't provide the immediate feedback of navigating, inspecting and manipulating the whole environment, and therefore newcomers have no appropriate expectations (internal model), and are clueless on what they are able to do in Pharo. Combined with the lack of systematic visual clues and the high density of the class library that makes it not easy to learn. Stephan

I'll second that. Having separate namespaces would be really good. VisualWorks has them. Why not Pharo? kilon.alios wrote

The one things I trully miss, even know that I am "experieced" Pharo coder, depending on your standards, is python namespaces

I dont care about the dot syntax but containers of containers at language level that will make me avoid giving weird names to my Pharo classes to avoid potential collisions is a must have for me. It would also make the System Browser experience much smoother not only for beginners but also experts in Pharo.

Also again under the threat of being thrown tomoatoes (probably justified) I would not mind a more modular approach to image format, for example having mutlipe files instead one monolithic. Not as a mandatory thing just something optional, the ability to break an image to pieces , send those pieces around so people do not have to close their image to open yours. Fuel covers this case nicely but again it could become a bit more "out of the box" and more automatic. .

On Thu, Oct 12, 2017 at 11:22 AM stephan <

stephan@

> wrote:

...

On 12-10-17 08:30, Markus Stumptner wrote:

...

Just to lead this back to the original question. What you say is undoubtedly true. It is not, however, necessarily something that a beginner will understand or be able to share in.

That is a very important point. It also explains a lot of why we are missing certain things that developers coming from other environments take for granted: they simply provide less value to experienced smalltalkers. And that is indeed a barrier to entry.

I remember sharply my first looking at squeak, and just not understanding how I could create a new class or method in a browser. Another was that I have been programming in seaside for a year without using senders and implementers. Pair programming for an hour with Philippe Marschall showed me so much invisible/hidden functionality.

Other (mainstream) environments don't provide the immediate feedback of navigating, inspecting and manipulating the whole environment, and therefore newcomers have no appropriate expectations (internal model), and are clueless on what they are able to do in Pharo. Combined with the lack of systematic visual clues and the high density of the class library that makes it not easy to learn.

Stephan

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

For me there is also question 3) How closely they are related to the bootstrap project namespaces afterall is all about modularity which is the goal of bootstrap as well . no ? So maybe we should not view them as a separate project and more as boostrap v2 , after v1 is released of course Proably Pharo 9 or 10 should be a good period to focus on them. Bootstrap will have matured and stabilize and then we can go the extra step of namespaces. Also in Delphi , besides namespaces which is purely a language construct we had "Components" , think of them as namespaces but meant to work convenient in a IDE enviroment. I really like it as an idea and Delphi based its whole library on components. Again pure objects of course, with some metadata for the IDE to use, like category, dependencies etc So if namespaces is the bridge between bootstrap and the language , Components can be the bridge between bootsrap and the IDE , because their role was to assembly libraries together via drag and drop and make code like legos. So it can be Components containing namespaces, namespaces containing objects. Thats one idea that worked well enough in practice to make Borland very profitable. It applied it both in Delphin and C++ Builder products. The library was called VCL (Visual Component Library) and still exists today after decades of use. Metacello also can come to this game on the basis that nowdays everything is online , Components could abstract git and other version controls and offer a convenient drag and drop from the github directly to the comforts of you image with no extra tool needed like Iceberg. You can then use Iceberg to commit back to the repo. It can really come together quite nicely if Components function as in Delphi, a common protocol for object to communicate for IDE convenience, without braking the existing legacy code in Pharo. Well thats just an idea, based on my personal experience. On Thu, Oct 12, 2017 at 3:53 PM Sean P. DeNigris <sean@clipperadams.com> wrote:

horrido wrote

...

Having separate namespaces would be really good. VisualWorks has them. Why not Pharo?

I can't remember ever hearing disagreement on this subject. It seems the only questions have been: 1) how to do them *right*, and 2) where they fall on the endless prioritized todo list

----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

On Wed, Oct 11, 2017 at 10:39 PM, Offray Vladimir Luna Cárdenas < offray.luna@mutabit.com> wrote:

The more I use Pharo, the less I use web documentation.

That is a familiar path, but still an obstacle for people to get over in trying Pharo - i.e. its a barrier of entry. I've previously referred to this article by JoelOnSoftware, but to pull out a key part... "Think of these barriers as an obstacle course that people have to run before you can count them as your customers. If you start out with a field of 1000 runners, about half of them will trip on the tires; half of the survivors won’t be strong enough to jump the wall; half of those survivors will fall off the rope ladder into the mud, and so on, until only 1 or 2 people actually overcome all the hurdles. With 8 or 9 barriers, everybody will have one non-negotiable deal killer. This calculus means that eliminating barriers to switching is the most important thing you have to do if you want to take over an existing market, because eliminating just one barrier will likely double your sales. Eliminate two barriers, and you’ll double your sales again." For example, Stef mentioned that the Pharo web docs were dropped because were't used much. But perhaps their value is not for regular use by the community, but more for outsiders evaluating Pharo, or newcomers transitioning from their old workflow to a Pharo one. In that case their value eliminating one barrier of entry is much greater than measured from the number of page hits. btw, What I like about Richards's articles is that... most of our community's articles are for people already using Pharo, even if only a newcomer of a few days working through an introductory tutorial. Richard's articles target outsiders and one of the side benefits for *me* is that it pulls in critical outside perspectives to remind me of the barriers-of-entry stopping people using Pharo. Take for instance the common angst people have against working in an Image in Smalltalk. There are some legitimate concerns with ending up in a state you can't recreate, which we are addressing this with the bootstrapping projects. But I think we might publicize this better to outsiders. For example... Mr Smith knows nothing about Smalltalk and takes an interest in Pharo. Smith discusses with colleague Jones who presents a poor opinion of the Smalltalk Image approach. So Smith never tries Pharo! Alternatively, if Smith has already read in an FAQ about this common argument and how we address it by our bootstrap process, he can inform Jones', and maybe now we've got two curious newcomers. cheers -ben

I agree with you that difficulty is half the fun, assuming you're a developer - developers solve problems, so if there weren't any we'd be a bit out of luck.  For myself I've somehow never, in a 26+ year career, worked on maintaining code. I've only ever written new code. in fact  I usually wind up with the things nobody, me included, has a clue of how to do, tending to make them even more difficult.  On a project last year the 'technical unknowns' could be boiled down from the 5 page document I was given to one word, 'everything', including what the customer (the government, unsurprisingly), actually meant by any of the terms used in the requirements, since even common networking terms like VPN mean something different to government employees, apparently, than to anyone else in the world. It's rewriting the same or incredibly similar rote code because we start from the same basic point on every project that gets on my nerves; writing new and often difficult code, or learning new and often difficult languages, even learning unfamiliar domain specific terminology, are the reasons I'm still a developer.  Difficulty though ought to come with a bit of power.  JavaScript can be extremely difficult, but when it's difficult and the result is that a page widget appears in the right place, it doesn't feel like much of an accomplishment.  Electron apps can be difficult, though the difficulty isn't in writing them, but in building them and getting them to actually run, especially if you're supporting Mac as well as Windows. Unless I'm writing a VM (which I haven't done very much of at all) the difficulties with CLANG, SLANG, along with about a dozen other tools, just to build a simple application, doesn't feel like much of an accomplishment either. At least not to me, I guess it does to some people though.  I have noticed a squeaky wheel effect: technologies that 'just work' get quickly forgotten, because there aren't 3 million people on slashdot or wherever asking questions about how to get them to work. JINI (now Apache River) is a good example (especially in Java, where not much 'just works'), when the new cars that automagically connect your cell phone and tablet to their own 4G were designed, they had to write JINI clients for C and whatever other languages they use, because that's what does all the automagic.  But not many people even remember it exists. One thing I do disagree with you on is that people prefer Windows. It seems to me that Windows is more popular due to price, and maybe due to the relative ease of controlling access centrally, more than anything, and even given the lower prices on (at least as far as obvious specs go) equivalent machines, I can't think of anyone I know off the top of my head who would use Windows if they could afford a Mac, and everyone I know who can, does use one.  I had to write a Mac app for Charles Schwab that would run on any home Mac (down to G4 based Macs with a half gig of RAM that could run at best OS X 10.5) with equivalent features to a Windows app that required 16GB RAM to load and 24GB to run decently, because the majority of the professional stock traders who use Windows all day at work have Macs at home (of course they can largely afford them).   If I'm not developing or testing I admittedly most often use a Macbook myself.  I do use Windows on my tablet, since it can run a full version of Win 10 x64 (not the useless RT version) and therefore nearly any Windows program.  I won the tablet at HP at the xmas party though, and with a quad-core Atom CPU and 8GB RAM it's not really an average tablet. Even then, I only use it if stuck somewhere for a while with nothing to do. So I have to admit, if I'm not developing I don't enjoy difficulty much.  Nor do most of the end users I know.  I do know a few masochists who prefer Linux to Mac, most of whom don't run a UI.  The few who do use MATE, which while being both ugly and lacking any notable capabilities, never mind applications, doesn't use much memory.  Exactly why a third of a GB of RAM is relevant today I'm not sure, when both Atom and Sublime Text use more memory than Ubuntu, Kubuntu or OS X for that matter, but they seem to feel it's radically important.  Sublime Text makes me think of Hegel's definition of The Sublime: "the night where all cows are black" ☺. I'll use Linux if my Thinkpad is handier. It runs OEL with KDE, so it's not difficult (unless you want anything by Adobe, lol), and it's pretty quick. Though ironically the Macbook is still quicker, though it has half the RAM and an i7 that's 2 generations older.   I visited a friend at the IBM lab I used to work at a few months ago, and since they know me pretty well at security, I had no problem getting a visitor badge.  Walking through the area where they write among other things, DB2 UDB, InfoSphere, WebSphere and associated products, and all of ibm.com I glanced in the cubicles as I went to my friend's desk, and the majority of the developers were using Macbooks. The only people with Thinkpads were managers.  So maybe developers like difficulty, but not quite as much with things that are supposed to be already developed.  It could just be easier to give them Macbooks than to try to get security to let them have local admin rights on Windows ... Best quote I've seen on Windows, particularly given the source:  "With luck, this will start Windows, and a dialogue box will appear and tell you the default drive onto which IADS will be installed.  If Windows doesn't start up, you could always try launching Windows manually."  - IADS Manual, U.S. Army.   Since IADS requires Windows 7 at minimum, exactly how you 'launch it manually' is beyond me, but then again I'm not in the military, and they seem to be able to write software in ADA (software that runs, even).  Although the Army writes IADS, it's used by virtually every government department, not only in the U.S. but in Canada as well - it's AFAIK the only open source, free, true WYSIWYG SGML editor, and given FrameMaker is $999 a license, free becomes relevant when you have a lot of employees. It has to have the worst name of any software in the world, excepting maybe Eclipse VIATRA. cheersAndrew Glynn    -----Original Message----- Date: Fri, 13 Oct 2017 07:00:46 +0000Subject: Re: [Pharo-users] Behold Pharo: The Modern SmalltalkTo: Any question about pharo is welcome <pha ro-users@lists.pharo.org>Reply-to: Any question about pharo is welcome <pharo-users@lists.pharo.org>From: Dimitris Chloupis <kilon.alios@gmail .com>

That is a familiar path, but still an obstacle for people to get over in trying Pharo - i.e. its a barrier of entry.  I've previously referred to this article by JoelOnSoftware, but to pull out a key part... "Think of these barriers as an obstacle course that people have to run before you can count them as your customers. If you start out with a field of 1000 runners, about half of them will trip on the tires; half of the survivors won’t be strong enough to jump the wall; half of those survivors will fall off the rope ladder into the mud, and so on, until only 1 or 2 people actually overcome all the hurdles. With 8 or 9 barriers, everybody will have one non-negotiable deal killer.  This calculus means that eliminating barriers to switching is the most important thing you have to do if you want to take over an existing market, because eliminating just one barrier will likely double your sales. Eliminate two barriers, and you’ll double your sales again."

  ****WARNING LONG POST AHEAD****  There numerous reason why this kind of thinking is fundamental flawed, if not completely wrong 1) How you get people to run in this race ? 2) What makes you think that people participating in the race doing to get first or even finish ? 3) How you are certain that those barriers are not the very reason people participate ? The fundamental problem is that if you base your assumption that people are motivated on avoidance of pain, this is a very popular argument by the way, you going to be severely disapointed. From the very first fact that there is a 90% chance that right now that you use almost 100% of your time one of the worst software to be ever created.  Microsoft Windows.  Of course you can throw claims to me that peope use Windows because that is what's popular and widely available, but then so is MacOS is by far the easiest to use OS out there. When you pit Windows vs Macos a such taboo subject , fuel to so many flame wars, there is one thing that both sides agree on and that is that MacOS is far easier to use , perdiod. The rest of the debate which OS is the best is up in the air and frankly not the point of my argument.  The fact is , we love pain, we love barriers, we love doors that slam into our face. We love challange. But only if we find it interesting.  Of course Windows is not the only example  (C/C++ , Java , Web dev, computer games and the list is just endless)of the machocistic nature of human beings. I dont need to look far, my own story about how I started coding is more than enough . I am going to ramble about my initiation to the realm of coding , so feel free to ignore the rest of my post but what the hell here we go. 

From an early age , no idea when, I was exposed to the idea of the computer. Never used one before or saw on in person other than what I saw in the TV I asked my father to get me one and he agreed on the ground that I wont use it just to play games but to learn how to code. My father had no idea what coding is, had no idea what technology is, to this day he hates technology and he refuses to learn even how to close a window. None , friend , relative or random stranger I knew used a computer.

So I got this weird thing called computer and turned it on, of course motivated to play games like any other kind in my age, I was 9 years old at the time, december 1988. But I had a sense of honor even from that age so I had to keep my promise. So I did and I was fascinated by it, to the degree that I was coding as much I was playing games. Problem is that it was mainly masochistic venture. I had one book and one book alone, none that had any clue how to show how to turn this thing on and of course no internet, no schools, no magazines I could afford to buy or even know where to buy them . So in 3 years, I made nothing special, only tiny fragments of code and I was still struggling with basic concept like looping. Yes, looping.  But I already was doing things that a greek kid did not suppose to do and I did not even fit the geek stereotype at the time (not that the term existed at the time, I still does not exist in my language), I had tons of friends, I was anything but shy , I was the craziest nosiest kid suffering from the annoying syndrom of hyperactivity and with very lmited attention span.  I was the absolute worst candidate to learn how to code, yet I did . Sort of. Then my father decided to send me, after me begging on my knees, on a prrivate school, that just opened near our neighborhood for learning. At the time time I only still had the same computer, Amstrad CPC 6128 and knew the very basics of Locomotive Basic which was used also by the computer as a bash like language for its OS.  I went 3 years, the first year I did ok, an average student even though I had by far the most experience than other kids we learned GWBASIC. The second year I did terrible, we learned DBASE and the third we learned CLIPPER and blow any other student completely away, I was the only to graduate with 99.8% and our teacher was super strict on the matter of grades. But I wanted more.  So I went and learned C++ and assembly because why not and when I told my teacher that, he was looking me with his eye wide open, took me quite a lenghy discussion to convince him that this was true.  The reason why the first year I did average was that it was too easy. I was already familiar with Basic , sure I was struggling with basic concepts when I started but   under the wing of the teacher (he was a great teacher, professional coder and highly skilled at helping you understand even the most difficult concepts) and full access to multiple books in few months became a walk in the park. The second year was a disaster, partly because our teacher decided to hire a relative of his to teach us DBASE and the guy was a moron wasting his time with telling jokes. The truth is that I did not like and still dont like database coding. Clipper I fall in love with it at the time because still a database orientated language but our teacher tought us, his relative got sacked as soon as he learned that he sucked, that happened one year after because none of the kids had the courage to go tell him and it was probably a parent the told him and did so well I was even offered to make a database for a considerable amount of money. Said no. Again not interested.  My story is nothing special, I heard it in slightly diffirent versions by countless others in a similar situation however my point is  not to brag, because lets face it I was just merely learning languages and not doing any serious coding , my point is that the drive behind it was the pain. Was the obstacles. Was the challange.  Pharo for me is also the same story. At the time I was coding in Python, super easy, got the job done, had no intention learning another language because why bother when they all look the same and they would have been much less powerful than Python. I was super happy with Python and still is one of my favorite language as you all know. Then I saw people on forums rambling about this weird language called Lisp , I was interested, google a tutorial , saw the parentheses , said "hell no!" and carried on coding in python. Then even more people claiming that it was so amazing, that it can cure cancer and make you super sexy. I always wanted to be super sexy so I said, ok lets give this a serious try. So I bought a book called "Land of Lisp" very fun to read, terrible teaching material, messy and all over the place. Community was terrible too (Common Lisp), at least some people, rude, snobs, evangelistic and plain stupid. A minority of people but still enough to ruin your day.Then I was introduced to emacs, another super painful experience, thoroughly enjoyed and one day I mentioned how cool it would be if one could combine the simplicity of Lisp with emacs but via a GUI IDE and without elisp which was hog slow. People immediately recommended Squeak, I though they were messing with me because none would pick such a ridiculous name for a language. Looked to me like a toy language for kids and then it hit my face like a train.  Pain, pain and more pain.  But it was well worth, I was completely blown away from the elegance of Smalltalk. The learning curve of Smalltalk and Lisp are plain insane. Made learningh DOS Assembly a walk in the park in comparison.  But frankly thats half of the fun.  Many obstacles, many challanges.  And there lies my point that an obstacle is a good thing when it becomes an interesting challange. You have to have at least a degree of masochism to learn how to code in any language. Of course the question is what makes an interesting challange and welcome to the abyss that is called "human brain". None knows and we are not anywhere close in finding out.  What we know is that documentation is super important , whether you are a masochist or not, you need it to progress. Problems is that documentation is hard to create and maintain, again masochism required. So we should not just worry about making it easier for people to reach documentation we should make it easier for people to maintain it. Because even masochism has its limits. Those limits are as far it is a pleasureable pain.  So congratulations to anyone reading this long post , you already proven my point. Thus, let embrace the pain of Pharo and the pain of smalltalk and instead of trying to make it easy, boring and usual. Lets turn it to a challange, lets turn it to a painful yet pleasureable experience  I think to that extend we in a very good path, I think Pharo is definetly a fun experience to use and learn.  A huge plus also for Pharo is the community and how welcoming it is, we take for granted but my experience with Python was not the best either. I joined the IRC channel, other than having to endure the stupidity of "say lol 3 times and you are banned" , too many wars over languages and how superior Python is than anything else. Guido is god and blah blah blah... No thanks.  People here are open minded, still "religious" about Smaltalk but they actually want to help , not to teach, actually help.  I think we are a bit too obsessed on how to make Pharo popular, Smalltalkers suffer from this insecurity of the "failure" of the "best language of the world" not only to become popular but also to convince coders that "is not a a relic of the past".   But we are fine, documentation is doing grear, Pharo is improving rapidly , the community is welcoming as ever. All we need is embrace our successes and our failures, reject the hype, consider the crticism and accept it or reject it and generally carry on doing what we all love.  Improving Pharo.  ;)

On 13/10/17 08:52, Vitor Medina Cruz wrote:

I completely agree with Ben.

As for Dimitris, I have some points: [...]

The fact is , we love pain, we love barriers, we love doors that slam into our face. We love challange. But only if we find it interesting.

See, I think that’s not the point, the point is that people are very resistant to any change in their habits, so much that’s usually better to short-circuit into their habits to make a change instead of trying to force a hard change on them. That is why I think Ben point of view is not flawed at all, on the contrary, removing barriers is a way to make Pharo seems more like what people are habituated, short-circuiting peoples habits into Pharo usage. Withing time, people better understanding of Pharo may trigger small, but incremental, changes to it’s habits to get the “A-ha!!!” moment where live code and all wonders of Pharo make sense.

I frankly read very loosely the rest of you answer ( :) :P ), but I get you are not interested in making Pharo popular rather than get really interested, open minded people on borad so to make it even more amazing, but I also disagree here (in part  :) ). There are lot’s of people who could do better for the community if the entrance were easier, more popularity could means more opportunity in job field and, in a more philosophical matter, a way to make the whole current programming field better. Of course, with more popularity comes disadvantages as well, some of which you already said, which can be addressed, but if this is price to pay I personally think it is worth it.

[...]

On Fri, Oct 13, 2017 at 4:00 AM, Dimitris Chloupis <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>> wrote:

That is a familiar path, but still an obstacle for people to get over in trying Pharo - i.e. its a barrier of entry.  I've previously referred to this article by JoelOnSoftware, but to pull out a key part... "Think of these barriers as an obstacle course that people have to run before you can count them as your customers. If you start out with a field of 1000 runners, about half of them will trip on the tires; half of the survivors won’t be strong enough to jump the wall; half of those survivors will fall off the rope ladder into the mud, and so on, until only 1 or 2 people actually overcome all the hurdles. With 8 or 9 barriers, everybody will have one non-negotiable deal killer.  This calculus means that eliminating barriers to switching is the most important thing you have to do if you want to take over an existing market, because eliminating just one barrier will likely double your sales. Eliminate two barriers, and you’ll double your sales again."

[...]

 

The learning curve of Smalltalk and Lisp are plain insane. Made learningh DOS Assembly a walk in the park in comparison. 

But frankly thats half of the fun. 

Many obstacles, many challanges. 

And there lies my point that an obstacle is a good thing when it becomes an interesting challange. You have to have at least a degree of masochism to learn how to code in any language. Of course the question is what makes an interesting challange and welcome to the abyss that is called "human brain". None knows and we are not anywhere close in finding out. 

What we know is that documentation is super important , whether you are a masochist or not, you need it to progress. Problems is that documentation is hard to create and maintain, again masochism required. So we should not just worry about making it easier for people to reach documentation we should make it easier for people to maintain it. Because even masochism has its limits. Those limits are as far it is a pleasureable pain. 

So congratulations to anyone reading this long post , you already proven my point.

I read it the same way as Vitor did also (I don't know why my mail client marked some part of this thread as unread), so answering Dimitris mail is not a probe of being pain lovers ( :-P ).

A huge plus also for Pharo is the community and how welcoming it is, we take for granted but my experience with Python was not the best either. I joined the IRC channel, other than having to endure the stupidity of "say lol 3 times and you are banned" , too many wars over languages and how superior Python is than anything else. Guido is god and blah blah blah... No thanks. 

People here are open minded, still "religious" about Smaltalk but they actually want to help , not to teach, actually help. 

I think we are a bit too obsessed on how to make Pharo popular, Smalltalkers suffer from this insecurity of the "failure" of the "best language of the world" not only to become popular but also to convince coders that "is not a a relic of the past".  

But we are fine, documentation is doing grear, Pharo is improving rapidly , the community is welcoming as ever. All we need is embrace our successes and our failures, reject the hype, consider the crticism and accept it or reject it and generally carry on doing what we all love. 

Improving Pharo. 

;)

I think, as I have said and mentioned in the thread, that the issue is having the proper community size (but I don't know how to calculate that). This, in my case means to show Pharo to non-developers (like myself): activists, journalist, (non-software) researchers and so on, and show them something similar (not equal) to what they know, but with advantages. So we start by learning Markdown, using Grafoscopio to write structured documents with markdown, then using it to learn how to create the same visualizations that you could do in a spreadsheet (pie and bar charts), , but with coding and then using coding to create visualization you can not get in as premade in any point and click interface. That path from what they know (mostly spreed sheets and word processing) to what is possible with coding has being worthy and more pleasant to traverse that the classical (and dumb) "hello world!" introductions to programming or even other "data science" course that are tools focused. We use the idea of moldable tools to "escape the tools". That means that you need to learn how to think symbolically (coding) to express the features you want the tool to have. Documentation is going well. In fact the stuff that kept me away of Squeak, despite of its potential was the lack of documentation. "The artifact is the curriculum" was to powerful but too heavy. You need a way to understand how to deconstruct and navigate the artifact that is usually anchored with the culture you have (books and reading) instead of only launching inspectors os browsing the code. Grafoscopio is my attempt to fill that gap between the world of objects/simulations and the world of scripts/documents. Cheers, Offray

On 4 December 2017 at 12:15, horrido <horrido.hobbies@gmail.com> wrote:

Speaking of which, one of my readers said he tried out Pharo recently and found the documentation wanting. He was expecting a Getting Started guide at the pharo.org website and couldn't find one. So he had to blunder around a bit.

Thanks for passing that on. Documentation has been improving but a quick start would probably be useful. Its the sort of thing I look for in other systems to skim to evaluate how interesting they are and if they are worth investing time in. cheers -ben

I told him he could've looked at "Chapter 2: A quick tour of Pharo" in the *Pharo by Example 5* book, but he's right. There ought to be something obvious at the pharo.org website that helps a newbie get Pharo up and running, understand how to basically use the Pharo IDE, and write the standard "Hello World" program.

I checked out squeak.org and found the same documentation issue! Why is this???

Offray Vladimir Luna Cárdenas-2 wrote

...

Documentation is going well. In fact the stuff that kept me away of Squeak, despite of its potential was the lack of documentation. "The artifact is the curriculum" was to powerful but too heavy. You need a way to understand how to deconstruct and navigate the artifact that is usually anchored with the culture you have (books and reading) instead of only launching inspectors os browsing the code. Grafoscopio is my attempt to fill that gap between the world of objects/simulations and the world of scripts/documents.

Cheers,

Offray

Understood. I'm working on a Pharo Quick Start guide. If it passes muster with you guys, you may want to link to it, or incorporate its contents into the pharo.org website. However, I've stumbled on an odd obstacle: downloading and running the Default GNU/Linux zip file. According to the Linux installation page, and I quote: Version 6.1 for several common GNU/Linux configurations. The zip files contain everything necessary. Just download and run the executable. For more download options, see the sections below. I am unable to "run the executable" without further explanation. I'm guessing that it's missing the Pharo VM, which apparently isn't included in the download. A newbie looking at this installation page and trying to get started with Pharo under Linux would be totally confused and frustrated. Hell, *I'm totally confused and frustrated!* Stephane Ducasse-3 wrote

Hi

We have a full mooc with 90 videos, we have books. And we are super busy. You see we cannot do everything.

Stef

On Mon, Dec 4, 2017 at 5:15 AM, horrido <

horrido.hobbies@

> wrote:

...

Speaking of which, one of my readers said he tried out Pharo recently and found the documentation wanting. He was expecting a Getting Started guide at the pharo.org website and couldn't find one. So he had to blunder around a bit.

I told him he could've looked at "Chapter 2: A quick tour of Pharo" in the *Pharo by Example 5* book, but he's right. There ought to be something obvious at the pharo.org website that helps a newbie get Pharo up and running, understand how to basically use the Pharo IDE, and write the standard "Hello World" program.

I checked out squeak.org and found the same documentation issue! Why is this???

Offray Vladimir Luna Cárdenas-2 wrote

...

Documentation is going well. In fact the stuff that kept me away of Squeak, despite of its potential was the lack of documentation. "The artifact is the curriculum" was to powerful but too heavy. You need a way to understand how to deconstruct and navigate the artifact that is usually anchored with the culture you have (books and reading) instead of only launching inspectors os browsing the code. Grafoscopio is my attempt to fill that gap between the world of objects/simulations and the world of scripts/documents.

Cheers,

Offray

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

On 5 December 2017 at 14:50, Stephane Ducasse <stepharo.self@gmail.com> wrote:

On Tue, Dec 5, 2017 at 5:49 AM, horrido <horrido.hobbies@gmail.com> wrote:

...

Understood. I'm working on a Pharo Quick Start guide. If it passes muster with you guys, you may want to link to it, or incorporate its contents into the pharo.org website.

Sure let us know.

...

However, I've stumbled on an odd obstacle: downloading and running the Default GNU/Linux zip file. According to the Linux installation page, and I quote:

Version 6.1 for several common GNU/Linux configurations. The zip files contain everything necessary. Just download and run the executable. For more download options, see the sections below.

./pharo-ui Pharo61.image &

I guess this is to make `pharo` look "normal" when used for non-gui scripting from the command line. It still bites me occasionally depending on what context I've been working in, but I can live with that. This is the sort of thing a Quick Start will be good for. cheers -ben

...

I am unable to "run the executable" without further explanation. I'm guessing that it's missing the Pharo VM, which apparently isn't included in the download.

Why would it be?

...

A newbie looking at this installation page and trying to get started with Pharo under Linux would be totally confused and frustrated. Hell, *I'm totally confused and frustrated!*

As you see this can be fixed without losing more time on that.

...

Stephane Ducasse-3 wrote

...

Hi

We have a full mooc with 90 videos, we have books. And we are super

busy.

...

...

You see we cannot do everything.

Stef

On Mon, Dec 4, 2017 at 5:15 AM, horrido <

...

horrido.hobbies@

...

> wrote:

...

Speaking of which, one of my readers said he tried out Pharo recently and found the documentation wanting. He was expecting a Getting Started guide at the pharo.org website and couldn't find one. So he had to blunder around a bit.

I told him he could've looked at "Chapter 2: A quick tour of Pharo" in the *Pharo by Example 5* book, but he's right. There ought to be something obvious at the pharo.org website that helps a newbie get Pharo up and running, understand how to basically use the Pharo IDE, and write the standard "Hello World" program.

I checked out squeak.org and found the same documentation issue! Why is this???

Offray Vladimir Luna Cárdenas-2 wrote

...

Documentation is going well. In fact the stuff that kept me away of Squeak, despite of its potential was the lack of documentation. "The artifact is the curriculum" was to powerful but too heavy. You need a way to understand how to deconstruct and navigate the artifact that is usually anchored with the culture you have (books and reading) instead of only launching inspectors os browsing the code. Grafoscopio is my attempt to fill that gap between the world of objects/simulations and the world of scripts/documents.

Cheers,

Offray

Then clearly there is something seriously wrong with the Default GNU/Linux download. It does not contain a file called 'pharo-ui'. Moreover, since the Pharo6.1.image file is located in the 'shared' folder, you'd have to CD to 'shared' to execute your command. No mention of this anywhere! How is a newbie to know??? Also, there is absolutely no indication that: (a) you need to download a VM; and (b) where you can obtain this VM from. All in all, this Linux support is quite messed up. It would be safer to remove it completely from pharo.org, rather than confusing the hell out of a visitor to pharo.org. Stephane Ducasse-3 wrote

On Tue, Dec 5, 2017 at 5:49 AM, horrido <

horrido.hobbies@

> wrote:

...

Understood. I'm working on a Pharo Quick Start guide. If it passes muster with you guys, you may want to link to it, or incorporate its contents into the pharo.org website.

Sure let us know.

...

However, I've stumbled on an odd obstacle: downloading and running the Default GNU/Linux zip file. According to the Linux installation page, and I quote:

Version 6.1 for several common GNU/Linux configurations. The zip files contain everything necessary. Just download and run the executable. For more download options, see the sections below.

./pharo-ui Pharo61.image &

...

I am unable to "run the executable" without further explanation. I'm guessing that it's missing the Pharo VM, which apparently isn't included in the download.

Why would it be?

...

A newbie looking at this installation page and trying to get started with Pharo under Linux would be totally confused and frustrated. Hell, *I'm totally confused and frustrated!*

As you see this can be fixed without losing more time on that.

...

Stephane Ducasse-3 wrote

...

Hi

We have a full mooc with 90 videos, we have books. And we are super busy. You see we cannot do everything.

Stef

On Mon, Dec 4, 2017 at 5:15 AM, horrido <

...

horrido.hobbies@

...

> wrote:

...

Speaking of which, one of my readers said he tried out Pharo recently and found the documentation wanting. He was expecting a Getting Started guide at the pharo.org website and couldn't find one. So he had to blunder around a bit.

I told him he could've looked at "Chapter 2: A quick tour of Pharo" in the *Pharo by Example 5* book, but he's right. There ought to be something obvious at the pharo.org website that helps a newbie get Pharo up and running, understand how to basically use the Pharo IDE, and write the standard "Hello World" program.

I checked out squeak.org and found the same documentation issue! Why is this???

Offray Vladimir Luna Cárdenas-2 wrote

...

Documentation is going well. In fact the stuff that kept me away of Squeak, despite of its potential was the lack of documentation. "The artifact is the curriculum" was to powerful but too heavy. You need a way to understand how to deconstruct and navigate the artifact that is usually anchored with the culture you have (books and reading) instead of only launching inspectors os browsing the code. Grafoscopio is my attempt to fill that gap between the world of objects/simulations and the world of scripts/documents.

Cheers,

Offray

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

On 5 Dec 2017, at 16:36, Sven Van Caekenberghe <sven@stfx.eu> wrote:

Hmm, yes, http://files.pharo.org/platform/Pharo6.1-linux.zip seems broken, duh.

$ curl get.pharo.org | bash

works fine though.

It is not possible to offer a single solution for 'Linux' as there are 100s of distributions, package managers, and individual preferences and tastes. That is what GNU/Linux is for. It also assumes you know what you are doing (i.e. understand the command line).

There is this, too: https://pharo.fogbugz.com/f/cases/20799/Update-Linux-Download-instructions I will update the website this week. We need to improve in general the download… so much todo.

...

On 5 Dec 2017, at 16:10, horrido <horrido.hobbies@gmail.com> wrote:

Then clearly there is something seriously wrong with the Default GNU/Linux download. It does not contain a file called 'pharo-ui'.

Moreover, since the Pharo6.1.image file is located in the 'shared' folder, you'd have to CD to 'shared' to execute your command. No mention of this anywhere! How is a newbie to know???

Also, there is absolutely no indication that: (a) you need to download a VM; and (b) where you can obtain this VM from. All in all, this Linux support is quite messed up. It would be safer to remove it completely from pharo.org, rather than confusing the hell out of a visitor to pharo.org.

Stephane Ducasse-3 wrote

...

On Tue, Dec 5, 2017 at 5:49 AM, horrido <

...

horrido.hobbies@

...

> wrote:

...

Understood. I'm working on a Pharo Quick Start guide. If it passes muster with you guys, you may want to link to it, or incorporate its contents into the pharo.org website.

Sure let us know.

...

However, I've stumbled on an odd obstacle: downloading and running the Default GNU/Linux zip file. According to the Linux installation page, and I quote:

Version 6.1 for several common GNU/Linux configurations. The zip files contain everything necessary. Just download and run the executable. For more download options, see the sections below.

./pharo-ui Pharo61.image &

...

I am unable to "run the executable" without further explanation. I'm guessing that it's missing the Pharo VM, which apparently isn't included in the download.

Why would it be?

...

A newbie looking at this installation page and trying to get started with Pharo under Linux would be totally confused and frustrated. Hell, *I'm totally confused and frustrated!*

As you see this can be fixed without losing more time on that.

...

Stephane Ducasse-3 wrote

...

Hi

We have a full mooc with 90 videos, we have books. And we are super busy. You see we cannot do everything.

Stef

On Mon, Dec 4, 2017 at 5:15 AM, horrido <

...

horrido.hobbies@

...

> wrote:

...

Speaking of which, one of my readers said he tried out Pharo recently and found the documentation wanting. He was expecting a Getting Started guide at the pharo.org website and couldn't find one. So he had to blunder around a bit.

I told him he could've looked at "Chapter 2: A quick tour of Pharo" in the *Pharo by Example 5* book, but he's right. There ought to be something obvious at the pharo.org website that helps a newbie get Pharo up and running, understand how to basically use the Pharo IDE, and write the standard "Hello World" program.

I checked out squeak.org and found the same documentation issue! Why is this???

Offray Vladimir Luna Cárdenas-2 wrote

...

Documentation is going well. In fact the stuff that kept me away of Squeak, despite of its potential was the lack of documentation. "The artifact is the curriculum" was to powerful but too heavy. You need a way to understand how to deconstruct and navigate the artifact that is usually anchored with the culture you have (books and reading) instead of only launching inspectors os browsing the code. Grafoscopio is my attempt to fill that gap between the world of objects/simulations and the world of scripts/documents.

Cheers,

Offray

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

If you are working with Mac and Gnu/Linux, your quick start could start by: 1. Create the folder for your Pharo program, download it and Launch it. For that, open your Terminal and type: ``` mkdir -p ~/Programs/Pharo/ cd ~/Programs/Pharo/ |curl get.pharo.org/64/ | bash ./pharo-ui Pharo.image | ``` You only need 2 and 4 steps to relaunch Pharo, once installed, but Mac and several variants of Gnu/Linux offer a quick launcher for running programs. Is not the smoothest intro to Pharo, but is not a big issue either and in that way you can continue your guide knowing that readers in Linux and Mac have a working Pharo System. Hope this helps, Offray On 05/12/17 13:18, horrido wrote:

I've encountered another issue, this time with the macOS download...

After I download the zip file, I unzip the file and move the Pharo application to the Applications folder. Then I have to right-click on the Pharo application and select open (double-clicking prevents me from opening the file at all). This last step fails (Pharo crashes), but if I repeat it, it works.

Thereafter, I may double-click to open the file anytime.

I can't add these instructions to my Pharo Quick Start guide without sounding like an ass. I shall have to wait until all download issues are resolved before I can complete the guide.

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Yes. Creating directories are just extra steps so Pharo and its images is just a good practice to not let it pollute your home directory... as most programs do these days. Cheers, Offray On 07/12/17 05:01, Cédrick Béler wrote:

I also find this way simple and the best to me.

curl get.pharo.org/64/ <http://get.pharo.org/64/> | bash ./pharo-ui Pharo.image

Don’t really need to say to create a dir or maybe pass it as a parameter in curl. 

The other way to install through that download one file is nice at first but I find it no convenient especially when doing a “save as”...  I also have recurrent problem with student on windows (through the first download link) where pharo complains it has no source file (whereas it is there). 

Cheers,

Cédrick 

Le 7 déc. 2017 à 00:55, Offray Vladimir Luna Cárdenas <offray.luna@mutabit.com <mailto:offray.luna@mutabit.com>> a écrit :

...

curl get.pharo.org/64/ <http://get.pharo.org/64/> | bash ./pharo-ui Pharo.image

I've completed the first draft of my Pharo Quick Start guide <https://medium.com/@richardeng/pharo-quick-start-5bab70944ce2> . I decided to forge ahead anyway. Feedback welcome. Note that I chose wget instead of curl because many Linux distros do not have curl installed. I've tested the guide for various Linux distros including Mint 18.3 (Ubuntu-based), Debian 9.2.1, Manjaro 17.0.6 (Arch-based), Solus 3, and Fedora 27. So it should be good for all the popular distros (Top 10). -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

I read it and it is good and to the point. I was thinking if we could have a class named something else than Hello May be Repeater new say: 'Hello' ? Stef On Thu, Dec 7, 2017 at 8:43 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:

Thanks Richard. I like when you are doing :)

On Thu, Dec 7, 2017 at 8:38 PM, horrido <horrido.hobbies@gmail.com> wrote:

...

I've completed the first draft of my Pharo Quick Start guide <https://medium.com/@richardeng/pharo-quick-start-5bab70944ce2> . I decided to forge ahead anyway.

Feedback welcome.

Note that I chose wget instead of curl because many Linux distros do not have curl installed.

I've tested the guide for various Linux distros including Mint 18.3 (Ubuntu-based), Debian 9.2.1, Manjaro 17.0.6 (Arch-based), Solus 3, and Fedora 27. So it should be good for all the popular distros (Top 10).

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Excellent work, Richard! May I offer the small criticism against using #initialize for the method name? I think a name like #sayIt (for example) and invocation like "Hello new sayIt" would make it explicit. This will be a great help for people who drop by out of curiosity. On Thu, Dec 7, 2017 at 11:38 AM, horrido <horrido.hobbies@gmail.com> wrote:

I've completed the first draft of my Pharo Quick Start guide <https://medium.com/@richardeng/pharo-quick-start-5bab70944ce2> . I decided to forge ahead anyway.

Feedback welcome.

Note that I chose wget instead of curl because many Linux distros do not have curl installed.

I've tested the guide for various Linux distros including Mint 18.3 (Ubuntu-based), Debian 9.2.1, Manjaro 17.0.6 (Arch-based), Solus 3, and Fedora 27. So it should be good for all the popular distros (Top 10).

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May be the class name could be changed a little bit to allow more flexibility using the Pharo Quick Start as a base. Something like "Greeter" and "Greeter new say: 'Hello world!'" or "Greeter new sayIt" could be implemented from there. Nice to see more and more documentation around Pharo, including this one. That being said, I have always felt that hello world is kind of a strange introduction to programming: http://mutabit.com/offray/blog/en/entry/dumb-hello-world Cheers, Offray On 07/12/17 15:31, horrido wrote:

I've revised the draft slightly for the comments given here: https://medium.com/@richardeng/pharo-quick-start-5bab70944ce2

Yes, it's a definite improvement. Thanks.

Richard Sargent wrote

...

Excellent work, Richard!

May I offer the small criticism against using #initialize for the method name? I think a name like #sayIt (for example) and invocation like "Hello new sayIt" would make it explicit.

This will be a great help for people who drop by out of curiosity.

On Thu, Dec 7, 2017 at 11:38 AM, horrido < horrido.hobbies@ > wrote:

...

I've completed the first draft of my Pharo Quick Start guide <https://medium.com/@richardeng/pharo-quick-start-5bab70944ce2>; . I decided to forge ahead anyway.

Feedback welcome.

Note that I chose wget instead of curl because many Linux distros do not have curl installed.

I've tested the guide for various Linux distros including Mint 18.3 (Ubuntu-based), Debian 9.2.1, Manjaro 17.0.6 (Arch-based), Solus 3, and Fedora 27. So it should be good for all the popular distros (Top 10).

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

To me the Hello World in Smalltalk was always just writing: 'Hello world' 2017-12-07 19:35 GMT-03:00 horrido <horrido.hobbies@gmail.com>:

Done. Class #Hello is now #Greeter in package "HelloDemo".

I presume we're good to go, then?

Offray Vladimir Luna Cárdenas-2 wrote

...

May be the class name could be changed a little bit to allow more flexibility using the Pharo Quick Start as a base. Something like "Greeter" and "Greeter new say: 'Hello world!'" or "Greeter new sayIt" could be implemented from there. Nice to see more and more documentation around Pharo, including this one.

That being said, I have always felt that hello world is kind of a strange introduction to programming:

http://mutabit.com/offray/blog/en/entry/dumb-hello-world

Cheers,

Offray

On 07/12/17 15:31, horrido wrote:

...

I've revised the draft slightly for the comments given here: https://medium.com/@richardeng/pharo-quick-start-5bab70944ce2

Yes, it's a definite improvement. Thanks.

Richard Sargent wrote

...

Excellent work, Richard!

May I offer the small criticism against using #initialize for the method name? I think a name like #sayIt (for example) and invocation like "Hello new sayIt" would make it explicit.

This will be a great help for people who drop by out of curiosity.

On Thu, Dec 7, 2017 at 11:38 AM, horrido < horrido.hobbies@ > wrote:

...

I've completed the first draft of my Pharo Quick Start guide <https://medium.com/@richardeng/pharo-quick-start-5bab70944ce2>; . I decided to forge ahead anyway.

Feedback welcome.

Note that I chose wget instead of curl because many Linux distros do not have curl installed.

I've tested the guide for various Linux distros including Mint 18.3 (Ubuntu-based), Debian 9.2.1, Manjaro 17.0.6 (Arch-based), Solus 3, and Fedora 27. So it should be good for all the popular distros (Top 10).

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

I'm not sure what you mean by *PrintIt:*. If you mean type 'Hello World' in the Playground and just *Print it*, that's not really a "program." Sean P. DeNigris wrote

hernanmd wrote

...

To me the Hello World in Smalltalk was always just writing: 'Hello world'

+1. While putting it in a class shows a few more of the system's features, it also makes it seem more complex than other languages, when that's not really true. Why not just PrintIt: 'Hello world'? If it seems important to show classes, maybe start with PrintIt: 'Hello world' and step-by-step build through `Transcript show: 'Hello world'` to the class-based solution.

----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Maybe the core of the suggestion is start with the Playground and then go to the code browser, that's my workflow coming from other languages like Python and Scheme, and having the playground to emulate REPL before going to code browser has been really refreshing and also "going from scripting to object" is a well received approach in our Data Weeks. So the Pharo Quick Start, after providing the installation instrucctions could be something like: """ The classical "Hello World!" program can be done in one line in Pharo, as in most dynamic languages by opening the Playground ("Cmd + Shif + o" shortcut on Mac o "Ctrl + Shift + o" on Windows) and writing "Transcript show: 'Hello World!" (see figure below), but we are going to learn also how to put this simple script into the Code Browser, a place where much of the Pharo power resides. ^ Up: The "Hello World!" example as a one-liner script ran in the Playground. """ and then I would add the succinct explanation you are doing about how to create the Greeter. Cheers, Offray On 08/12/17 09:41, horrido wrote:

I'm not sure what you mean by *PrintIt:*. If you mean type 'Hello World' in the Playground and just *Print it*, that's not really a "program."

Sean P. DeNigris wrote

...

hernanmd wrote

...

To me the Hello World in Smalltalk was always just writing: 'Hello world' +1. While putting it in a class shows a few more of the system's features, it also makes it seem more complex than other languages, when that's not really true. Why not just PrintIt: 'Hello world'? If it seems important to show classes, maybe start with PrintIt: 'Hello world' and step-by-step build through `Transcript show: 'Hello world'` to the class-based solution.

----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Hi Richard Thanks this is nice. I like Greeter :) The suggestion of Ben are fun for the next one. I will add a link to your article. Stef On Thu, Dec 7, 2017 at 11:35 PM, horrido <horrido.hobbies@gmail.com> wrote:

Done. Class #Hello is now #Greeter in package "HelloDemo".

I presume we're good to go, then?

Offray Vladimir Luna Cárdenas-2 wrote

...

May be the class name could be changed a little bit to allow more flexibility using the Pharo Quick Start as a base. Something like "Greeter" and "Greeter new say: 'Hello world!'" or "Greeter new sayIt" could be implemented from there. Nice to see more and more documentation around Pharo, including this one.

That being said, I have always felt that hello world is kind of a strange introduction to programming:

http://mutabit.com/offray/blog/en/entry/dumb-hello-world

Cheers,

Offray

On 07/12/17 15:31, horrido wrote:

...

I've revised the draft slightly for the comments given here: https://medium.com/@richardeng/pharo-quick-start-5bab70944ce2

Yes, it's a definite improvement. Thanks.

Richard Sargent wrote

...

Excellent work, Richard!

May I offer the small criticism against using #initialize for the method name? I think a name like #sayIt (for example) and invocation like "Hello new sayIt" would make it explicit.

This will be a great help for people who drop by out of curiosity.

On Thu, Dec 7, 2017 at 11:38 AM, horrido < horrido.hobbies@ > wrote:

...

I've completed the first draft of my Pharo Quick Start guide <https://medium.com/@richardeng/pharo-quick-start-5bab70944ce2>; . I decided to forge ahead anyway.

Feedback welcome.

Note that I chose wget instead of curl because many Linux distros do not have curl installed.

I've tested the guide for various Linux distros including Mint 18.3 (Ubuntu-based), Debian 9.2.1, Manjaro 17.0.6 (Arch-based), Solus 3, and Fedora 27. So it should be good for all the popular distros (Top 10).

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

isn't GNU Smalltalk a emacs Smalltalk? maybe making a migration path from GNU to Pharo could be good? On Fri, Dec 8, 2017 at 1:33 PM, Kjell Godo <squeaklist@gmail.com> wrote:

if Pharo could have a emacs version or face or something that would advertise more functions that you can get from the Pharo version or maybe link the two versions Pharo and emacsVimPharo so there is like a migration path to Pharo or they could work together that could be lower the barrier to entry i saw emacs vim guy who could also hate to learning something new

On Fri, Dec 8, 2017 at 1:08 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:

...

Hi Richard

Thanks this is nice. I like Greeter :) The suggestion of Ben are fun for the next one. I will add a link to your article.

Stef

On Thu, Dec 7, 2017 at 11:35 PM, horrido <horrido.hobbies@gmail.com> wrote:

...

Done. Class #Hello is now #Greeter in package "HelloDemo".

I presume we're good to go, then?

Offray Vladimir Luna Cárdenas-2 wrote

...

May be the class name could be changed a little bit to allow more flexibility using the Pharo Quick Start as a base. Something like "Greeter" and "Greeter new say: 'Hello world!'" or "Greeter new sayIt" could be implemented from there. Nice to see more and more documentation around Pharo, including this one.

That being said, I have always felt that hello world is kind of a strange introduction to programming:

http://mutabit.com/offray/blog/en/entry/dumb-hello-world

Cheers,

Offray

On 07/12/17 15:31, horrido wrote:

...

I've revised the draft slightly for the comments given here: https://medium.com/@richardeng/pharo-quick-start-5bab70944ce2

Yes, it's a definite improvement. Thanks.

Richard Sargent wrote

...

Excellent work, Richard!

May I offer the small criticism against using #initialize for the method name? I think a name like #sayIt (for example) and invocation like "Hello new sayIt" would make it explicit.

This will be a great help for people who drop by out of curiosity.

On Thu, Dec 7, 2017 at 11:38 AM, horrido < horrido.hobbies@ > wrote:

...

I've completed the first draft of my Pharo Quick Start guide <https://medium.com/@richardeng/pharo-quick-start-5bab709 44ce2> . I decided to forge ahead anyway.

Feedback welcome.

Note that I chose wget instead of curl because many Linux distros do not have curl installed.

I've tested the guide for various Linux distros including Mint 18.3 (Ubuntu-based), Debian 9.2.1, Manjaro 17.0.6 (Arch-based), Solus 3, and Fedora 27. So it should be good for all the popular distros (Top 10).

-- Sent from: http://forum.world.st/Pharo-Sm alltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Nope , nothing to do with Emacs GNU Smalltalk is Smalltalk without.... welll... Smalltalk Which is why almost none is using it. There is a project to use Pharo from inside Emacs called Shamoo. Frankly you will be sacrificing a lot of IDE goodies leaving Pharo. Neither Emacs or vim are proper IDEs , they are text editors pretending to be IDEs and failing miserably at it. On the other hand Pharo IS an IDE playing ball with big boys. Making shortcuts in Pharo is no big deal, if 10% of people asking for Emacs or vim shortcuts bothered creating just 10 shortcuts each we would have by now at least 100 Emacs shortcuts in Pharo. When one say that needs something that He or she is not willing to do even 1% of its work, then he does not need it enough for others to bother. It’s the difference between hype and actual desire. On Fri, 8 Dec 2017 at 23:35, Kjell Godo <squeaklist@gmail.com> wrote:

isn't GNU Smalltalk a emacs Smalltalk? maybe making a migration path from GNU to Pharo could be good?

On Fri, Dec 8, 2017 at 1:33 PM, Kjell Godo <squeaklist@gmail.com> wrote:

...

if Pharo could have a emacs version or face or something that would advertise more functions that you can get from the Pharo version or maybe link the two versions Pharo and emacsVimPharo so there is like a migration path to Pharo or they could work together that could be lower the barrier to entry i saw emacs vim guy who could also hate to learning something new

On Fri, Dec 8, 2017 at 1:08 PM, Stephane Ducasse <stepharo.self@gmail.com

...

wrote:

...

Hi Richard

Thanks this is nice. I like Greeter :) The suggestion of Ben are fun for the next one. I will add a link to your article.

Stef

On Thu, Dec 7, 2017 at 11:35 PM, horrido <horrido.hobbies@gmail.com> wrote:

...

Done. Class #Hello is now #Greeter in package "HelloDemo".

I presume we're good to go, then?

Offray Vladimir Luna Cárdenas-2 wrote

...

May be the class name could be changed a little bit to allow more flexibility using the Pharo Quick Start as a base. Something like "Greeter" and "Greeter new say: 'Hello world!'" or "Greeter new sayIt" could be implemented from there. Nice to see more and more documentation around Pharo, including this one.

That being said, I have always felt that hello world is kind of a strange introduction to programming:

http://mutabit.com/offray/blog/en/entry/dumb-hello-world

Cheers,

Offray

On 07/12/17 15:31, horrido wrote:

...

I've revised the draft slightly for the comments given here: https://medium.com/@richardeng/pharo-quick-start-5bab70944ce2

Yes, it's a definite improvement. Thanks.

Richard Sargent wrote

...

Excellent work, Richard!

May I offer the small criticism against using #initialize for the method name? I think a name like #sayIt (for example) and invocation like "Hello new sayIt" would make it explicit.

This will be a great help for people who drop by out of curiosity.

On Thu, Dec 7, 2017 at 11:38 AM, horrido < horrido.hobbies@ > wrote:

...

I've completed the first draft of my Pharo Quick Start guide < https://medium.com/@richardeng/pharo-quick-start-5bab70944ce2>; . I decided to forge ahead anyway.

Feedback welcome.

Note that I chose wget instead of curl because many Linux distros do not have curl installed.

I've tested the guide for various Linux distros including Mint 18.3 (Ubuntu-based), Debian 9.2.1, Manjaro 17.0.6 (Arch-based), Solus 3, and Fedora 27. So it should be good for all the popular distros (Top 10).

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Envoyé de mon iPhone

Le 9 déc. 2017 à 11:05, Prof. Andrew P. Black <black@cs.pdx.edu> a écrit :

...

On 9 Dec 2017, at 07:44 , Dimitris Chloupis <kilon.alios@gmail.com> wrote:

Making shortcuts in Pharo is no big deal, if 10% of people asking for Emacs or vim shortcuts bothered creating just 10 shortcuts each we would have by now at least 100 Emacs shortcuts in Pharo. When one say that needs something that He or she is not willing to do even 1% of its work, then he does not need it enough for others to bother.

In September, I posted an Issue on pharo.fogbuz: making keyboard shortcuts for the Pharo Smalltalk editor is not easy, but should be. No one has responded to that issue saying that it really is easy, and explaining how to do it. So if you know, I invite you to work on this issue. tl;dr: I though that it was easy too, but after spending a couple of days trying to figure it out, gave up.

If 10% of the energy expended in this thread had gone into fixing open issues, then Pharo would be getting better every day.

+1 Less talk more Pharo !

Pharo: The Next Ten Minutes <https://medium.com/@richardeng/pharo-the-next-ten-minutes-a17899dc9a58> . Feedback welcome. I will be leaving for vacation on Sunday for two weeks. Feedback should be given to me asap. Thanks. Stephane Ducasse-3 wrote

Hi Richard

Thanks this is nice. I like Greeter :) The suggestion of Ben are fun for the next one. I will add a link to your article.

Stef

On Thu, Dec 7, 2017 at 11:35 PM, horrido <

horrido.hobbies@

> wrote:

...

Done. Class #Hello is now #Greeter in package "HelloDemo".

I presume we're good to go, then?

Offray Vladimir Luna Cárdenas-2 wrote

...

May be the class name could be changed a little bit to allow more flexibility using the Pharo Quick Start as a base. Something like "Greeter" and "Greeter new say: 'Hello world!'" or "Greeter new sayIt" could be implemented from there. Nice to see more and more documentation around Pharo, including this one.

That being said, I have always felt that hello world is kind of a strange introduction to programming:

http://mutabit.com/offray/blog/en/entry/dumb-hello-world

Cheers,

Offray

On 07/12/17 15:31, horrido wrote:

...

I've revised the draft slightly for the comments given here: https://medium.com/@richardeng/pharo-quick-start-5bab70944ce2

Yes, it's a definite improvement. Thanks.

Richard Sargent wrote

...

Excellent work, Richard!

May I offer the small criticism against using #initialize for the method name? I think a name like #sayIt (for example) and invocation like "Hello new sayIt" would make it explicit.

This will be a great help for people who drop by out of curiosity.

On Thu, Dec 7, 2017 at 11:38 AM, horrido < horrido.hobbies@ > wrote:

...

I've completed the first draft of my Pharo Quick Start guide <https://medium.com/@richardeng/pharo-quick-start-5bab70944ce2>; . I decided to forge ahead anyway.

Feedback welcome.

Note that I chose wget instead of curl because many Linux distros do not have curl installed.

I've tested the guide for various Linux distros including Mint 18.3 (Ubuntu-based), Debian 9.2.1, Manjaro 17.0.6 (Arch-based), Solus 3, and Fedora 27. So it should be good for all the popular distros (Top 10).

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

On 8 December 2017 at 03:38, horrido <horrido.hobbies@gmail.com> wrote:

I've completed the first draft of my Pharo Quick Start guide <https://medium.com/@richardeng/pharo-quick-start-5bab70944ce2> . I decided to forge ahead anyway.

Feedback welcome.

Note that I chose wget instead of curl because many Linux distros do not have curl installed.

I've tested the guide for various Linux distros including Mint 18.3 (Ubuntu-based), Debian 9.2.1, Manjaro 17.0.6 (Arch-based), Solus 3, and Fedora 27. So it should be good for all the popular distros (Top 10).

Good work. Really nice and succulent. Some random feedback...

due to a known macOS bug, the Pharo application will crash the first time

due to a known macOS bug >>> being investigated <<<, the Pharo application >>>>may<<< crash the first time (I presume it is)

To open the System Browser, click on...

To open the System Browser, left-click on... *Most* newcomers will assume getting a menu is a right-click (btw like every other menu in Pharo) but Pharo is different here. I do believe we should change it to right-click to lower friction, or even both left-click and right-click to keep newcomers and stalwarts happy. How often does anyone right-click on the World? Could it be moved to a modifier key?

Now we need to create a method or function for our Greeter class. The standard first method is ‘initialize’ which is invoked when the Greeter class is instantiated (this is OOP parlance). For simplicity, we shall skip this.

For simplicity, just leave it out. ------------------- Now that sparks an idea for a follow-on article "Pharo - the next ten minutes" * show how easy GUI text output is easy (its another equivalent to the printf debugging paradigm every knows) Greeter >> screamIt self inform: 'HELLO WORLD!' * show nice process management and DSLish language Greeter >> counter | count | count := 0. [ count := count + 1. self inform: count printString. 2 seconds wait. ] forkNamed: 'Count de Money' "see..[1]" then World > Tools > Process Browser to Suspend,Resume, Terminate. * show unique feature with continuation of state across sessions... run "Greeter new counter" the get them to close the image and reopen it. cheers -ben P.S. side humor... [1] https://www.youtube.com/watch?v=sztf4hcGrB4

horrido <horrido.hobbies@gmail.com> wrote:

Interestingly, I'm getting a fair amount of pushback on this. Personally, I think it would be very helpful to have a live (updatable, so as to keep it current) reference page for the class library, something that developers can easily look up what they need. After all, most of the power of Pharo comes from the class library and we need to make it as accessible as possible to less experienced Pharoers (i.e., beginners).

Exploring the class library through the System Browser is very inefficient. This is further exacerbated by the fact that many classes and methods are simply not well-documented (containing a cursory remark which is just barely useful).

I realize that creating a live reference page is not easy to do. In fact, it's a lot of work. But the absence of such a page is a real obstacle to Pharo acceptance.

I have a simple example compoared with python. I want to programatically find the version number of current instance. In Python I go to the document page e.g. <https://docs.python.org/3/> and search for version. I get a pageful of hits which I can read and find the snswer (ie sys.version) For Pharo what search do I do? You don't need to implement a seach engine Google, Bing etc can do this and with a lot more resopuirces than Pharo can do, but you need the information in a restricted place e.g. one site. and it does not need to be dynamic The first thing I do for a new technology is RTFM.

horrido wrote

...

Thanks. I gave your answer verbatim. I also added the following paragraph:

The problem I find with today's developers is that they are rather closed-minded. They are rigid and inflexible, and not willing to adapt to new and different ways of doing things. In my generation (circa 1980–1990), people didn't have a problem with trying different technologies. That's why I had no issue with learning Smalltalk 10 years ago, after I had retired from a 20-year-long career in C systems programming and FORTRAN scientific programming.

Sven Van Caekenberghe-2 wrote

...

...

On 6 Oct 2017, at 14:54, horrido <

...

horrido.hobbies@

...

> wrote:

...

I received this comment from someone who complained:

*What about the lack of documentation? From time to time I've checked some SmallTalk implementations like Squeak, GNU-Smalltalk and now Pharo. Of these, only GNU-SmallTalk appears to have a free, official programming guide and core library reference that any serious programmer expects from a language.

https://www.gnu.org/software/smalltalk/manual-base/html_node/*

I pointed to Pharo's documentation but then he came back with:

*Then show me a link of the free, maintained reference documentation for the classes that form "the core library", like this one for Python (https://docs.python.org/3/library/index.html)*

It's true, most Smalltalks do not have a core library reference, not even VisualWorks! So what is the proper response to this complaint?

The first answer is that Pharo/Smalltalk is unique in that a running system/IDE contains _all_ source code, _all_ documentation (class, method, help, tutorial), _all_ unit tests and _all_ runnable examples in a very easy, accessible way. It takes some getting used to, but this is actually better and much more powerful than any alternative.

The second answer is that there are lots of books and articles that take the classic/structured book/paper approach. There is http://books.pharo.org, http://themoosebook.org, http://book.seaside.st/book, http://medium.com/concerning-pharo and many more.

-- Mark

Thanks for posting this. It is one of the best descriptions of the state of the software industry that I have seen. On Thu, Oct 12, 2017 at 11:50 AM, Andrew Glynn <aglynn42@gmail.com> wrote:

https://medium.com/@dasein42/building-with-versus-building-on-c51aa3034c71

This is an article not *specifically* about Pharo, rather on the state of the industry in general and how it got that way, but positing Pharo as a way to learn building-*on* rather than building-*with*, where in the latter case on every project you start at essentially the same place.

As a result it does put in front of people a fair amount of info on Pharo, and challenges them to try it.

cheers

Andrew Glynn

I know about personalization being a lot of work, particularly with Eclipse. I copied the text out of the ‘summary’ page in About Eclipse into Kate, and it was 1233 lines long, lol. I was one of two team leads on what was probably the most complex application I’ve worked on, using VA Java and VA C++ with CORBA to exchange objects (the need to combine both was due to legacy issues). Siemens now owns the application, which was successful enough to bankrupt its closest competitor, but the binary jars in the latest version are still dated 2002, and every addition has been made via .the WS* API we included, which if I remember correctly, uses version 1.x of WebSphere. I’m a bit surprised it still runs at all tbh, but its security must be horrible by now. Eclipse’s only saving grace is EMF/CDO, and a few projects built on them, IMHO. Sent from Mail for Windows 10 From: Dimitris Chloupis Sent: Thursday, October 12, 2017 2:05 PM To: Any question about pharo is welcome Subject: Re: [Pharo-users] "Building-With versus Building-on" It's a mentality issue, modern programming languages provide the material necessary to create innovative environments but their communities just simply does not care. A language designer may introduce a feature in a language that is super useful. Still people may not use it.  And let's face it even with Pharo nothing beats a personalized environment, of course personalisation is a lot of work. Hence why people avoid it.   Essentially boiling down to cooking your own food instead of getting it from a shop. When you begin to learn how to cook , its kinda sucks, but the more you cook the better it tastes. Of course it takes time to get there and hence why so few people cook.  Eclispe , which I will disagree with your that is not the worst IDE, started as a smalltalk IDE and then it got Eclipsed. I am sure those people had a "build on" environment , still it got messy. We can blame porting to Java, but can we really blame Java for the mess that is called "Eclipse".... ehhhh.... nope.  I once saw a youtube video about a musician using windows sounds (the standard sounds we all know of) to make  a very nice music piece. He did all that using multiple instances of windows media player. Just pause reading think about this for a minute. That's the real essence of creativity Use something very limited and come up with something amazing. The software industry is not about creativity for the most part. On the other hand I that work with 3d its amazing how fast super cool new technologies pop around like mushrooms. Every year we have massive improvements in libraries and tools. But the coding for 3d graphics is all about creativity , artists are not very forgiving for ugly GUI, limited features and innovation stagnation. Artists want to be inspired by the tools they use. But then that's the creativity realm. Creativity pays the bills in this case, lack of it , game is not fun, rendering or animation is not fun, you can lose millions.  Of course in the creativity realm , there is too much innovation and unless you keep up you are kicked out the door, yesterday. Which brings down to the problem of complexity and how you deal with it. And I don't mean about bad complexity , aka web dev, I am talking about good complexity. Features you cannot ignore because other will use before you and you are left behind etc.  On Thu, Oct 12, 2017 at 7:13 PM Peter Fisk <peter.fisk@gmail.com> wrote: Thanks for posting this. It is one of the best descriptions of the state of the software industry that I have seen. On Thu, Oct 12, 2017 at 11:50 AM, Andrew Glynn <aglynn42@gmail.com> wrote: https://medium.com/@dasein42/building-with-versus-building-on-c51aa3034c71 This is an article not specifically about Pharo, rather on the state of the industry in general and how it got that way, but positing Pharo as a way to learn building-on rather than building-with, where in the latter case on every project you start at essentially the same place. As a result it does put in front of people a fair amount of info on Pharo, and challenges them to try it. cheers Andrew Glynn

VA (VisualAge) for C++ and for Java were two IBM products, the latter being the predecessor to Eclipse.  They were both available on OS/2 and Windows NT variants (2000 mainly), and the C++ version on AIX.  Whichever platform the C++ version was run on, you could target any supported runtime platform.  They were all (along with VisualAge Smalltalk, now maintained and sold by Instantiations and currently at version 9.0, and VisualAge Generator - a Cobol version) written in IBM Smalltalk. I still use VA C++, Java, and occasionally VA Smalltalk, albeit the latter at v. 6.02, in a VM running OS/2 (well, Ecomstation, but it's the same as OS/2 4.5, just updated for more recent hardware - interestingly Arca Noae released a version 5.0, the first official (i.e. called OS/2 version since 2004, in June of this year).   I use them for prototyping and quickly creating cross-VM client/server apps that allow me to generate virtual network traffic without using tons of memory for each VM (much of what I do involves monitoring network protocols such as BGP, and without traffic to exercise the virtualized aggregated service routers, I can't demonstrate the code without carrying 6 75lb servers on my back).   I can run Lotus Domino plus 10-12 server apps written in VA C++ in a VM with one or two vCPU's and 256MB RAM.  On the client, I can run a couple dozen Java clients, connecting either to the C++ servers or Domino, in 128MB.  I put a screenshot of the CPP and Java versions below. For Smalltalk code, Pharo is better than VA, certainly better than the 6.02 version, but for C++ or Java, as long as you don't mind prototyping in an old Java version (lacking the syntactic parmesan, mainly), they're still better than anything else. Both incrementally compile/precompile in-memory on save the way ST does, but that's fairly rare in C++.  Both have ways of writing arbitrary test code similar to a playground, which is also rare in either language. Both also have data access libraries that are far faster and easier to use than JPA, never mind CMP.  VA Java also includes an ancient version of WebSphere for J2EE. CORBA (Common Object Request Broker Architecture) is a complex way of exchanging objects/data between languages.  I've seen interviewers who are/were developers actually shake if I mention it.  However both the C++ and Java versions handled most of the details without any fuss.    All the build/deploy tooling was in the environment. With the app I mentioned, lacking those environments it's maybe not impossible, but likely at least close to 'infinitely improbable' to get the thing built properly, never mind actually change the code and configs.  The junior developer from that project is a friend of mine's little brother, he's still at the company that paid to have it built, and it's now 15 years later, just so it will keep running. Ironically he was fresh out of school at the time and basically worked as a gopher, he didn't write or even debug a line of code.  After we finished the project I taught him how to modify/build it using those tools, and they're still the only thing he can use.   cheersAndrew   -----Original Message----- Date: Fri, 13 Oct 2017 07:26:13 +0000Subject: Re: [Pharo-users] "Building-With versus Building-on"To: Any question about pharo is welcome <pharo-users@lists.pharo.org>Reply-to: Any question about pharo is welcome <pharo-users@lists.pharo.org>From: Dimitris Chloupis <kilon. alios@gmail.com>What is a VA Java ? and a VA C++ ?  Call me an idiot or insane but I am in favor of combiding languages, though I only have heard of COBRA never used it.  I am a lawyer by profession, I know fellow lawyers still using DOS and QBasic databases and yes under windows ...... sadly very common for businesses here. Ah the pleasures of technology but nothing comes close to the pleasure of rejecting it.  On Fri, Oct 13, 2017 at 12:49 AM Andrew Glynn <aglynn42@gmail.com> wrote:

I know about personalization being a lot of work, particularly with Eclipse.  I copied the text out of the ‘summary’ page in About Eclipse into Kate, and it was 1233 lines long, lol.     I was one of two team leads on what was probably the most complex application I’ve worked on, using VA Java and VA C++ with CORBA to exchange objects (the need to combine both was due to legacy issues).  Siemens now owns the application, which was successful enough to bankrupt its closest competitor, but the binary jars in the latest version are still dated 2002, and every addition has been made via .the WS* API we included, which if I remember correctly, uses version 1.x of WebSphere.  I’m a bit surprised it still runs at all tbh, but its security must be horrible by now.   Eclipse’s only saving grace is EMF/CDO, and a few projects built on them, IMHO.   Sent from Mail for Windows 10   From: Dimitris Chloupis Sent: Thursday, October 12, 2017 2:05 PM To: Any question about pharo is welcome Subject: Re: [Pharo-users] "Building-With versus Building-on"  It's a mentality issue, modern programming languages provide the material necessary to create innovative environments but their communities just simply does not care. A language designer may introduce a feature in a language that is super useful. Still people may not use it.    And let's face it even with Pharo nothing beats a personalized environment, of course personalisation is a lot of work. Hence why people avoid it.     Essentially boiling down to cooking your own food instead of getting it from a shop. When you begin to learn how to cook , its kinda sucks, but the more you cook the better it tastes. Of course it takes time to get there and hence why so few people cook.    Eclispe , which I will disagree with your that is not the worst IDE, started as a smalltalk IDE and then it got Eclipsed. I am sure those people had a "build on" environment , still it got messy. We can blame porting to Java, but can we really blame Java for the mess that is called "Eclipse".... ehhhh.... nope.    I once saw a youtube video about a musician using windows sounds (the standard sounds we all know of) to make  a very nice music piece. He did all that using multiple instances of windows media player. Just pause reading think about this for a minute. That's the real essence of creativity   Use something very limited and come up with something amazing. The software industry is not about creativity for the most part. On the other hand I that work with 3d its amazing how fast super cool new technologies pop around like mushrooms. Every year we have massive improvements in libraries and tools. But the coding for 3d graphics is all about creativity , artists are not very forgiving for ugly GUI, limited features and innovation stagnation. Artists want to be inspired by the tools they use. But then that's the creativity realm. Creativity pays the bills in this case, lack of it , game is not fun, rendering or animation is not fun, you can lose millions.    Of course in the creativity realm , there is too much innovation and unless you keep up you are kicked out the door, yesterday. Which brings down to the problem of complexity and how you deal with it. And I don't mean about bad complexity , aka web dev, I am talking about good complexity. Features you cannot ignore because other will use before you and you are left behind etc.      On Thu, Oct 12, 2017 at 7:13 PM Peter Fisk <peter.fisk@gmail.com> wrote: Thanks for posting this.   It is one of the best descriptions of the state of the software industry that I have seen.     On Thu, Oct 12, 2017 at 11:50 AM, Andrew Glynn <aglynn42@gmail.com> wrote: https://medium.com/@dasein42/building-with-versus-building-on-c51aa30 34c71 This is an article not specifically about Pharo, rather on the state of the industry in general and how it got that way, but positing Pharo as a way to learn building-on rather than building-with, where in the latter case on every project you start at essentially the same place.   As a result it does put in front of people a fair amount of info on Pharo, and challenges them to try it.  cheersAndrew Glynn    

Am 12.10.17 um 20:04 schrieb Dimitris Chloupis:

Eclispe , which I will disagree with your that is not the worst IDE, started as a smalltalk IDE and then it got Eclipsed. I am sure those people had a "build on" environment , still it got messy. We can blame porting to Java, but can we really blame Java for the mess that is called "Eclipse".... ehhhh.... nope.

Eclipse was never implemented in Smalltalk. Its predecessor, VisualAge for Java (and parts of the other VisualAge family members) was. Eclipse was started as a replacement for VisualAge for Java because Java develoers didn't like VisualAge for its emulation of an image based environement. It was a very nice IDE for Java (the best I've known), but it wasn't a nice home for developers who think in files. These days Eclipse, IMO, does emulate an image as good as possible, but nobody cares anymore, because it hides the fact and lets you think in files ;-) Joachim

The problem is that it takes 1233 pages of config, and that's the summary page of my config, and it uses 15GB RAM, on my laptop, lol. On Sat, Oct 14, 2017 at 1:10 AM, jtuchel@objektfabrik.de < jtuchel@objektfabrik.de> wrote:

Am 12.10.17 um 20:04 schrieb Dimitris Chloupis:

...

Eclispe , which I will disagree with your that is not the worst IDE, started as a smalltalk IDE and then it got Eclipsed. I am sure those people had a "build on" environment , still it got messy. We can blame porting to Java, but can we really blame Java for the mess that is called "Eclipse".... ehhhh.... nope.

Eclipse was never implemented in Smalltalk. Its predecessor, VisualAge

for Java (and parts of the other VisualAge family members) was. Eclipse was started as a replacement for VisualAge for Java because Java develoers didn't like VisualAge for its emulation of an image based environement. It was a very nice IDE for Java (the best I've known), but it wasn't a nice home for developers who think in files. These days Eclipse, IMO, does emulate an image as good as possible, but nobody cares anymore, because it hides the fact and lets you think in files ;-)

Joachim

-- Andrew Glynn 512-818-3291

Hi Andrew, Stephane, thanks for the read. It was interesting, albeit a bit confusing at times. I do like your evaluation of the thesis. 2017-10-12 23:10 GMT+02:00 Stephane Ducasse <stepharo.self@gmail.com>:

Thanks Andrew I read it fast and I will reread it. It is really interesting to me because I never took the time to understand "worse is better".

Reading through "worse is better", and the follow-up "worse is better is worse" by the same author, I'm not sure there is much to understand ;) Apart if you want to study how a misunderstood quote can become a driving force in software development... Thierry

On Thu, Oct 12, 2017 at 5:50 PM, Andrew Glynn <aglynn42@gmail.com> wrote:

...

https://medium.com/@dasein42/building-with-versus-building- on-c51aa3034c71

This is an article not specifically about Pharo, rather on the state of the industry in general and how it got that way, but positing Pharo as a way to learn building-on rather than building-with, where in the latter case on every project you start at essentially the same place.

As a result it does put in front of people a fair amount of info on Pharo, and challenges them to try it.

cheers

Andrew Glynn

On Sat, Oct 14, 2017 at 11:50 AM, H. Hirzel <hannes.hirzel@gmail.com> wrote:

On 10/12/17, Andrew Glynn <aglynn42@gmail.com> wrote:

...

https://medium.com/@dasein42/building-with-versus-building-on-c51aa3034 c71 This is an article not specifically about Pharo, rather on the state of the industry in general and how it got that way, but positing Pharo as a way to learn building-on rather than building-with, where in the latter case on every project you start at essentially the same place. As a result it does put in front of people a fair amount of info on Pharo, and challenges them to try it.

cheersAndrew Glynn

Thank you for this comprehensive report.

Do you have a reference for more info about the epidemiology project which was completed in only a months time? [1]

-- Hannes

[1] <citation> After Google spent millions failing to solve the epedemiology of the Ebola outbreak, an application built with it, or rather on it, by one developer in an extremely short timespan (under a month), successfully predicted the path and allowed it to be stopped by vaccinating those in the most likely path. Google themselves took notice, and their Dart language, while using syntax similar to the JavaScript many of their developers are familiar with, uses the object model from the OSS Smalltalk. The problem is not simply a matter of how much engineers enjoy their work, but it can be a life or death matter, as it was in the case of the Toyota microcode. </citation>

​ Yes I'm also interested by this. Never heard this before :-)

-- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/

I think Laurent wrote something to export classes and documentation as html form to let user browse it. I have not idea where it is though. Hilaire Le 06/10/2017 à 14:54, horrido a écrit :

*Then show me a link of the free, maintained reference documentation for the classes that form “the core library”, like this one for Python (https://docs.python.org/3/library/index.html)*

-- Dr. Geo http://drgeo.eu

On 6 Oct 2017, at 19:57, Sean P. DeNigris <sean@clipperadams.com> wrote:

Maybe this [1] or this [2] (the two might be the same thing)

1. http://forum.world.st/Online-Pharo-Documentation-tp3468690.html 2. http://forum.world.st/webdoc-tt3654967.html

http://files.pharo.org/doc/4.0/#classList=package/Kernel.html&packageList=pa... This is only up to Pharo 4. But the point remains, given an image and all our tools, why go to the web.

Yes. We have tools that are *designed* for reading code and understanding it. But, let's have a ton of dead bits instead. On Oct 6, 2017, 15:35, at 15:35, Stephane Ducasse <stepharo.self@gmail.com> wrote:

To get dead objects while we have them live :)

On Fri, Oct 6, 2017 at 8:48 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:

...

...

On 6 Oct 2017, at 19:57, Sean P. DeNigris <sean@clipperadams.com>

wrote:

...

...

Maybe this [1] or this [2] (the two might be the same thing)

1. http://forum.world.st/Online-Pharo-Documentation-tp3468690.html 2. http://forum.world.st/webdoc-tt3654967.html

http://files.pharo.org/doc/4.0/#classList=package/Kernel.html&packageList=pa...

...

This is only up to Pharo 4.

But the point remains, given an image and all our tools, why go to

the web.

...

To be honest, I didn't know you could do live coding in Python, Ruby, C/C++. I had only ever heard of "hot swapping" in Java. At any rate, I'd be surprised if live coding in these languages was as easy and convenient as in Pharo/Smalltalk. Sven Van Caekenberghe-2 wrote

Yes, you are right: Pharo/Smalltalk is more or less the same as Ruby/Python/C/C++ in terms of power & flexibility of OOP and in live coding.

Come on.

...

On 6 Oct 2017, at 23:18, Dimitris Chloupis <

kilon.alios@

> wrote:

...

Wise not to mention Ruby and Python and Pick the worst of the worst in OOP. Because frankly the competition for Pharo against those two behemoths can be quite brutal in the flexibility and power of OOP.

And no , these language can do live coding with ease. I know because I currently code live coding style with Python for an app I am making. Sure it wont provide you with a live system out of the box, but put in 10 lines of code and you already ready to go with hardcore live coding. At least Python , Ruby being practically a rip off of Smalltalk language may need even less.

iPython which by the way is by far the most popular Python tool is the real deal, a full blow live coding enviroment.

To my suprise its not even hard to do live coding with C/C++ including using image format. To my shock live coding is actually supported by both the OS and the hardware. Hardware has its own exception system , OS has an image flie format called "memory mapped files" used for DLLs and a lot of essential functionality.

For some weird reason however its well hidden and not that much utilised by coders. They really love long compile times, dont ask me why.

But yeah C++ even though it has come a long way with its template system, its still the king of ugly. That sytax, oh the horrors of that syntax..... yiaks !!!

I am so enternal greatful that Pharo introduced me to live coding and opened my eyes to universe of fun and productivity. I cannot imagine coding an other way ever again.

I really hope that we take this further though.

On Wed, Oct 4, 2017 at 1:31 PM horrido <

horrido.hobbies@

> wrote:

...

Behold Pharo: The Modern Smalltalk <https://medium.com/smalltalk-talk/behold-pharo-the-modern-smalltalk-38e132c4...;

If you would like to suggest some edits, I'm all ears. Anything to improve the impact of the article.

Thanks.

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html