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

[Dimitris Chloupis]

The beginner way
--
1. Open Pharo 6
2. Go to Welcome window
3. Go to Keymap Browser tab
4. Right click on a shortcut entry (for example global shortcut for close
window)
5. Choose Inspect Action
6. Go to Source Code tab
7. Profit

The Pharo coder way

Or go to SystemWindow class >> buildShortcutsOn:
or got to NautilusWindow class >> buildShortcutsOn: (any method will do)
or search for any method using the  pragma


On Sat, Dec 9, 2017 at 12:06 PM Prof. Andrew P. Black 
wrote:

>
> On 9 Dec 2017, at 07:44 , Dimitris Chloupis  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.
>

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

[Ben Coman]

An extra thing for the first article, maybe change the package name from
"HelloDemo" to "HelloWorld"


On 9 December 2017 at 11:37, horrido  wrote:

> Pharo: The Next Ten Minutes
> 
> .
>
> Feedback welcome.
>
> I will be leaving for vacation on Sunday for two weeks. Feedback should be
> given to me asap. Thanks.
>

I see you have auto-update-process turned on, but you didn't tell users to
do this.
(I think it is useful to have on.  @all, I'm curious why its not on by
default)


Double "little" in first sentence.


You should describe how you enter the second method over the top of the
first.
People sometimes get stuck thinking they'll be altering the #sayIt method.


In hindsight, when readers go to experiment themselves,
some may drop the #wait to see how fast it can generate messages
which will lock up the UI due to co-operative scheduling within a
priority.
It will be better to use...
 [...] #forkAt: 30 named: 'Count de Money'



> How do you like it?

maybe...
How do you like it?   The implication is that in the early stages of
protoyping,
you don't need to slow down to build an object/relational mapping.
Just design with pure objects and persist sample data in the Image.





-
The article is good but feels too short.  One additional demonstration
would look good.
To facilitate this, change the demo code to use two methods.

sayCount: anInteger
 self inform: anInteger printString.

counter
| count |
count := 0.
[1000 timesRepeat: [count := count + 1.
self sayCount: count.
2 seconds wait]] forkNamed: 'Count de Money'



Then after the existing end of the article...

 Now consider your current language of choice...
 Say you are part of the Testing Team and a unit test errors
intermittently, or you're in Operations where an intermittent error occurs
in a production system.
 Typically the program exits, maybe dumping state but losing the live
context where the error occurred.
 What would it take to reproduce the exact error context for Developers
to analyze?
 Lets see how Pharo handles this by introducing an error into a running
'Count de Money' process.
 (If its not running, evaluate "Greeter new counter")

 Make this modification...

 sayCount: anInteger
  self inform: anInteger * 10 printString.

 Immediately after you save this, a pre-debug window pops up...
 [screen snapshot pre-debug top of stack]
 Scroll down and click on "sayCount:"  and you should see the
debugger...
 [screen snapshot full debugger on sayCount with "* 10 printString"
highlighted]

 Now as before, you can record the execution state of all running
threads by saving a Pharo Image.
 Later when you reopen Pharo you can continue debugging the faulted
thread.
 So give this a try. Save and quit Pharo now. (You could even transfer
the .image file together with its paired .changes file to another machine
with Pharo.)

 Open the Pharo Image again.  Now we are ready to fix the error.

 To explain the error, one thing Pharo newcomers need to adapt to is
that arithmetic operators are just normal message sends with no special
precedence.
 Pharo has simple semantics with just three precedence rules, evaluated
right to left.
 Unary messages like "printString" are always evaluated first.  Binary
messages like " * " are evaluated second.
 Keyword messages like "inform:" are evaluated last.   So the error
here is that we multiplied an integer with a string.
 Easily fixed...

 sayCount: anInteger
  self inform: (anInteger * 10) printString.

After saving, click  and observe the running process continues
rather than needing to restart it.
In many situations, continuing from errors like this rather than
waiting for a restarted program to progress to the same state facilitates a
very quick "debug->edit->compile->run" development loop.

For a similar demonstration, check out [PharoLambda Serverless
Debugging, https://www.youtube.com/watch?v=bNNCT1hLA3E  ]


HTH
cheers -ben

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

[serge . stinckwich]

Envoyé de mon iPhone

> Le 9 déc. 2017 à 11:05, Prof. Andrew P. Black  a écrit :
> 
> 
>> On 9 Dec 2017, at 07:44 , Dimitris Chloupis  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 !

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

[Prof. Andrew P. Black]

> On 9 Dec 2017, at 07:44 , Dimitris Chloupis  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.

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

[Dimitris Chloupis]

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

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

[horrido]

Pharo: The Next Ten Minutes
  .

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

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

[Kjell Godo]

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

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

[Kjell Godo]

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

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

[Stephane Ducasse]

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

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

[horrido]

Thanks to all your feedback, the Pharo Quick Start guide gets better and
better. Now, the reader will *really* see how easy Pharo is by the end of
the second section. The rest of the guide deals with the System Browser.

I'm very happy about this because I keep hearing crapola from JavaScript
developers saying how low the entry barrier for JavaScript is (everybody has
a web browser; all you need is a text editor and you can see immediate
results). I wanted to drive home the point that the entry barrier for Pharo
is exceptionally low, too.

And it's just as low as for Elixir, Julia, Nim, Racket, and other languages
I've recently tried.



Offray Vladimir Luna Cárdenas-2 wrote
> 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
>>
>>
> 
> 
> 
> amgfcildhiemjbph.png (21K)
> http://forum.world.st/attachment/5060126/0/amgfcildhiemjbph.png;





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

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

[Offray Vladimir Luna Cárdenas]

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

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

[Dimitris Chloupis]

Now that’s what I call a great way to promote something. Excellent work,
short to the point.

In the future you could combine small code snippets together with the rest
of your arguments for explaining the awesomeness of Pharo. Apple does this
very well and in similar style to what you have done here.

I love the size , quick to read, easy to understand.


On Fri, 8 Dec 2017 at 16:42, 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
>
>

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

[horrido]

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

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

[Ben Coman]

On 8 December 2017 at 03:38, horrido  wrote:

> I've completed the first draft of my  Pharo Quick Start guide
>   . 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

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

[Sean P. DeNigris]

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

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

[Hernán Morales Durand]

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

'Hello world'


2017-12-07 19:35 GMT-03:00 horrido :
> 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
>

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

[horrido]

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

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

[Offray Vladimir Luna Cárdenas]

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

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

[Richard Sargent]

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  wrote:

> I've completed the first draft of my  Pharo Quick Start guide
>   . 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
>
>

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

[Stephane Ducasse]

Once the pharo quick start guide is ready we will add it to the documentation.


On Thu, Dec 7, 2017 at 8:45 PM, Stephane Ducasse
 wrote:
> 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
>  wrote:
>> Thanks Richard. I like when you are doing :)
>>
>> On Thu, Dec 7, 2017 at 8:38 PM, horrido  wrote:
>>> I've completed the first draft of my  Pharo Quick Start guide
>>>   . 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
>>>

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

[Stephane Ducasse]

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
 wrote:
> Thanks Richard. I like when you are doing :)
>
> On Thu, Dec 7, 2017 at 8:38 PM, horrido  wrote:
>> I've completed the first draft of my  Pharo Quick Start guide
>>   . 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
>>

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

[Stephane Ducasse]

Thanks Richard. I like when you are doing :)

On Thu, Dec 7, 2017 at 8:38 PM, horrido  wrote:
> I've completed the first draft of my  Pharo Quick Start guide
>   . 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
>

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

[horrido]

I've completed the first draft of my  Pharo Quick Start guide
  . 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

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

[Offray Vladimir Luna Cárdenas]

I meant: Creating directories are just extra steps so Pharo and its
images keep the good practice to not let them pollute your home
directory... as most programs do these days.

Cheers,

Offray


On 07/12/17 09:49, Offray Vladimir Luna Cárdenas wrote:
>
> 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/  | 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
>> > a écrit :
>>
>>> curl get.pharo.org/64/  | bash
>>> ./pharo-ui Pharo.image
>

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

[Offray Vladimir Luna Cárdenas]

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/  | 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
> > a écrit :
>
>> curl get.pharo.org/64/  | bash
>> ./pharo-ui Pharo.image

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

[Cédrick Béler]

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

curl 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 
>  a écrit :
> 
> curl get.pharo.org/64/ | bash
> ./pharo-ui Pharo.image

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

[Offray Vladimir Luna Cárdenas]

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

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

[horrido]

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

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

[Marcus Denker]

> On 5 Dec 2017, at 16:36, Sven Van Caekenberghe  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  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
> 
> 

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

[Sven Van Caekenberghe]

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

> On 5 Dec 2017, at 16:10, horrido  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

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

[horrido]

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

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

[Cédrick Béler]

> On Tue, Dec 5, 2017 at 5:49 AM, horrido  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.


I’m also very interested as I want to give my students a very quick overview so 
they can use Pharo to manipulate some web/ICT concepts (like client request 
cycle, request processing).

So I planned to do a simple tutorial « for those who know only basic procedural 
programming ». 
Actually I will not show the power of OOP. But that is ok for me. I’ll setup a 
classes so that they can act as a « db » to student and give them some methods 
(essentially set up a (web) server, and clients).

So If you want, I’ll be happy to review your tutorial.




And BTW, I see some people complaining about documentation. I repeat myself, 
but after what I used to know back in 2003-2009… I really can tell the 
situation has improved a lot !!!
Of course this is not perfect but I find it far better.

I’ve just seen this LearningOOPWithPharo. This is excellent !!!  I’m reading it 
with a lot of interest. Congrats all and Stephane especially.
https://github.com/SquareBracketAssociates/LearningOOPWithPharo


So the situation is far better. MOOC + plenty of booklets. Since I agree a 
quick beginner guide will be useful.

Concerning image comments (class and methods), people often say that writing a 
comment, a test, a method comment is already an important contribution… and I 
agree
BUT, the process is not easy at all. It is kind of intimidating… It’s for me 
and I don’t consider myself as a « beginner », more a journeyer.

So, I was thinking of something that would be cool and fun to do. The idea 
would be to have an online image « opened » for contribution online. 
ie., a kind of wiki image that exposes all the code of a standard image and 
where we could update class/method comments and eventually create tests.

It shouldn’t be difficult to do with Zinc or whatever. Just to avoid crashes or 
image destruction, it should be limited to simple contributions (comments first 
then tests maybe). Then, a core dev should be able to manage contributions and 
push them in official repositories.

As a side effect, we would have an (another) updated PharoDoc (~JavaDoc) that 
is kind of useless but that newcomers always ask for.

What do you think ? Useful/useless ?
I could give it a shot.

Cheers,

Cédrick


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

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

[Ben Coman]

On 5 December 2017 at 14:50, Stephane Ducasse 
wrote:

> On Tue, Dec 5, 2017 at 5:49 AM, horrido  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
>

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

[Stephane Ducasse]

On Tue, Dec 5, 2017 at 5:49 AM, horrido  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
>

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

[Stephane Ducasse]

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

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

[Ben Coman]

On 4 December 2017 at 12:15, horrido  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

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

[horrido]

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

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

[Offray Vladimir Luna Cárdenas]

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

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

[Dimitris Chloupis]

e of what can be done if you build-*on*: it was
>> built on Moose, which is built on Glamorous, which is built on Morphic,
>> which itself is based on a couple of decades work olving the basic problems
>> inherent to UI's and MVC-type UI's in particular. Kendrick itself was
>> written in a very short time when you compare it with other epidemiology
>> programs, *if* you only count the time spent on Kendrick itself. It's an
>> inherently complex problem area, and it's a life or death problem area.
>> That an application capable of working reliably enough to be trusted in
>> that area was built in a short time, because it was built-on a couple of
>> decades of OSS work, is a huge compliment to those who were involved.
>>
>> Unfortunately for me, I wasn't, ☺. But at least I can take advantage of
>> it existence now.
>>
>> Andrew
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -Original Message-
>>
>> *Date*: Fri, 06 Oct 2017 21:18:28 +
>> *Subject*: Re: [Pharo-users] Behold Pharo: The Modern Smalltalk
>> *To*: Any question about pharo is welcome <pharo-users@lists.pharo.org
>> <any%20question%20about%20pharo%20is%20welcome%20%3cpharo-us...@lists.pharo.org%3e>
>> >
>> Reply-to: Any question about pharo is welcome <
>> pharo-users@lists.pharo.org>
>> *From*: Dimitris Chloupis <kilon.al...@gmail.com
>> <dimitris%20chloupis%20%3ckilon.al...@gmail.com%3e>>
>> 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.hobb...@gmail.com> wrote:
>>
>> Behold Pharo: The Modern Smalltalk
>> <
>> https://medium.com/smalltalk-talk/behold-pharo-the-modern-smalltalk-38e132c46053
>> >
>>
>> 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
>>
>>
>>

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

[Offray Vladimir Luna Cárdenas]

Hi,


On 13/10/17 19:39, Andrew Glynn wrote:
> Pharo is a great OSS Smalltalk, IMHO by the best to date (Squeak
> was/is good, but the LaF was never professional enough for it to be
> taken as seriously as it deserves, it just looks too much like a toy
> although in reality it's very powerful). Having the capability to
> build-on a reliable, attractive and enjoyable base without signing
> over my great-grand-child's first born is fantastic, and a great
> achievement for those who accomplished it.

What is the LaF ?

Cheers,

Offray

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

[Dimitris Chloupis]

I don’t care about Python vs Pharo debate. I love both I use both.

My ultimate goal is to unite the two under a single Uber powerful live
coding environment part of my project Atlas. With direct mapping between
Pharo and Python objects and no compromises. A workflow that will be
seamless that you won’t know if you use Python or Pharo libraries as the
Atlas environment will allow you to work with both languages in a symbiotic
relationship.

That was a dream of mine that I did not dear to reveal now slowly and
steadily becomes reality.

I am extending the live coding environment of python and later will tackle
the subject of a python image format.

Already Atlas can use python libraries from Pharo but that’s about it , but
after this revelation I can move to stage 2 of full synchronization between
Python and Pharo. Even now Atlas allows you to use Pharo syntax to fully
access Python libraries. But integration is skin deep and is what is going
to improve the next years.

So it seems something good came out of this very long discussion. Atlas is
going for a big update. This thread has been a huge inspiration for me.
Super excited :)

On Sat, 14 Oct 2017 at 03:40, Andrew Glynn <aglyn...@gmail.com> wrote:

> The first language I played with, I was nearly 5, was a live environment,
> Forth. I used it on an old PDP my mother had bought that was being
> surplused at the company she worked at. I used Forth until I was in my
> early teens, it was far superior to the BASIC that most other kids I knew
> who knew any programming used. It wasn't Smalltalk, but in many of the
> areas it was used (production automation is one major area), the language
> that most often replaced it *was* Smalltalk.
>
> The biggest difference, for me, as I wrote in the article the other day,
> is the ability to build-on rather than build-with, which in turn is based
> on the environment being written in itself. Ruby *looks* very much like
> Smalltalk, but it *works* like Java; Python works *more* like Smalltalk,
> and it's a much better live environment than Java or Ruby, because more of
> it is written in itself, but too much of Python is written in C, and that
> causes problems. If the code that interprets/compiles your code follows the
> same rules, the machine code it generates will usually also follow the same
> rules, and those rules/restrictions are, for the most part, designed to
> make code more reliable.
>
> As well, RVM has proven Smalltalk (specifically Squeak / Pharo, though
> admittedly an older version) can scale to 1024 cores nearly linearly.
>
> Python has a decent developer base but it's almost all OSS and almost all
> on Linux. Very few applications in Python are in areas where reliability is
> absolutely necessary, or even all that important.  Like Smalltalk, it's a
> general purpose language in a niche, but the niches are very different. For
> years, decades really, any good version of Smalltalk cost an arm and a leg
> (some of them both of each), and as a result it tended to be used only
> where things really *had* to work.
>
> Pharo is a great OSS Smalltalk, IMHO by the best to date (Squeak was/is
> good, but the LaF was never professional enough for it to be taken as
> seriously as it deserves, it just looks too much like a toy although in
> reality it's very powerful). Having the capability to build-on a reliable,
> attractive and enjoyable base without signing over my great-grand-child's
> first born is fantastic, and a great achievement for those who accomplished
> it.
>
> Kendrick is an example of what can be done if you build-*on*: it was
> built on Moose, which is built on Glamorous, which is built on Morphic,
> which itself is based on a couple of decades work olving the basic problems
> inherent to UI's and MVC-type UI's in particular. Kendrick itself was
> written in a very short time when you compare it with other epidemiology
> programs, *if* you only count the time spent on Kendrick itself. It's an
> inherently complex problem area, and it's a life or death problem area.
> That an application capable of working reliably enough to be trusted in
> that area was built in a short time, because it was built-on a couple of
> decades of OSS work, is a huge compliment to those who were involved.
>
> Unfortunately for me, I wasn't, ☺. But at least I can take advantage of it
> existence now.
>
> Andrew
>
>
>
>
>
>
>
>
>
> -Original Message-
>
> *Date*: Fri, 06 Oct 2017 21:18:28 +
> *Subject*: Re: [Pharo-users] Behold Pharo: The Modern Smalltalk
> *To*: Any question about pharo is welcome <pharo-users@lists.pharo.org
> <any%20question%20about%20pharo%20is%20welcome%20%3cpharo-us...@lists.pharo.org%3e>
> >
> Reply-to: Any question about pharo is welcome <pharo-users@lists.

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

[Andrew Glynn]

The first language I played with, I was nearly 5, was a live
environment, Forth.  I used it on an old PDP my mother had bought that
was being surplused at the company she worked at.  I used Forth until I
was in my early teens, it was far superior to the BASIC that most other
kids I knew who knew any programming used.  It wasn't Smalltalk, but in
many of the areas it was used (production automation is one major
area), the language that most often replaced it was Smalltalk.  
The biggest difference, for me, as I wrote in the article the other
day, is the ability to build-on rather than build-with, which in turn
is based on the environment being written in itself. Ruby looks very
much like Smalltalk, but it works like Java; Python works more like
Smalltalk, and it's a much better live environment than Java or Ruby,
because more of it is written in itself, but too much of Python is
written in C, and that causes problems. If the code that
interprets/compiles your code follows the same rules, the machine code
it generates will usually also follow the same rules, and those
rules/restrictions are, for the most part, designed to make code more
reliable. 
As well, RVM has proven Smalltalk (specifically Squeak / Pharo, though
admittedly an older version) can scale to 1024 cores nearly linearly.  
Python has a decent developer base but it's almost all OSS and almost
all on Linux. Very few applications in Python are in areas where
reliability is absolutely necessary, or even all that important.  Like
Smalltalk, it's a general purpose language in a niche, but the niches
are very different. For years, decades really, any good version of
Smalltalk cost an arm and a leg (some of them both of each), and as a
result it tended to be used only where things really had to work.  
Pharo is a great OSS Smalltalk, IMHO by the best to date (Squeak was/is
good, but the LaF was never professional enough for it to be taken as
seriously as it deserves, it just looks too much like a toy although in
reality it's very powerful). Having the capability to build-on a
reliable, attractive and enjoyable base without signing over my great-
grand-child's first born is fantastic, and a great achievement for
those who accomplished it.
Kendrick is an example of what can be done if you build-on:  it was
built on Moose, which is built on Glamorous, which is built on Morphic,
which itself is based on a couple of decades work olving the basic
problems inherent to UI's and MVC-type UI's in particular.  Kendrick
itself was written in a very short time when you compare it with other
epidemiology programs, if you only count the time spent on Kendrick
itself.  It's an inherently complex problem area, and it's a life or
death problem area. That an application capable of working reliably
enough to be trusted in that area was built in a short time, because it
was built-on a couple of decades of OSS work, is a huge compliment to
those who were involved.  
Unfortunately for me, I wasn't, ☺.  But at least I can take advantage
of it existence now.
Andrew








-Original Message-
Date: Fri, 06 Oct 2017 21:18:28 +Subject: Re: [Pharo-users] Behold
Pharo: The Modern SmalltalkTo: Any question about pharo is welcome Reply-to: Any question about pharo is welcome
From: Dimitris Chloupis 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 
wrote:
> Behold Pharo: The Modern 

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

[Nicolai Hess]

2017-10-13 22:04 GMT+02:00 Andrew Glynn <aglyn...@gmail.com>:

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

and who did you quote ?



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

I can not see what is wrong here.
You are problably confused by
- the value of a *variable*
- and the value an *object* represents (its object state)
the first can not be changed for a final variables
the last can only be preserved, if the object is immutable.



> There are also numerous issues around type erasure
>

... this seems a bit off topic


> I'd rather have *no* API documentation than documentation of the sort
> represented by the Java API doc.
>

I  think a java api doc like documentation would help.
For newcomers, that not yet know ( or know how to find) the in-image help.
And even so we can easily browse our code with comments and class comments,
an API-doc could provide the help from a different view (group by
collaboration rather
then by class hierarchy or packages), give an "overall" view or provide
additional code examples.



> Not that I think it's all
> intentional, though perhaps the primitives and scalars that are in fact
> objects
>

How are java primitives "in fact" objects ? They are "in fact" primitives.
This is different from
smalltakl where some *objects* like Smallinteger are implemented as
primitives (or immediates)
but still objects on the (smalltalk) code level.


> 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  us...@lists.pharo.org>
> From: Nicolai Hess <nicolaih...@gmail.com>
>
>
> Am 13.10.2017 5:50 PM schrieb "Andrew Glynn" <aglyn...@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
>
>
>
>

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

[Dimitris Chloupis]

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.

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

[Andrew Glynn]

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 
From: Nicolai Hess <nicolaih...@gmail.com>


Am 13.10.2017 5:50 PM schrieb "Andrew Glynn" <aglyn...@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

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

[Nicolai Hess]

Am 13.10.2017 5:50 PM schrieb "Andrew Glynn" :

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

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

[Andrew Glynn]

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 From:
Offray Vladimir Luna Cárdenas 
  

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

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

[Vitor Medina Cruz]

I completely agree with Ben.

As for Dimitris, I have some points:

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

I think you are missing one point here: people get used to Windows, using
windows with all it’s quirks and nonsenses became strong reinforced habits
for most people, and that is something REALLY hard change.

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

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

[Andrew Glynn]

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 

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

[Dimitris Chloupis]

> 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 

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

[Ben Coman]

On Wed, Oct 11, 2017 at 10:39 PM, Offray Vladimir Luna Cárdenas <
offray.l...@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

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

[Stephane Ducasse]

On Mon, Oct 9, 2017 at 2:45 PM, horrido  wrote:
> Hey, guys, I'm mentioned in this  O'Reilly newsletter
> 
> !!! All because of the Pharo article.
>
> I wonder, is my campaign /actually/ succeeding? If so, I can die happy. ;-)

Great!
But do not die yet we have more to do :).

Stef

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

[Brad]

Plus, namespaces are difficult to implement. It could tear your class library 
to pieces 

Brad Selfridge
913-269-2385

> On Oct 12, 2017, at 9:10 AM, Dimitris Chloupis  wrote:
> 
> 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  
>> 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
>> 

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

[Dimitris Chloupis]

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

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

[Sean P. DeNigris]

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

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

[horrido]

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

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

[Dimitris Chloupis]

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

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

[stephan]

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

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

[Dimitris Chloupis]

That's definetly not a wrong view point, but neither is python's , its all
about context. Who you are ? What you want do ? What live coding means to
you ? How you want to use it ? How much you want to use it? etc

If you want to do Pharo coding the pharo way , then Pharo is your No1
choice, but if you want to Pharo coding the python way , Python is your No1
choice and  etc.

Thus I never pick sides in language wars , I am participating merely to
find things I do not know. Like I just found about become in the VM list,
though I still wait for enumarion of classes and reified frame stacks to be
explained as well.

I am here to learn as much I am here to teach. Well ok , more likely to
learn :D

For example messages vs method calls. What happens if method calls are
executing by reference, does that make them cross message territory?.
Meaning you use a name to hide the reference to an object of a method. You
change the reference to the method but without changing the name of the
call. Or what happens when you extend the MethodObject to cross message
territory, is this still "bastardised OOP" or Alan's Keay great regret of
naming it "OOP" ? OR is it smalltalkish OOP in python , or is it something
more ?

Those question do fascinate me.Languages are so fluid, its like clay in our
hands. We live in very exciting times.

On Thu, Oct 12, 2017 at 11:08 AM Nicolai Hess  wrote:

> 2017-10-12 9:28 GMT+02:00 Dimitris Chloupis :
>
>>
>>
>>
>>> This is what Smalltalk gives you for free.
>>>
>> Sorrry for being rude but I wll use the two usually heavily annoying
>> word, at least for me :D
>>
>> It depends
>>
>> See there is a problem for Python here. Ideology.
>>
>> The zen of python has been both a joke a serious mantra in the python
>> world . Its a joke because its obviously oversimplify decision making in
>> such a complex subject as language designe but is serious because it
>> clearly illustrates the philosophy of its creator, Guido van Rossum.
>>
>> https://www.python.org/dev/peps/pep-0020/
>>
>>  Guido is not any less of a rock star to Pythoners than Alan Kay is for
>> Smalltalkers. The zen has become so popular that is even included in python
>> implementation and can be fetched as the link says using the "import this"
>> in any implementation of Python. It's the very sould of python as messages
>> and objects are the very soul of Smalltalk.
>>
>> So the problem here is that a live coding enviroment brakes the second
>> rule. "explicit is better than implicit". Because live coding in Pharo and
>> Smaltalk is about replacing old instances with new while keeping the state
>> it non the less an implicit behavior and especially become is a no go
>> scenario for python because not only replaces references to an object it
>> also breaks the references to the other object. Of course the old object is
>> garbage collected and RIP. Python follows this rule very strictly.
>>
>> Thus means that not only that Python will not offer a live coding
>> enviroment in the future as the basis of its implementation . It means it
>> does not want to. It may offer it as part of its extensive library.
>>
>> That also leads us to the inescapable conclusion that nothing comes free,
>> everything has a cost. Because there will be scenarios you dont want to
>> lose your old instances or not affect them at all and instead affect only
>> the classes or maybe you dont even want to do that and want to do something
>> else.
>>
>
>
> Hm, we have our own Pharo Zen, which includes a
> Explicit is better than implicit.
> So we are violating our own (zen)rules :)
>
> in my point of view, live or interactive coding has not much to do with
> explicit or implicit program code.
>
>

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

[Nicolai Hess]

2017-10-12 9:28 GMT+02:00 Dimitris Chloupis :

>
>
>
>> This is what Smalltalk gives you for free.
>>
> Sorrry for being rude but I wll use the two usually heavily annoying word,
> at least for me :D
>
> It depends
>
> See there is a problem for Python here. Ideology.
>
> The zen of python has been both a joke a serious mantra in the python
> world . Its a joke because its obviously oversimplify decision making in
> such a complex subject as language designe but is serious because it
> clearly illustrates the philosophy of its creator, Guido van Rossum.
>
> https://www.python.org/dev/peps/pep-0020/
>
>  Guido is not any less of a rock star to Pythoners than Alan Kay is for
> Smalltalkers. The zen has become so popular that is even included in python
> implementation and can be fetched as the link says using the "import this"
> in any implementation of Python. It's the very sould of python as messages
> and objects are the very soul of Smalltalk.
>
> So the problem here is that a live coding enviroment brakes the second
> rule. "explicit is better than implicit". Because live coding in Pharo and
> Smaltalk is about replacing old instances with new while keeping the state
> it non the less an implicit behavior and especially become is a no go
> scenario for python because not only replaces references to an object it
> also breaks the references to the other object. Of course the old object is
> garbage collected and RIP. Python follows this rule very strictly.
>
> Thus means that not only that Python will not offer a live coding
> enviroment in the future as the basis of its implementation . It means it
> does not want to. It may offer it as part of its extensive library.
>
> That also leads us to the inescapable conclusion that nothing comes free,
> everything has a cost. Because there will be scenarios you dont want to
> lose your old instances or not affect them at all and instead affect only
> the classes or maybe you dont even want to do that and want to do something
> else.
>


Hm, we have our own Pharo Zen, which includes a
Explicit is better than implicit.
So we are violating our own (zen)rules :)

in my point of view, live or interactive coding has not much to do with
explicit or implicit program code.

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

[Dimitris Chloupis]

"one of the reasons that Smalltalk historically has been view as insular,
living in its own world avoid using non-Smalltalk libraries - because the
lose of live coding here is a big impact."

I would not say that Smalltalk is viewed as insular. I would say that
Smallalk is not viewed at all period. Pharo wise the people who introduced
to Pharo have been impressed by it.

The same way most Pharoers prefer pharo libraries to c libraries via UFFI ,
applies to python coders as well.

You think a python coder is eager to leave the comforts of his language,
think again.

In both communities its user with either C experience or motivated to learn
C for personal reasons that use the FFIs or other means to import C code.
Is it an accident that 99% of C wrapped code libraries for Python are
existing C projects ? Some existing for decades and predating Python.

A pure Python developers will be as unlikely to use the FFI as a Pharo
developer, and by developers I mean users not the people who actually
develop Pharo.

So no there is nothing wrong with Smalltalk and Smallalk works with C just
fine.

Python's C API gained quickly reputation among the C people of being easy
to us so Python became the go to language for scripting C. This is also why
Python offered embeding, because back then Python was slooo.

This led Guido to claim that Python may be a great choice for scripting C
project but choice for replacing high performance code. He did not even
intended the language to target anything else than scriptin. Nonetheless
that did not stop the community from pop up like mushrooms high performance
libraries to that extend that nowdays Python is regarded as the second best
choice for high performance computing after C/C++ which if you think about
it sounds kinda insane but non the less wrapped optimised C python
libraries can easily outperform non optimised C/C++ code.  An example being
the emarashing truth that Python strings are faster than C++ strings which
forces C++ coders to use an external library that optimised them called
Boost.

So the real irony is that back then embeding Python was recommended,
nowdays embdeding Python is frown upon. Instead now its recommended to
brake your C project to a library wrapped for Python and import it to
Python.

Its fascinating to see something that started so humble become so ambitious
but that is true power of the community and this is also the true power of
Pharo.

You can let this misconceptions get in the way and think small like
"Python/Pharo cannot do this, or is hard to do" or you can shut up
(something I find hard to do) and just do it.

As I said , we use only 0.001% of the potential of any language out
there.

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

[Dimitris Chloupis]

> This is what Smalltalk gives you for free.
>
Sorrry for being rude but I wll use the two usually heavily annoying word,
at least for me :D

It depends

See there is a problem for Python here. Ideology.

The zen of python has been both a joke a serious mantra in the python world
. Its a joke because its obviously oversimplify decision making in such a
complex subject as language designe but is serious because it clearly
illustrates the philosophy of its creator, Guido van Rossum.

https://www.python.org/dev/peps/pep-0020/

 Guido is not any less of a rock star to Pythoners than Alan Kay is for
Smalltalkers. The zen has become so popular that is even included in python
implementation and can be fetched as the link says using the "import this"
in any implementation of Python. It's the very sould of python as messages
and objects are the very soul of Smalltalk.

So the problem here is that a live coding enviroment brakes the second
rule. "explicit is better than implicit". Because live coding in Pharo and
Smaltalk is about replacing old instances with new while keeping the state
it non the less an implicit behavior and especially become is a no go
scenario for python because not only replaces references to an object it
also breaks the references to the other object. Of course the old object is
garbage collected and RIP. Python follows this rule very strictly.

Thus means that not only that Python will not offer a live coding
enviroment in the future as the basis of its implementation . It means it
does not want to. It may offer it as part of its extensive library.

That also leads us to the inescapable conclusion that nothing comes free,
everything has a cost. Because there will be scenarios you dont want to
lose your old instances or not affect them at all and instead affect only
the classes or maybe you dont even want to do that and want to do something
else.


> So while Python has the flexibility for you to program such a system
> yourself, you don't get it for free like Smalltalk.
>
>
>> So it does have a wide application. Python can give you back the
>> references to and from an object (via gc module) but the problem is that
>> when an object is created its already referenced by many internal stuff so
>> it can get messy soon.
>>
>
> Smalltalk handles this for free.  You need #become:
> https://gbracha.blogspot.com.au/2009/07/miracle-of-become.html
> Note one of the comments links to user code that apparently does the same
> thing in Python.  But again this is Python "allows" you to, not "Python"
> gives it to you, but it could be good enough for you.
>
>

First the python example is not an actual become the way I understand it,
because not only it does not change the references to the object , it
exchanges only the variables not the methods

http://wargle.blogspot.gr/2009/07/smalltalks-become-in-python.html

__CLASS__ is reference to the class object. __DICT__ is a reference to the
instance object dictionary contains basically the names of the variables
but not references to the methods themselves . Which means this wont work
for live coding.

His example works because both classes share the same methods with same
code in them but we know this is the polar opposite of live coding.

You can get references to the modified methods using this code

my_class_ref = (globals()[self.__class__.__name__])
found_methods=[eval("my_class_ref()." +
entry,{'my_class_ref':my_class_ref}) for entry in dir(my_class_ref()) if
eval("type(my_class_ref()." + entry +
").__name__",{'my_class_ref':my_class_ref}) == 'method']

Globals is used to fetch the reference to the class object. eval is used
because names are passed as strings of course and basically eval executes a
string as a collection of python commands and returns its value. In this
case the value is a reference to an object, a method object. Dir returns
all names , including both variables and methods, instance and class,
including all superclasses.

You do then something similar to get the old methods , and then you iterate
checking the names and replacing the references with simple assignments.
You end up with a become that is I would say around , if I brake down the
list comprehension to multiple lines, 20 lines of code.

It wont be still a Smalltalk become but it will support live coding and
live replacement of instance objects.

> Plus Python is not exactly a high performance language ,
>>
>
> We now have this for improved performance...
> https://hal.inria.fr/hal-01152610/file/partialReadBarrier.pdf
>
>
Here come the two ugly words "it depends"

See what the python becomes does is essentially better than the smalltalk
becomes. I know its hard to not throw tomatoes at me but if you take a
closer look at the Elito's paper you linked you will see why.

Python solution really becomes an object to another because its swaps its
contents and not the entity of the object, this includes variables and
methods and the class it points to. By entity here I mean 

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

[Markus Stumptner]

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.  So, to a certain 
degree this may be a trap caused by having the excellent environment.  
The newbie who is not used to it and tries to get somehow organised 
before diving in will be scared off.


(I do realise that this is a matter of the time being available, but the 
fact remains that people coming from the outside may be held back this 
apparent lack of information, even though it is only a lack of 
information external to the image. It's the difference between the 
converted who are already going with the flow and those who want to dip 
a toe into the water.)


On 12/10/17 01:09, Offray Vladimir Luna Cárdenas 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 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 
> 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
> wrote:


> On Oct 10, 2017, at 09:58, horrido
> 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 

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

[Ben Coman]

On Thu, Oct 12, 2017 at 1:08 AM, Dimitris Chloupis 
wrote:

> Yes sorry for not making this clear. I was wrong in this case. A module
> reload will only replace class objects not instance objects. So if you
> create a new instance after the reload it will have the updated version but
> your old instance would not.
>
> I try to test something before I make a claim but in this case I failed
> because I forgot the obvious. The tiny fact I was reinitialising my objects
> in the python project I am currently using live coding, so of course my
> instances were updating instantenously because I was in a loop that was
> recreating them every few milliseconds.
>
> When webwarrior mentioned this it draw my supisions and I tested it
> outside my code in the interpreter and it became obvious I was wrong. This
> why my reply I dont claim he is wrong and I am talking about injecting
> methods to old objects.
>
> I have no problem admitting when I am wrong but in this case maybe I was
> not clear enough considering I am responsible for exploding this thread , I
> hope in a good way.
>
> So yes its possible to do in Python but no it is not coming already
> available to you, so you can restrain yourself from abandoning Pharo for
> Python ;)
>
> Python is not there yet. I still keep the opinion that is easy to do ,
> method injection is just regular assignment, you cannot get any easier than
> assignment but this means you have to keep track of the instances of a
> class and replace their methods.
>

This is what Smalltalk gives you for free.


> The good news is that if you replace just the methods and not the entire
> object , you can keep the references to the old instance because keeping
> track of the references as well would be trickier. So this way you would
> not brake your references and having to rebuild them to point to a new
> instance because you continue to use the old instance but with updated
> methods. You can do this also with adding / removing / editing variables
> and/or methods.
>

So while Python has the flexibility for you to program such a system
yourself, you don't get it for free like Smalltalk.


> So it does have a wide application. Python can give you back the
> references to and from an object (via gc module) but the problem is that
> when an object is created its already referenced by many internal stuff so
> it can get messy soon.
>

Smalltalk handles this for free.  You need #become:
https://gbracha.blogspot.com.au/2009/07/miracle-of-become.html
Note one of the comments links to user code that apparently does the same
thing in Python.  But again this is Python "allows" you to, not "Python"
gives it to you, but it could be good enough for you.


> Plus Python is not exactly a high performance language ,
>

We now have this for improved performance...
https://hal.inria.fr/hal-01152610/file/partialReadBarrier.pdf


> unless you use third party libraries focusing on performance (basically C
> libraries wrapped for Python).
>

And how does such C libraries impact your live coding?  Its not longer
turtles all the way down (or its turtles walking off a cliff)
Of course, the same applies for FFI with Pharo, and one of the reasons that
Smalltalk historically has been view as insular, living in its own world
avoid using non-Smalltalk libraries - because the lose of live coding here
is a big impact.

cheers -ben




> In my case its easy to do because I care about live coding my own project
> and do not care about code outside of it, because I wont be changing it
> anyway. But if I had to do this the Pharo way , providing a full live
> enviroment it would be easy because I would have to find a mechanism to
> accomodate for tons of Python code that does not follow live coding
> standards by a long margin. So my goal is not to come up with full blown
> live coding enviroment like Pharo does, that is simply not possible because
> there is like a ton of python code out there and I am sure there so many
> scenarios that live coding in python can go wrong that I am not even aware
> of. But if live code is only for my code and my code alone , I dont think I
> will have any major issues. Afterall even when I use Pharo I use live
> coding strictly for my code and rarely touch the enviroment with the
> exception of once messing with UI theme classes.
>
> But then again I am so new to this that at any point I may come up for a
> solution about this too, who knows :)
>
> On Wed, Oct 11, 2017 at 7:05 PM Pierce Ng  wrote:
>
>> On Sat, Oct 07, 2017 at 01:41:17AM +, Dimitris Chloupis wrote:
>> > execution. Hence live coding, the Python VM replaces objects lively.
>> Python
>> > can also compile any size of code including individual methods.
>> > That happens with one line of code importlib.reload(mymodule)
>>
>> AFAIK in Python when you modify and reload source, existing instances are
>> not
>> "reshaped" to the modified code. Not live enough. Of course with Python
>> 

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

[Dimitris Chloupis]

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

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

[Dimitris Chloupis]

major mistake i meant to say
"providing a full live enviroment it would NOT  be easy because I would
have to find a mechanism to accomodate for tons of Python code that does
not follow live coding standards "

On Wed, Oct 11, 2017 at 8:08 PM Dimitris Chloupis 
wrote:

> Yes sorry for not making this clear. I was wrong in this case. A module
> reload will only replace class objects not instance objects. So if you
> create a new instance after the reload it will have the updated version but
> your old instance would not.
>
> I try to test something before I make a claim but in this case I failed
> because I forgot the obvious. The tiny fact I was reinitialising my objects
> in the python project I am currently using live coding, so of course my
> instances were updating instantenously because I was in a loop that was
> recreating them every few milliseconds.
>
> When webwarrior mentioned this it draw my supisions and I tested it
> outside my code in the interpreter and it became obvious I was wrong. This
> why my reply I dont claim he is wrong and I am talking about injecting
> methods to old objects.
>
> I have no problem admitting when I am wrong but in this case maybe I was
> not clear enough considering I am responsible for exploding this thread , I
> hope in a good way.
>
> So yes its possible to do in Python but no it is not coming already
> available to you, so you can restrain yourself from abandoning Pharo for
> Python ;)
>
> Python is not there yet. I still keep the opinion that is easy to do ,
> method injection is just regular assignment, you cannot get any easier than
> assignment but this means you have to keep track of the instances of a
> class and repace their methods. The good news is that if you replace just
> the methods and not the entire object , you can keep the references to the
> old instance because keeping track of the references as well would be
> trickier. So this way you would not brake your references and having to
> rebuild them to point to a new instance because you continue to use the old
> instance but with updated methods. You can do this also with adding /
> removing / editing variables and/or methods. So it does have a wide
> application. Python can give you back the references to and from an object
> (via gc module) but the problem is that when an object is created its
> already referenced by many internal stuff so it can get messy soon. Plus
> Python is not exactly a high performance language , unless you use third
> party libraries focusing on performance (basically C libraries wrapped for
> Python).
>
> In my case its easy to do because I care about live coding my own project
> and do not care about code outside of it, because I wont be changing it
> anyway. But if I had to do this the Pharo way , providing a full live
> enviroment it would be easy because I would have to find a mechanism to
> accomodate for tons of Python code that does not follow live coding
> standards by a long margin. So my goal is not to come up with full blown
> live coding enviroment like Pharo does, that is simply not possible because
> there is like a ton of python code out there and I am sure there so many
> scenarios that live coding in python can go wrong that I am not even aware
> of. But if live code is only for my code and my code alone , I dont think I
> will have any major issues. Afterall even when I use Pharo I use live
> coding strictly for my code and rarely touch the enviroment with the
> exception of once messing with UI theme classes.
>
> But then again I am so new to this that at any point I may come up for a
> solution about this too, who knows :)
>
> On Wed, Oct 11, 2017 at 7:05 PM Pierce Ng  wrote:
>
>> On Sat, Oct 07, 2017 at 01:41:17AM +, Dimitris Chloupis wrote:
>> > execution. Hence live coding, the Python VM replaces objects lively.
>> Python
>> > can also compile any size of code including individual methods.
>> > That happens with one line of code importlib.reload(mymodule)
>>
>> AFAIK in Python when you modify and reload source, existing instances are
>> not
>> "reshaped" to the modified code. Not live enough. Of course with Python
>> objects
>> it is easy to add per-instance inst-vars, but still this needs to be
>> scripted
>> and doesn't come free with the programming environment.
>>
>> Pierce
>>
>>

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

[Dimitris Chloupis]

Yes sorry for not making this clear. I was wrong in this case. A module
reload will only replace class objects not instance objects. So if you
create a new instance after the reload it will have the updated version but
your old instance would not.

I try to test something before I make a claim but in this case I failed
because I forgot the obvious. The tiny fact I was reinitialising my objects
in the python project I am currently using live coding, so of course my
instances were updating instantenously because I was in a loop that was
recreating them every few milliseconds.

When webwarrior mentioned this it draw my supisions and I tested it outside
my code in the interpreter and it became obvious I was wrong. This why my
reply I dont claim he is wrong and I am talking about injecting methods to
old objects.

I have no problem admitting when I am wrong but in this case maybe I was
not clear enough considering I am responsible for exploding this thread , I
hope in a good way.

So yes its possible to do in Python but no it is not coming already
available to you, so you can restrain yourself from abandoning Pharo for
Python ;)

Python is not there yet. I still keep the opinion that is easy to do ,
method injection is just regular assignment, you cannot get any easier than
assignment but this means you have to keep track of the instances of a
class and repace their methods. The good news is that if you replace just
the methods and not the entire object , you can keep the references to the
old instance because keeping track of the references as well would be
trickier. So this way you would not brake your references and having to
rebuild them to point to a new instance because you continue to use the old
instance but with updated methods. You can do this also with adding /
removing / editing variables and/or methods. So it does have a wide
application. Python can give you back the references to and from an object
(via gc module) but the problem is that when an object is created its
already referenced by many internal stuff so it can get messy soon. Plus
Python is not exactly a high performance language , unless you use third
party libraries focusing on performance (basically C libraries wrapped for
Python).

In my case its easy to do because I care about live coding my own project
and do not care about code outside of it, because I wont be changing it
anyway. But if I had to do this the Pharo way , providing a full live
enviroment it would be easy because I would have to find a mechanism to
accomodate for tons of Python code that does not follow live coding
standards by a long margin. So my goal is not to come up with full blown
live coding enviroment like Pharo does, that is simply not possible because
there is like a ton of python code out there and I am sure there so many
scenarios that live coding in python can go wrong that I am not even aware
of. But if live code is only for my code and my code alone , I dont think I
will have any major issues. Afterall even when I use Pharo I use live
coding strictly for my code and rarely touch the enviroment with the
exception of once messing with UI theme classes.

But then again I am so new to this that at any point I may come up for a
solution about this too, who knows :)

On Wed, Oct 11, 2017 at 7:05 PM Pierce Ng  wrote:

> On Sat, Oct 07, 2017 at 01:41:17AM +, Dimitris Chloupis wrote:
> > execution. Hence live coding, the Python VM replaces objects lively.
> Python
> > can also compile any size of code including individual methods.
> > That happens with one line of code importlib.reload(mymodule)
>
> AFAIK in Python when you modify and reload source, existing instances are
> not
> "reshaped" to the modified code. Not live enough. Of course with Python
> objects
> it is easy to add per-instance inst-vars, but still this needs to be
> scripted
> and doesn't come free with the programming environment.
>
> Pierce
>
>

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

[Pierce Ng]

On Sat, Oct 07, 2017 at 01:41:17AM +, Dimitris Chloupis wrote:
> execution. Hence live coding, the Python VM replaces objects lively. Python
> can also compile any size of code including individual methods.
> That happens with one line of code importlib.reload(mymodule)

AFAIK in Python when you modify and reload source, existing instances are not
"reshaped" to the modified code. Not live enough. Of course with Python objects
it is easy to add per-instance inst-vars, but still this needs to be scripted
and doesn't come free with the programming environment.

Pierce

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

[Offray Vladimir Luna Cárdenas]

Seaside for html live docs browsing seems a good idea. How do you create
something like [1]?:

[1]
http://files.pharo.org/doc/4.0/#packageList=package.html=package/Kernel.html=welcome.html

Cheers,

Offray


On 11/10/17 10:31, Marcus Denker wrote:
>
>
>> On 11 Oct 2017, at 17:18, Thierry Goubier > > 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/Number.class/instance/raisedTo..st
>>
>
> There is http://files.pharo.org/doc/, too. 
>
> Marcus
>

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

[Marcus Denker]

> On 11 Oct 2017, at 17:18, Thierry Goubier  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/Number.class/instance/raisedTo..st
>  
> 
> 

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

Marcus

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

[Sven Van Caekenberghe]

> On 11 Oct 2017, at 17:18, Thierry Goubier  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/Number.class/instance/raisedTo..st

Indeed. Too bad there are plans to put everything in one file (booo) ;-)

> Thierry
> 
> 2017-10-11 17:01 GMT+02:00 Offray Vladimir Luna Cárdenas 
> :
> 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  
>> 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 
>>  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 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  
>>> 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 

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

[Thierry Goubier]

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/Number.class/instance/raisedTo..st

Thierry

2017-10-11 17:01 GMT+02:00 Offray Vladimir Luna Cárdenas <
offray.l...@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 
> 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.l...@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 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 
>>> 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: 

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

[Offray Vladimir Luna Cárdenas]

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

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

[Dimitris Chloupis]

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 
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.l...@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 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 
>> 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 
>>> wrote:
>>>

 > On Oct 10, 2017, at 09:58, horrido  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 

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

[Dimitris Chloupis]

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.l...@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 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 
> 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 
>> wrote:
>>
>>>
>>> > On Oct 10, 2017, at 09:58, horrido  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.
>>> >
>>> >

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

[Offray Vladimir Luna Cárdenas]

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 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
> > 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
> > wrote:
>
>
> > On Oct 10, 2017, at 09:58, horrido
> >
> 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 

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

[Mark Bestley]

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

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

[Dimitris Chloupis]

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 
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 
> wrote:
>
>>
>> > On Oct 10, 2017, at 09:58, horrido  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 

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

[Vitor Medina Cruz]

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  wrote:

>
> > On Oct 10, 2017, at 09:58, horrido  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
> >
>
>

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

[john pfersich]

> On Oct 10, 2017, at 09:58, horrido  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
> 

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

[Dimitris Chloupis]

Yes exactly my post was not an effort to diminish the value of Pharo as
live coding system.

My effort was to reveal my findings because I have been doing a lot of
research lately. I am not keen on abandoning the comforts of Pharo live
coding wise now that I code in Python. But to get to Pharo level there are
many issues to be resolved. I know however that I can get to Pharo level
eventually at least on features I really care about. Because I have little
interest in proving something better from something else. I would not try
this if there were not already a substantial amount of features.

I know that you guys did not know this is possible and I do not think thats
a bad thing because a year ago I did not know that is possible either. It
started as a joke and out of it I created two projects , Atlas and
CPPBridge both 100% Pharo code. With atlas I could have settled with inling
python syntax but I did not because that was easy instead I parsed Pharo
syntax to python syntax to make a deeper integration between Pharo and
Python libraries.

I think how difficult it is depends on how high you put your barrier of
entry, if you go for a full blown live coding system like Pharo has, it
will be difficult because there will be several important issues to
resolve. As you said those language do not follow a strict live coding
workflow. They have live coding features out of need to resolved real time
issues.

Does C has DLLs because it cares about live coding, obviously not, but the
moment you have a library that can at any moment be reloaded you already
made the first step down the path.

When I said you can do hardcore live coding with ease, I meant that you can
live code full time provided you have built some of the functionality. Once
you got a basic library running the rest just flows. But if you want to
complete neck to neck with Pharo it will be a challange because Pharo does
not have live coding feature only at language level but also at IDE level.

Again if people did only the easy stuff, we would not have Pharo would we ,
the fun is in the challenge.

If a python coder should be stop by the lack of a live coding enviroment
should a Pharo be stopped by the lack of namespaces ?

Of course not, languages are there to be extended via third party libraries
and the more we challange ourselved the deeper the understanding becomes
and the more amazing stuff we can do.
On Tue, Oct 10, 2017 at 2:25 PM Sean P. DeNigris 
wrote:

> kilon.alios wrote
> > it’s clear the community is unwilling to deal with such discussions.
>
> I wouldn't say that... after all this thread has the most posts on this
> list
> since January 21 ;) I personally learned a lot and was glad to hear all the
> points. I thought the last two pretty much captured the situation, which is
> that you *can* do live programming in other languages, but the advantage of
> Pharo is that it's *about* live programming. I certainly didn't know it was
> even possible in some of the other languages mentioned. Yet, practically,
> it
> seems extremely difficult for a system that tacks something on as a feature
> to compete with a system that values that thing at its core. Ironically,
> the
> biggest barrier seems to be human, in the McLuhan sense that our medium
> determines how/what we can think/say. I feel lucky to have discovered
> Smalltalk and have cast off (most) of the brain damage from C and C++ ha
> ha.
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
>

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

[Dimitris Chloupis]

No because turing conplete means you have to implement all those live
features yourself, I only gave a taste but I return to Python because thats
the language I know the most, you can live manipulate objects in so many
diffirent ways and mess their structure. Make a method become an instance
variable,and instance variable to a method, rename variables , change the
signature of your methods but only on specific instance or on the class
itself. There is an incredibe large library of object manipulation features
there to be tamed. Pharo can do many of those things and more of course.

Turing complete would apply to me if I said, Python has no live coding
feature, but you can implement those if you want.

Thats not what I am saying. Python or C may not call this live coding, they
call it dynamic libraries, dynamic loading of modules, exceptions , post
mortem debugging (debugger popping up in case of error) , module reloading,
execution time compiling and many more. They never mentions the word "live
coding" , but the features themselves are directly related and very
fundamental requirements for live coding.

Those features exists because live coding is a necessity , there will be
always scenarios that a coder will want to dynamically change something
during execution. There is no big ideology behind it like Pharto , which is
why Pharo is the best at live coding, but rather practical needs that users
requested to be resolved and the devs of languages were forced to implement
them to keep them happy.

For example its possible to extend live coding outside the Pharo image,
using memory mapped files , the Pharo image can be extended not only to
save Pharo live state but also the live state of any C library it depends
on. This is crucial when you open the image and then you find something
does not work because C live state was not storred which is why we have the
session attribute we use to make sure that C libraries are correctly
initialize in image startup.

My CPPBridge which is 100% Pharo project , if you exclude some C examples ,
it provide a basic way of a live coding image that can act as an extension
to the pharo image and include live C state. So yes I have done my hopework.

As a matter of fact each time I hear arguments turing complete wise, I
facepalm myself.

Because its a louse excuse to support a language. Any tool or library that
can save you time its a huge deal.

On Tue, Oct 10, 2017 at 12:40 PM Denis Kudriashov 
wrote:

> Hi Dimitris.
>
> You opinion about live programming reminds me the common sentence from
> developers who don't care about languages at all. Usual argument is: they
> all are Turing complete, so who cares.
>
> 2017-10-10 11:02 GMT+02:00 webwarrior :
>
>> Calm your tits, dude. No need to use Caps Lock that much :-)
>>
>> I made no value judgements in my post, letting readers decide for
>> themselves.
>> Nor did I attribute any claims to you. Except "live coding in Python is
>> easy", which you did say in some earlier posts.
>>
>> > My post were not made to pick a fight but rather to inform and demolish
>> > the wrong assumptions that other languages CANNOT DO live coding.
>>
>> Well, many of them kinda can.
>> But you see, when live coding is an afterthought, problems appear here and
>> there, and some of them are unsolvable. Up to the point that it's easier
>> to
>> do traditional development process and not bother with live coding at all.
>>
>> It's almost like saying that you can do point-free style functional
>> programming in Python.
>> Of course you can (to some extent).  There is even a library for that
>> (https://pypi.python.org/pypi/pointfree/).
>> I there much sense in it? I don't think so.
>>
>>
>>
>>
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>>
>>
>

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

[Dimitris Chloupis]

Nothing is unresovable, some problems will require a lot of more hacking
sure, but Pharo VM is implemented in C (yeah I know it suppose to be
smalltalk but is actually slang compiled to C) and since everything out
there uses C anything out there can do live coding. You can do it in
billlion diffirent ways.The question of course is then how easy to do.

The answer to that is usual answer as in all things, it depends.

But yes it easier indeed to do traditional level coding because lets say
face, you have to be aware of the benefits of live coding and you have to
really try it beforehand. Plus the idea of having to move a finger to make
live coding work properly on the language of choice is less than appealing
to most developers.

Take for example your instance update problem, you can resolve it 2 ways,
python allows you to copy the data of an instance to another in a form of a
dictionary or you can exchange live methods between old a new instances in
frankenstein way. You also find references and replace them real time
keeping track of their object ids. I lately got an idea about a time
machine live coding, live coding that does not keep alive the current data
and execution but also old data and execution and allows you go backwards
in time. I am inspired by implementation of backward debugging and some
demos I have seen where data was visualised as it evolved with the ability
to move it back in time.

This is something that no language I am aware of , including Pharo offers.

I am the weirdo researching live coding because after being introduced to
Pharo my appetite severely increased. Pharo opened to me a world that never
knew it existed. As a resulte I know learn more about language features
related to live coding that I never thought it was possible.

I implement my own live coding library because I want to learn more about
live coding and if possible improve on it but without messing with VMs.  I
hope I bring some of those features back into Pharo as my giift for
introducing me to such a fun way of coding.

On Tue, Oct 10, 2017 at 12:03 PM webwarrior  wrote:

> Calm your tits, dude. No need to use Caps Lock that much :-)
>
> I made no value judgements in my post, letting readers decide for
> themselves.
> Nor did I attribute any claims to you. Except "live coding in Python is
> easy", which you did say in some earlier posts.
>
> > My post were not made to pick a fight but rather to inform and demolish
> > the wrong assumptions that other languages CANNOT DO live coding.
>
> Well, many of them kinda can.
> But you see, when live coding is an afterthought, problems appear here and
> there, and some of them are unsolvable. Up to the point that it's easier to
> do traditional development process and not bother with live coding at all.
>
> It's almost like saying that you can do point-free style functional
> programming in Python.
> Of course you can (to some extent).  There is even a library for that
> (https://pypi.python.org/pypi/pointfree/).
> I there much sense in it? I don't think so.
>
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
>

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

[Stephane Ducasse]

On Tue, Oct 10, 2017 at 3:58 PM, horrido  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
>

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

[Stephane Ducasse]

Which reminds me a guy that I tried to convince that become: is not
the same as changeClassToThatOf: but he was super smart and knew so
this is written in his super smart paper and I smile still now
thinking about it.



On Tue, Oct 10, 2017 at 11:39 AM, Denis Kudriashov  wrote:
> Hi Dimitris.
>
> You opinion about live programming reminds me the common sentence from
> developers who don't care about languages at all. Usual argument is: they
> all are Turing complete, so who cares.
>
> 2017-10-10 11:02 GMT+02:00 webwarrior :
>>
>> Calm your tits, dude. No need to use Caps Lock that much :-)
>>
>> I made no value judgements in my post, letting readers decide for
>> themselves.
>> Nor did I attribute any claims to you. Except "live coding in Python is
>> easy", which you did say in some earlier posts.
>>
>> > My post were not made to pick a fight but rather to inform and demolish
>> > the wrong assumptions that other languages CANNOT DO live coding.
>>
>> Well, many of them kinda can.
>> But you see, when live coding is an afterthought, problems appear here and
>> there, and some of them are unsolvable. Up to the point that it's easier
>> to
>> do traditional development process and not bother with live coding at all.
>>
>> It's almost like saying that you can do point-free style functional
>> programming in Python.
>> Of course you can (to some extent).  There is even a library for that
>> (https://pypi.python.org/pypi/pointfree/).
>> I there much sense in it? I don't think so.
>>
>>
>>
>>
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>>
>

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

[Stephane Ducasse]

Webwarrior I can tell you that you made my day :)
Thanks for this great testimony.

Today we discuss about Pablo because he has a working system being
able to upload hot
code and migrate instance but also the code on the stack.

We will see if we integrate it in Pharo but I want the best hot code
loader ever and be able to update the updater while running the
updater.

Then we want to have a context aware version of this one where you can
apply a change that break the UI and revert it.

Stef


On Mon, Oct 9, 2017 at 7:05 PM, webwarrior  wrote:
> kilon.alios wrote
>> Care to explain what difficulty you experienced in live coding with
>> Python.
>> Or what Pharo can do that Python can’t live code wise ? Maybe I will learn
>> something.
>
> It's funny that one of main reasons why I discovered and started using Pharo
> was failure to get live coding working for Python (Jython in particular).
>
> And now time after time kilon.alios states that live coding in Python is
> "easy" and no big deal.
>
> I will tell you, Pharoers, about code reloading in Python, and let you
> decide for yourselves how it compares to Pharo.
>
>
> Out of the box in Python you can execute some Python code and reload modules
> with reload() function.
>
> What reload() does is it reads code from file (in Python each source file
> corresponds to module), executes it, and replaces reference to [that module]
> in current module.
> From that moment, any code in current module, when referencing reloaded
> module, will point to new version of it.
>
> All implicitly imported names will (like from foo import bar, from foo
> import *, etc.) will point to old version. Also all other modules except
> current will not be affected.
>
> There are, however, third-party libraries, that take care of it.
>
> But that's not all. All instances and subclasses of old classes will point
> to old versions of classes.
> To counter that, instead of replacing old module you could replace its
> contents by newer variables/functions and patch classes by replacing their
> contents.
> Some third-party libraries do that.
>
> That's still not all. If you store references to functions/methods/classes,
> that references will point to old versions.
> reimport library takes care of that, but it uses implementation-specific
> feature of CPython's GC, which lets you get all references to some object.
> Unfortunately, it doesn't work in Jython, and probably in other alternative
> Python implementations.
>
> But wait, what if you rename a class or function, or change its base
> class(-es)?
> You're out of luck. Theoretically you could handle such change if recent
> code change consists of a single rename, but that's it.
>
> I may have missed some other edge cases and haven't talked about tools
> support, but I hope you get the idea.
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>

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

[p...@highoctane.be]

A Bluebook updated picture would be great. And I am sure Roassal could
produce it right away.

Phil

On Oct 10, 2017 15:58, "horrido"  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.
>
>
>
> 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
>
>
>

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

[horrido]

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

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

[Sean P. DeNigris]

kilon.alios wrote
> it’s clear the community is unwilling to deal with such discussions.

I wouldn't say that... after all this thread has the most posts on this list
since January 21 ;) I personally learned a lot and was glad to hear all the
points. I thought the last two pretty much captured the situation, which is
that you *can* do live programming in other languages, but the advantage of
Pharo is that it's *about* live programming. I certainly didn't know it was
even possible in some of the other languages mentioned. Yet, practically, it
seems extremely difficult for a system that tacks something on as a feature
to compete with a system that values that thing at its core. Ironically, the
biggest barrier seems to be human, in the McLuhan sense that our medium
determines how/what we can think/say. I feel lucky to have discovered
Smalltalk and have cast off (most) of the brain damage from C and C++ ha ha.



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

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

[Denis Kudriashov]

Hi Dimitris.

You opinion about live programming reminds me the common sentence from
developers who don't care about languages at all. Usual argument is: they
all are Turing complete, so who cares.

2017-10-10 11:02 GMT+02:00 webwarrior :

> Calm your tits, dude. No need to use Caps Lock that much :-)
>
> I made no value judgements in my post, letting readers decide for
> themselves.
> Nor did I attribute any claims to you. Except "live coding in Python is
> easy", which you did say in some earlier posts.
>
> > My post were not made to pick a fight but rather to inform and demolish
> > the wrong assumptions that other languages CANNOT DO live coding.
>
> Well, many of them kinda can.
> But you see, when live coding is an afterthought, problems appear here and
> there, and some of them are unsolvable. Up to the point that it's easier to
> do traditional development process and not bother with live coding at all.
>
> It's almost like saying that you can do point-free style functional
> programming in Python.
> Of course you can (to some extent).  There is even a library for that
> (https://pypi.python.org/pypi/pointfree/).
> I there much sense in it? I don't think so.
>
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
>

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

[webwarrior]

Calm your tits, dude. No need to use Caps Lock that much :-)

I made no value judgements in my post, letting readers decide for
themselves.
Nor did I attribute any claims to you. Except "live coding in Python is
easy", which you did say in some earlier posts.

> My post were not made to pick a fight but rather to inform and demolish
> the wrong assumptions that other languages CANNOT DO live coding. 

Well, many of them kinda can.
But you see, when live coding is an afterthought, problems appear here and
there, and some of them are unsolvable. Up to the point that it's easier to
do traditional development process and not bother with live coding at all.

It's almost like saying that you can do point-free style functional
programming in Python.
Of course you can (to some extent).  There is even a library for that
(https://pypi.python.org/pypi/pointfree/).
I there much sense in it? I don't think so.




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

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

[Dimitris Chloupis]

And not to worry I won’t bother with discussing such issues again it’s
clear the community is unwilling to deal with such discussions. I have no
problem with that , it’s a free world.
On Tue, 10 Oct 2017 at 03:41, Dimitris Chloupis 
wrote:

> I never claimed that Python , which refers to CPython to the vast majority
> of python coders, is offering live coding out of the box. The fact that you
> have to reload modules manually would make such claims ridiculous.
>
> From the very first post I was crystal clear that there is a need for
> creating a library that handles live coding for you and gave general
> instructions of what this library will have to do.
>
> My claim is that Python and other languages CAN do live coding.
>
> I NEVER claimed also that Python is a live coding environment which it
> stores in an image format. In short Python IS NOT Pharo. Period.
>
> Can python reload modules ? Yes
> Can python trigger the debugger in case of error ? Yes
> Can python replace methods and variables during execution ? Yes
> Can python recompile individual methods and classes and replace their
> previous instances ? Yes
> Can python make you coffee ? Nope
> Etc etc
>
> Depending how deep you want to go live coding wise your live coding
> library will enlarge.
>
> From my experience around  100 lines of code are enough to offer most of
> Pharo’s basic live coding functionality. Such task that needs to happen
> only once and then simply reused in each project that wants to utilize live
> coding , for my standards it is easy. It won’t be easy for a beginner
> python coder cause he may not even know what OOP is. So obviously I am
> referring to experienced coders. It won’t be easy if you want to fully
> replicate Pharo’s live coding capabilities , because you will Definetly go
> way beyond 100 lines.
>
>
> I stated this before and I will state this again Pharo IS HANDS DOWN THE
> BEST LIVE CODING ENVIRONMENT I have ever used.
>
> My point is that other languages CAN do what Pharo does. Even though they
> are NOT live coding environments. They just have the features to be live
> coding environments.
>
> Jython has had a lot of problems using CPython libraries, live coding is
> the least of its problems. This is the reason CPython has almost the
> monopoly of python coding.
>
> I just don’t like it when other languages are illustrated as garbage and
> Pharo as the holy grail. They all have their pros and cons.
>
> Can’t help with Jython , I used it on the premise that I may need Java
> libraries, I ended up finding what I wanted in CPython and have not touched
> it since.
>
> My post were not made to pick a fight but rather to inform and demolish
> the wrong assumptions that other languages CANNOT DO live coding.
>
>
> If we are to compare them the least we can do is do it in a fair and
> sincere way.
> On Mon, 9 Oct 2017 at 20:06, webwarrior  wrote:
>
>> kilon.alios wrote
>> > Care to explain what difficulty you experienced in live coding with
>> > Python.
>> > Or what Pharo can do that Python can’t live code wise ? Maybe I will
>> learn
>> > something.
>>
>> It's funny that one of main reasons why I discovered and started using
>> Pharo
>> was failure to get live coding working for Python (Jython in particular).
>>
>> And now time after time kilon.alios states that live coding in Python is
>> "easy" and no big deal.
>>
>> I will tell you, Pharoers, about code reloading in Python, and let you
>> decide for yourselves how it compares to Pharo.
>>
>>
>> Out of the box in Python you can execute some Python code and reload
>> modules
>> with reload() function.
>>
>> What reload() does is it reads code from file (in Python each source file
>> corresponds to module), executes it, and replaces reference to [that
>> module]
>> in current module.
>> From that moment, any code in current module, when referencing reloaded
>> module, will point to new version of it.
>>
>> All implicitly imported names will (like from foo import bar, from foo
>> import *, etc.) will point to old version. Also all other modules except
>> current will not be affected.
>>
>> There are, however, third-party libraries, that take care of it.
>>
>> But that's not all. All instances and subclasses of old classes will point
>> to old versions of classes.
>> To counter that, instead of replacing old module you could replace its
>> contents by newer variables/functions and patch classes by replacing their
>> contents.
>> Some third-party libraries do that.
>>
>> That's still not all. If you store references to
>> functions/methods/classes,
>> that references will point to old versions.
>> reimport library takes care of that, but it uses implementation-specific
>> feature of CPython's GC, which lets you get all references to some object.
>> Unfortunately, it doesn't work in Jython, and probably in other
>> alternative
>> Python implementations.
>>
>> But wait, what if you rename a class or function, or change its 

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

[Dimitris Chloupis]

I never claimed that Python , which refers to CPython to the vast majority
of python coders, is offering live coding out of the box. The fact that you
have to reload modules manually would make such claims ridiculous.

>From the very first post I was crystal clear that there is a need for
creating a library that handles live coding for you and gave general
instructions of what this library will have to do.

My claim is that Python and other languages CAN do live coding.

I NEVER claimed also that Python is a live coding environment which it
stores in an image format. In short Python IS NOT Pharo. Period.

Can python reload modules ? Yes
Can python trigger the debugger in case of error ? Yes
Can python replace methods and variables during execution ? Yes
Can python recompile individual methods and classes and replace their
previous instances ? Yes
Can python make you coffee ? Nope
Etc etc

Depending how deep you want to go live coding wise your live coding library
will enlarge.

>From my experience around  100 lines of code are enough to offer most of
Pharo’s basic live coding functionality. Such task that needs to happen
only once and then simply reused in each project that wants to utilize live
coding , for my standards it is easy. It won’t be easy for a beginner
python coder cause he may not even know what OOP is. So obviously I am
referring to experienced coders. It won’t be easy if you want to fully
replicate Pharo’s live coding capabilities , because you will Definetly go
way beyond 100 lines.


I stated this before and I will state this again Pharo IS HANDS DOWN THE
BEST LIVE CODING ENVIRONMENT I have ever used.

My point is that other languages CAN do what Pharo does. Even though they
are NOT live coding environments. They just have the features to be live
coding environments.

Jython has had a lot of problems using CPython libraries, live coding is
the least of its problems. This is the reason CPython has almost the
monopoly of python coding.

I just don’t like it when other languages are illustrated as garbage and
Pharo as the holy grail. They all have their pros and cons.

Can’t help with Jython , I used it on the premise that I may need Java
libraries, I ended up finding what I wanted in CPython and have not touched
it since.

My post were not made to pick a fight but rather to inform and demolish the
wrong assumptions that other languages CANNOT DO live coding.


If we are to compare them the least we can do is do it in a fair and
sincere way.
On Mon, 9 Oct 2017 at 20:06, webwarrior  wrote:

> kilon.alios wrote
> > Care to explain what difficulty you experienced in live coding with
> > Python.
> > Or what Pharo can do that Python can’t live code wise ? Maybe I will
> learn
> > something.
>
> It's funny that one of main reasons why I discovered and started using
> Pharo
> was failure to get live coding working for Python (Jython in particular).
>
> And now time after time kilon.alios states that live coding in Python is
> "easy" and no big deal.
>
> I will tell you, Pharoers, about code reloading in Python, and let you
> decide for yourselves how it compares to Pharo.
>
>
> Out of the box in Python you can execute some Python code and reload
> modules
> with reload() function.
>
> What reload() does is it reads code from file (in Python each source file
> corresponds to module), executes it, and replaces reference to [that
> module]
> in current module.
> From that moment, any code in current module, when referencing reloaded
> module, will point to new version of it.
>
> All implicitly imported names will (like from foo import bar, from foo
> import *, etc.) will point to old version. Also all other modules except
> current will not be affected.
>
> There are, however, third-party libraries, that take care of it.
>
> But that's not all. All instances and subclasses of old classes will point
> to old versions of classes.
> To counter that, instead of replacing old module you could replace its
> contents by newer variables/functions and patch classes by replacing their
> contents.
> Some third-party libraries do that.
>
> That's still not all. If you store references to functions/methods/classes,
> that references will point to old versions.
> reimport library takes care of that, but it uses implementation-specific
> feature of CPython's GC, which lets you get all references to some object.
> Unfortunately, it doesn't work in Jython, and probably in other alternative
> Python implementations.
>
> But wait, what if you rename a class or function, or change its base
> class(-es)?
> You're out of luck. Theoretically you could handle such change if recent
> code change consists of a single rename, but that's it.
>
> I may have missed some other edge cases and haven't talked about tools
> support, but I hope you get the idea.
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
>

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

[webwarrior]

kilon.alios wrote
> Care to explain what difficulty you experienced in live coding with
> Python.
> Or what Pharo can do that Python can’t live code wise ? Maybe I will learn
> something.

It's funny that one of main reasons why I discovered and started using Pharo
was failure to get live coding working for Python (Jython in particular).

And now time after time kilon.alios states that live coding in Python is
"easy" and no big deal.

I will tell you, Pharoers, about code reloading in Python, and let you
decide for yourselves how it compares to Pharo.


Out of the box in Python you can execute some Python code and reload modules
with reload() function.

What reload() does is it reads code from file (in Python each source file
corresponds to module), executes it, and replaces reference to [that module]
in current module.
>From that moment, any code in current module, when referencing reloaded
module, will point to new version of it. 

All implicitly imported names will (like from foo import bar, from foo
import *, etc.) will point to old version. Also all other modules except
current will not be affected.

There are, however, third-party libraries, that take care of it.

But that's not all. All instances and subclasses of old classes will point
to old versions of classes.
To counter that, instead of replacing old module you could replace its
contents by newer variables/functions and patch classes by replacing their
contents.
Some third-party libraries do that.

That's still not all. If you store references to functions/methods/classes,
that references will point to old versions.
reimport library takes care of that, but it uses implementation-specific
feature of CPython's GC, which lets you get all references to some object.
Unfortunately, it doesn't work in Jython, and probably in other alternative
Python implementations.

But wait, what if you rename a class or function, or change its base
class(-es)?
You're out of luck. Theoretically you could handle such change if recent
code change consists of a single rename, but that's it.

I may have missed some other edge cases and haven't talked about tools
support, but I hope you get the idea.



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

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

[horrido]

Hey, guys, I'm mentioned in this  O'Reilly newsletter

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

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

[Dimitris Chloupis]

Indeed if you google "live coding" you get a lot of audio visual related
tools. I have to confess because I am working with graphics, live coding is
pretty much bread and butter of my workflow , cannot imagine myself working
without it.

When you step out of audio visual and other live performance arts you
barely see "live coding" mentioned if not at all. The only exception I know
is RunRev's LiveCode , similar to Pharo in the general idea, used to be
closed source but now there is an open source version and Apple's Swift's
Playgrounds which were inspired by a Smalltalk like demo.

Fragmantation is indeed an issue with all programming languages including
Pharo but on the other hand is a necessarily evil for innovation because my
experience is that where there is unity there is also stagnation of
progress but this enters philosophical ground I rather not venture into.

On Sat, Oct 7, 2017 at 6:18 PM Offray Vladimir Luna Cárdenas <
offray.l...@mutabit.com> wrote:

> I think that there are some communities that are more receptive of live
> coding, beyond programmers. Scientist, journalists, hacktivists, data
> visualizers, musicians, come to mind and I have a better experience and
> more openness to live coding with them that with the "classical
> programmer/coder". With our recent Data Journalism Handbook, adaptation in
> Grafoscopio [1] and our recurrent Data Week hackathon+workshops[2], we're
> trying to reach new audiences and communities.
> [1] http://mutabit.com/repos.fossil/mapeda/
> [2] http://mutabit.com/dataweek/
>
> Cheers,
>
> Offray
>
>
> On 07/10/17 07:40, Dimitris Chloupis wrote:
>
> Yes I agree with this
>
> Pharo is a live coding BASED enviroment. For Pharo live coding is not just
> an easy to use feature it based its entire mentality around the idea of
> live coding.
>
> Even though Smalltalk borrowed live coding and image format from Lisp we
> are more "pure" in that regard even compared to Lisp.
>
> But one thing to note here is that live coding is not really that useful
> when used always. At least for me I rely a lot on it for debugging and
> experimenting. But when I work based on a plan , or code just works I do
> not care so much about it.
>
> So my workflow in the end is semi-live coding because I dont feel I need
> live coding 24/7 to be super productive.
>
> Of course that creates some barriers in the end when tools are not made to
> work 24/7 on a live coding context. To that extend Pharo is definetly
> superior and a true live coding enviroment.
>
> You are suprised that you can do live coding in C++ but I was trully
> shocked.
>
> My saga to do live coding in C++ started as a joke, something to use to
> mock C++ ugliness and weakness. But oh boy it did slap it back to my face.
>
> The process is again simple, you wrap eveything inside a main loop,and
> call in this loop functions (C has no objects obvious) or methods if you
> use C++ from DLLs. Those DLLs obviously contain 99.9% of your code. Because
> a DLL can be reloaded it allows you not to stop executing and replace code
> on the fly. The main loop is wrapped inside an exception to make sure the
> an error will never crash your application, C/C++ exceptions are more
> powerful than Pharo live coding in that regard because in Pharo if you do
> anything bad with UFFI and crash it , it will crash for sure.
>
> If you keep the DLL small and  you use tons of small dlls your compile
> times will be almost instantenous. You can also with very view lines detect
> date signature change in source file and trigger background compilation.
> Again few lines of code. The last mountain is live state, in this case the
> executable pass a single pointer and instead of the executable handling the
> memory its actually the dlls that handle it but the executable because it
> cannot crash or exit will keep the live state running. You can also use
> memory mapped file to store live state as they perform pure memory dumps.
>
> All in all you will end up with 100 lines of code that can be wrapped into
> a library and reused in the next project with zero setup. Its an one time
> pain.
>
> Will I would recommend C++ over Pharo for live coding  helll no
> C++ obviously misses a hugely important live coding ingredient which is
> reflection. We do live coding because we want to interact with those
> objects ask questions about what is going on and why our code does not work
> as intended
>
> However Python has no such limitation following a very similar design to
> Smalltalk and being much more powerful language than C++. Python follow
> very closely the Smalltalk paradigm even though there is not a single
> mention of Smalltalk , anywhere in the Python community or of live coding.
>
> Live coding in C++ has become a huge deal in game development mainly
> because game development tend to want to change things on the fly and games
> are so big with extremely long compile times. Unreal has made a huge deal
> over its ability to hot reload C++  

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

[Offray Vladimir Luna Cárdenas]

Ok. Glad to help. In the thread I mentioned some of the specific
difficulties I had implementing Grafoscopio's idea in Python[1] (in one
word: fragmentation, of technologies and computing paradigms)

[1]
http://mutabit.com/offray/static/blog/output/posts/grafoscopio-idea-and-initial-progress.html

Cheers,

Offray


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

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

[Offray Vladimir Luna Cárdenas]

I think that there are some communities that are more receptive of live
coding, beyond programmers. Scientist, journalists, hacktivists, data
visualizers, musicians, come to mind and I have a better experience and
more openness to live coding with them that with the "classical
programmer/coder". With our recent Data Journalism Handbook, adaptation
in Grafoscopio [1] and our recurrent Data Week hackathon+workshops[2],
we're trying to reach new audiences and communities.

[1] http://mutabit.com/repos.fossil/mapeda/
[2] http://mutabit.com/dataweek/

Cheers,

Offray

On 07/10/17 07:40, Dimitris Chloupis wrote:
> Yes I agree with this
>
> Pharo is a live coding BASED enviroment. For Pharo live coding is not
> just an easy to use feature it based its entire mentality around the
> idea of live coding.
>
> Even though Smalltalk borrowed live coding and image format from Lisp
> we are more "pure" in that regard even compared to Lisp. 
>
> But one thing to note here is that live coding is not really that
> useful when used always. At least for me I rely a lot on it for
> debugging and experimenting. But when I work based on a plan , or code
> just works I do not care so much about it. 
>
> So my workflow in the end is semi-live coding because I dont feel I
> need live coding 24/7 to be super productive. 
>
> Of course that creates some barriers in the end when tools are not
> made to work 24/7 on a live coding context. To that extend Pharo is
> definetly superior and a true live coding enviroment.
>
> You are suprised that you can do live coding in C++ but I was trully
> shocked. 
>
> My saga to do live coding in C++ started as a joke, something to use
> to mock C++ ugliness and weakness. But oh boy it did slap it back to
> my face. 
>
> The process is again simple, you wrap eveything inside a main loop,and
> call in this loop functions (C has no objects obvious) or methods if
> you use C++ from DLLs. Those DLLs obviously contain 99.9% of your
> code. Because a DLL can be reloaded it allows you not to stop
> executing and replace code on the fly. The main loop is wrapped inside
> an exception to make sure the an error will never crash your
> application, C/C++ exceptions are more powerful than Pharo live coding
> in that regard because in Pharo if you do anything bad with UFFI and
> crash it , it will crash for sure. 
>
> If you keep the DLL small and  you use tons of small dlls your compile
> times will be almost instantenous. You can also with very view lines
> detect date signature change in source file and trigger background
> compilation. Again few lines of code. The last mountain is live state,
> in this case the executable pass a single pointer and instead of the
> executable handling the memory its actually the dlls that handle it
> but the executable because it cannot crash or exit will keep the live
> state running. You can also use memory mapped file to store live state
> as they perform pure memory dumps. 
>
> All in all you will end up with 100 lines of code that can be wrapped
> into a library and reused in the next project with zero setup. Its an
> one time pain. 
>
> Will I would recommend C++ over Pharo for live coding  helll
> no C++ obviously misses a hugely important live coding ingredient
> which is reflection. We do live coding because we want to interact
> with those objects ask questions about what is going on and why our
> code does not work as intended
>
> However Python has no such limitation following a very similar design
> to Smalltalk and being much more powerful language than C++. Python
> follow very closely the Smalltalk paradigm even though there is not a
> single mention of Smalltalk , anywhere in the Python community or of
> live coding.
>  
> Live coding in C++ has become a huge deal in game development mainly
> because game development tend to want to change things on the fly and
> games are so big with extremely long compile times. Unreal has made a
> huge deal over its ability to hot reload C++  code in its editor ,
> though I do not like its approach so much.
>
> Bottom line is yes its easy and simple to do live coding in other
> languages, not recommended so much in C++ because of its static
> compiled nature and lack of reflection but for dynamic language like
> Python it can come pretty close and I speak from experience. 
>
> At least I have not found something in Python that made me wish I was
> live  coding in Pharo so far, but then yes I still think its better to
> have a full blown live coding. Also from my limited understanding I
> have figured out that pretty much every language out there allows for
> reloading code which is pretty much a very large requirement for live
> coding. 
>
> So yes you can live code to an extend, lesser in languages like C++ ,
> more so in language like Python, Ruby etc. Can you get the Pharo
> experience ? In a dynamic language with the creation of a live coding
> library you could get pretty close but never exactly the same.
>
> 

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

[Dimitris Chloupis]

Well I was refering to live coding itself, but you are correct, I have not
tried combining with literate coding hence why I was curious about the
difficulties you ecountered. I did not know that you focused so much
Grafoscopio on iterate coding. Thanks for enlighting me.

I never implied that Python was easier in everything compared to Pharo.
Afterall kinda misses a huge chunk which is the IDE itself.

There lies the challange of live coding as I initially said that we each
use it in a diffirent way. Thanks for the link also very enlighting and it
is what i wanted, an actual use case.

On Sat, Oct 7, 2017 at 5:49 PM Offray Vladimir Luna Cárdenas <
offray.l...@mutabit.com> wrote:

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

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

[Offray Vladimir Luna Cárdenas]

On 06/10/17 21:00, Dimitris Chloupis wrote:
> Again very generic statements , and I see you refer to tools and
> libraries instead of OOP. We talking here Pharo vs Python on the
> language level because Python obviously does not come with an IDE. But
> then Pharo does not come with literate programming tools or libraries
> as well.

No. We were talking about things "that Pharo can do that Python can't do
or is most difficult". And, for me that includes the (community &
computing) environment provided by Pharo that allow you to go from and
idea to its implementation. In my case the idea was to provide an
experience which mix outlining (a la Leo Editor) with literate computing
(a la Jupyter, IPython) [1]. Even if the original pieces where already
there in Python, mixing them was a nighmare (at least 3 years ago) and
Pharo was more empowering for going from idea to prototype and now Pharo
has literate *computing* (not literate programming [2]) tools.
Grafoscopio is one of them. GT Documenter, in alpha now, is promising.
You can not have a single document for complex books in Jupyter. You
need to split/storage a single work in a "pile of files" metaphor. You
can, today, with Grafoscopio put a 300 pages long PDF in a single
notebook. So yes, there are things that are more complex in one
technology that in other (of course all computer languages are the same
at enough distance, because all them are Turing complete and all that stuff)

[1]
http://mutabit.com/offray/static/blog/output/posts/on-deepness-and-complexity-of-ipython-documents.html
[2] http://blog.fperez.org/2013/04/literate-computing-and-computational.html

>
> I rather not go down the rabbit hole of third party libraries because
> obviously I cannot participate in a discussion about libraries and
> areas of coding, I know nothing about. Plus Python has countless of
> libraries which makes a very longer discussion even if I was familiar
> with them and Pharo has much less but still quite a lot of libraries
> as well.

One of the advantages of being in a community is learning from others
experiences. You said that in your experience you have not found a place
where Python were more difficult that in Pharo. I have shown that in
*my* experience there are. And agree, is unwise to discuss about places
where one has no experience, when is better to learn from those who have it.

Cheers,

Offray