Re: [Pharo-users] Dynamic Typing > Static Typing? « games.greggman.com

[Sven Van Caekenberghe]

> On 20 Jan 2016, at 08:07, stepharo  wrote:
> 
> What is funny is that in general people do not believe us :).
> So I decided that I do not want to talk with type freaks.

Yes, that was something I forgot to add: it seems that both sides are really 
very different and opposed to each other. I also gave up this discussion. 
Personally, I am very much on the dynamic side, but I understand what typing 
offers. It is just that it does not offer enough: it fixes a small number of 
problems up front for an enormous cost in added code and loss of flexibility.

What was also in the original article is the point that yes, refactoring is a 
bit easier, more correct and more powerful in a static typed language, but you 
need much more refactoring there because of all this extra coding to maintain 
the type constraints (again for little gain).

Now, Common Lisp has, IMHO, the right approach to optional typing: not (so 
much) to catch errors, but specifically to instruct/help the compiler produce 
more efficient code. 

> Stef
> 
> Le 19/1/16 22:09, Sven Van Caekenberghe a écrit :
>> Not that we didn't already know this or that we don't feel like this (else 
>> you wouldn't be here), but it is nice to see a concise description and some 
>> fact based reasoning around this subject:
>> 
>>> http://games.greggman.com/game/dynamic-typing-static-typing/ 
>>> 
>> In summary:
>> 
>> In a dynamically typed language you write (a lot) less code for a shorter 
>> program that is easier and faster to write and debug, which gives you more 
>> time to think about what you are doing, resulting in more reliable programs.
>> 
>> Static typing catches only a (very) small amount of typing errors, that are 
>> just as easy to handle as dynamic typing exceptions, but they are a bit 
>> faster.
>> 
>> Sven
>> 
> 
> 

Re: [Pharo-users] Dynamic Typing > Static Typing? « games.greggman.com

[Thierry Goubier]

Le 20/01/2016 05:53, Martin Bähr a écrit :

Excerpts from Sven Van Caekenberghe's message of 2016-01-19 22:09:44 +0100:

http://games.greggman.com/game/dynamic-typing-static-typing/ 


In a dynamically typed language you write (a lot) less code for a shorter 
program that is easier and faster to write and debug, which gives you more time 
to think about what you are doing, resulting in more reliable programs.

Static typing catches only a (very) small amount of typing errors, that are 
just as easy to handle as dynamic typing exceptions, but they are a bit faster.


if that is the case, then why are people working on typescript, why are both
python and ruby getting optional types?


I see two reasons

- Static typing believers trying to retrofit types into successfull 
dynamic languages, because it is impossible to write software without 
static typing


- Performance: for a compiler, having access to static types makes 
compiling and performance optimisation a lot easier. This is my current 
project (R compilation to heterogeneous targets) and I find that type 
inference over R code is a hard (and interesting) subject.



i think this is a comparison of apples with oranges.
even without typing languages like java, c and c++ are significantly different
from dynamic languages like python, ruby, smalltalk and others.

adding typing to javascript, python and ruby means that we can have our cake
and eat it too.



so i'll wait for this study to be redone in the next decade, to compare typed
with untyped javascript, python and ruby. and only that will show us the real
truth. does adding types, with everything else being equal, really make a
difference, or not?


Will it? We already have meta-publication studies, and I must say that 
even arguments like "static types reduces errors" are not even confirmed.


I now wonder if type inference is even a good idea. I do think that 
having explicit (static) typing has benefits; and having the ability to 
remove those types declarations in specific places (APIs, for example) 
seems to be a bad idea... Ocaml is a good example: large Ocaml systems 
are very hard to extend, because types are often not written in the APIs 
and extension points, and you rely on the IDE to scan the type inference 
results to be able to understand how you are supposed to use a module... 
I would really prefer to have incremental/optional typing to use types 
at API entry points, to document and freeze the code.



btw: the guys at rubyrogues make an interesting argument why lack of typing
works better in smalltalk than it does in ruby:
http://devchat.cachefly.net/rubyrogues/transcript-155-rr-why-ruby-sucks-ruby-rogues.pdf
read page 8 of that transcript.

basically they are saying that because java and c/c++ are compiled they can be
analyzed statically and you can build great refactoring tools for them because
the tools can predict which methods are the same.
and in difference to that smalltalk and lisp only know the code at runtime and
so they can't make those predictions. but they make up for that because they
are always running. there is no such thing as not runtime. you can simply ask
the system about its state, like find out which object in the whole system
would respond to a particular message. and in ruby you can't do either of those.


This is an interesting argument, except that if you had a correct model 
of the code set, being able to run it doesn't seems as mandatory to 
reason on it. Now, maybe Ruby need a Ring like implementation?



disclaimer: for the last 20 years, my main programming language has been pike,
a dynamic language like smalltalk, but with declarative typing. (it's optional,
in the sense that you can declare a type as "mixed" which can be anything, so
just like typescript, and how python and ruby will be once they have optional
types)

greetings, martin.


Regards,

Thierry

Re: [Pharo-users] Dynamic Typing > Static Typing? « games.greggman.com

[Dimitris Chloupis]

I am a bit in the middle, I never cared or saw a practical benefit from
static typing and neither I saw a practical benefit from using dynamic
types. So its a matter that has little interest to me , but then I was
never a language orientated person and I cared a lot more about IDEs and
visual coding in general.

However there is no doubt that dynamic types have won the war before the
war started by the fact that in the history of coding at least the last 30
years I have been around we have witnessed 3 great migrations of coders

1) The migration from Assembly to C/C++ and other high level languages
2) The migration from C++ as the dominant force of coding to Java
3) The migration from static types languages to dynamic typed languages

On the matter of python getting optional static typing I can say this and
predict this, static type will never become anywhere as big for python as
generic types are in static type languages and I say that because I have a
good understanding of the python culture.

In the end , does it really matter ? Languages are 99.9% personal
preferences 0.1% practical needs. If you love coding with static types and
you want to use them with your favorite dynamic language , go for it, code
any way you want , if there is one thing that the coding field generally
needs is to brake away from stereotypes , status quo and embrace innovation
and alternative thinking. But I wont hold my breath for that :)

On Wed, Jan 20, 2016 at 11:02 AM Thierry Goubier 
wrote:

> Le 20/01/2016 05:53, Martin Bähr a écrit :
> > Excerpts from Sven Van Caekenberghe's message of 2016-01-19 22:09:44
> +0100:
> >>> http://games.greggman.com/game/dynamic-typing-static-typing/ <
> http://games.greggman.com/game/dynamic-typing-static-typing/>
> >> In a dynamically typed language you write (a lot) less code for a
> shorter program that is easier and faster to write and debug, which gives
> you more time to think about what you are doing, resulting in more reliable
> programs.
> >>
> >> Static typing catches only a (very) small amount of typing errors, that
> are just as easy to handle as dynamic typing exceptions, but they are a bit
> faster.
> >
> > if that is the case, then why are people working on typescript, why are
> both
> > python and ruby getting optional types?
>
> I see two reasons
>
> - Static typing believers trying to retrofit types into successfull
> dynamic languages, because it is impossible to write software without
> static typing
>
> - Performance: for a compiler, having access to static types makes
> compiling and performance optimisation a lot easier. This is my current
> project (R compilation to heterogeneous targets) and I find that type
> inference over R code is a hard (and interesting) subject.
>
> > i think this is a comparison of apples with oranges.
> > even without typing languages like java, c and c++ are significantly
> different
> > from dynamic languages like python, ruby, smalltalk and others.
> >
> > adding typing to javascript, python and ruby means that we can have our
> cake
> > and eat it too.
>
> > so i'll wait for this study to be redone in the next decade, to compare
> typed
> > with untyped javascript, python and ruby. and only that will show us the
> real
> > truth. does adding types, with everything else being equal, really make a
> > difference, or not?
>
> Will it? We already have meta-publication studies, and I must say that
> even arguments like "static types reduces errors" are not even confirmed.
>
> I now wonder if type inference is even a good idea. I do think that
> having explicit (static) typing has benefits; and having the ability to
> remove those types declarations in specific places (APIs, for example)
> seems to be a bad idea... Ocaml is a good example: large Ocaml systems
> are very hard to extend, because types are often not written in the APIs
> and extension points, and you rely on the IDE to scan the type inference
> results to be able to understand how you are supposed to use a module...
> I would really prefer to have incremental/optional typing to use types
> at API entry points, to document and freeze the code.
>
> > btw: the guys at rubyrogues make an interesting argument why lack of
> typing
> > works better in smalltalk than it does in ruby:
> >
> http://devchat.cachefly.net/rubyrogues/transcript-155-rr-why-ruby-sucks-ruby-rogues.pdf
> > read page 8 of that transcript.
> >
> > basically they are saying that because java and c/c++ are compiled they
> can be
> > analyzed statically and you can build great refactoring tools for them
> because
> > the tools can predict which methods are the same.
> > and in difference to that smalltalk and lisp only know the code at
> runtime and
> > so they can't make those predictions. but they make up for that because
> they
> > are always running. there is no such thing as not runtime. you can
> simply ask
> > the system about its state, like find out which object in the whole
> system
> > would respond to a part

[Pharo-users] Updating a project and NIL class variables

[Dimitris Chloupis]

So my question is this , I have a class with nil variables that are lazy
initialised only when needed the first time and of course they keep their
values from there on.

Lets say I get the latest update from github via metacello over an older
update that I already have inside the image , do those variables revert
back to nil values ? or do they keep their values as they are ?

Re: [Pharo-users] Updating a project and NIL class variables

[Sven Van Caekenberghe]

They remain nil.

That is why #initialize on the class side is needed.

You can call that explicitly in a post load script, or rely on the class 
loading mechanism that normally calls #initialize automatically when loading a 
class. The warning is: this only happens when the *source* code of the 
#initialize methods changes. So sometimes, you will have to touch that method 
to force it.

I hope that makes sense.

See MCMethodDefinition>>#postloadOver:

> On 20 Jan 2016, at 13:41, Dimitris Chloupis  wrote:
> 
> So my question is this , I have a class with nil variables that are lazy 
> initialised only when needed the first time and of course they keep their 
> values from there on. 
> 
> Lets say I get the latest update from github via metacello over an older 
> update that I already have inside the image , do those variables revert back 
> to nil values ? or do they keep their values as they are ? 

Re: [Pharo-users] [ANN] OSSubprocess v0.2.0 release

[Hilaire]

https://github.com/marianopeck/OSSubprocess/
-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Updating a project and NIL class variables

[Hilaire]

Is it instance or class variables ?
In both cases, there are unchanged.
If class variables, Sven explain how to reinitialize.

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

Re: [Pharo-users] Updating a project and NIL class variables

[Ben Coman]

On Wed, Jan 20, 2016 at 8:41 PM, Dimitris Chloupis
 wrote:
> So my question is this , I have a class with nil variables that are lazy
> initialised only when needed the first time and of course they keep their
> values from there on.
>
> Lets say I get the latest update from github via metacello over an older
> update that I already have inside the image , do those variables revert back
> to nil values ?

No.

> or do they keep their values as they are ?

Yes.  Loading a package is only loading source code.  Its no different
than manually changing a method's source through the Nautilus system
browser (instance & class variables keep their values throughout)
except you get the whole lot in one go.

cheers -ben

Re: [Pharo-users] Updating a project and NIL class variables

[Dimitris Chloupis]

ok thank you all , its now crystal clear that I need to follow Sven's
approach, or maybe do it manually creating a reset method.

On Wed, Jan 20, 2016 at 4:31 PM Dimitris Chloupis 
wrote:

> Thank you for the info but I think I did not make myself clear because you
> say "remain nil"
>
> Ok Imagine a class SomeClass and that class has a variable we will call
> SomeVariable, class variable that is
> , there is no class initialize method, now that class has a method that is
> eventually called ,
> someMethod
>
> SomeVariable ifNil: [ SomeVariable := 'hello world']
>
> so when I decide to update this class via metacello loading the latest
> version from github ,  SomeVariable will have the value 'hello world'
>
> My question is , will SomeVariable after I do the update revert back to
> nil  or stay 'hello world' ?
>
> If your answer is no, and it stays 'hello world' then yes i need an
> initialize method and call it at update time.
>
> On Wed, Jan 20, 2016 at 2:54 PM Sven Van Caekenberghe 
> wrote:
>
>> They remain nil.
>>
>> That is why #initialize on the class side is needed.
>>
>> You can call that explicitly in a post load script, or rely on the class
>> loading mechanism that normally calls #initialize automatically when
>> loading a class. The warning is: this only happens when the *source* code
>> of the #initialize methods changes. So sometimes, you will have to touch
>> that method to force it.
>>
>> I hope that makes sense.
>>
>> See MCMethodDefinition>>#postloadOver:
>>
>> > On 20 Jan 2016, at 13:41, Dimitris Chloupis 
>> wrote:
>> >
>> > So my question is this , I have a class with nil variables that are
>> lazy initialised only when needed the first time and of course they keep
>> their values from there on.
>> >
>> > Lets say I get the latest update from github via metacello over an
>> older update that I already have inside the image , do those variables
>> revert back to nil values ? or do they keep their values as they are ?
>>
>>
>>

Re: [Pharo-users] Updating a project and NIL class variables

[Sven Van Caekenberghe]

> On 20 Jan 2016, at 15:34, Dimitris Chloupis  wrote:
> 
> Thank you for the info but I think I did not make myself clear because you 
> say "remain nil"
> 
> Ok Imagine a class SomeClass and that class has a variable we will call 
> SomeVariable, class variable that is
> , there is no class initialize method, now that class has a method that is 
> eventually called , 
> someMethod
> 
> SomeVariable ifNil: [ SomeVariable := 'hello world']
> 
> so when I decide to update this class via metacello loading the latest 
> version from github ,  SomeVariable will have the value 'hello world'
> 
> My question is , will SomeVariable after I do the update revert back to nil  
> or stay 'hello world' ? 
> 
> If your answer is no, and it stays 'hello world' then yes i need an 
> initialize method and call it at update time. 

Argh, I should have said: keeps it value, will not revert to nil.

Sorry for the confusion !

> On Wed, Jan 20, 2016 at 2:54 PM Sven Van Caekenberghe  wrote:
> They remain nil.
> 
> That is why #initialize on the class side is needed.
> 
> You can call that explicitly in a post load script, or rely on the class 
> loading mechanism that normally calls #initialize automatically when loading 
> a class. The warning is: this only happens when the *source* code of the 
> #initialize methods changes. So sometimes, you will have to touch that method 
> to force it.
> 
> I hope that makes sense.
> 
> See MCMethodDefinition>>#postloadOver:
> 
> > On 20 Jan 2016, at 13:41, Dimitris Chloupis  wrote:
> >
> > So my question is this , I have a class with nil variables that are lazy 
> > initialised only when needed the first time and of course they keep their 
> > values from there on.
> >
> > Lets say I get the latest update from github via metacello over an older 
> > update that I already have inside the image , do those variables revert 
> > back to nil values ? or do they keep their values as they are ?
> 
> 

Re: [Pharo-users] Updating a project and NIL class variables

[Dimitris Chloupis]

Thank you for the info but I think I did not make myself clear because you
say "remain nil"

Ok Imagine a class SomeClass and that class has a variable we will call
SomeVariable, class variable that is
, there is no class initialize method, now that class has a method that is
eventually called ,
someMethod

SomeVariable ifNil: [ SomeVariable := 'hello world']

so when I decide to update this class via metacello loading the latest
version from github ,  SomeVariable will have the value 'hello world'

My question is , will SomeVariable after I do the update revert back to
nil  or stay 'hello world' ?

If your answer is no, and it stays 'hello world' then yes i need an
initialize method and call it at update time.

On Wed, Jan 20, 2016 at 2:54 PM Sven Van Caekenberghe  wrote:

> They remain nil.
>
> That is why #initialize on the class side is needed.
>
> You can call that explicitly in a post load script, or rely on the class
> loading mechanism that normally calls #initialize automatically when
> loading a class. The warning is: this only happens when the *source* code
> of the #initialize methods changes. So sometimes, you will have to touch
> that method to force it.
>
> I hope that makes sense.
>
> See MCMethodDefinition>>#postloadOver:
>
> > On 20 Jan 2016, at 13:41, Dimitris Chloupis 
> wrote:
> >
> > So my question is this , I have a class with nil variables that are lazy
> initialised only when needed the first time and of course they keep their
> values from there on.
> >
> > Lets say I get the latest update from github via metacello over an older
> update that I already have inside the image , do those variables revert
> back to nil values ? or do they keep their values as they are ?
>
>
>

Re: [Pharo-users] Updating a project and NIL class variables

[Dimitris Chloupis]

no apologies owed, I just asked because I want to make sure Pharo wont do
anything weird behind my back :)

On Wed, Jan 20, 2016 at 4:39 PM Sven Van Caekenberghe  wrote:

>
> > On 20 Jan 2016, at 15:34, Dimitris Chloupis 
> wrote:
> >
> > Thank you for the info but I think I did not make myself clear because
> you say "remain nil"
> >
> > Ok Imagine a class SomeClass and that class has a variable we will call
> SomeVariable, class variable that is
> > , there is no class initialize method, now that class has a method that
> is eventually called ,
> > someMethod
> >
> > SomeVariable ifNil: [ SomeVariable := 'hello world']
> >
> > so when I decide to update this class via metacello loading the latest
> version from github ,  SomeVariable will have the value 'hello world'
> >
> > My question is , will SomeVariable after I do the update revert back to
> nil  or stay 'hello world' ?
> >
> > If your answer is no, and it stays 'hello world' then yes i need an
> initialize method and call it at update time.
>
> Argh, I should have said: keeps it value, will not revert to nil.
>
> Sorry for the confusion !
>
> > On Wed, Jan 20, 2016 at 2:54 PM Sven Van Caekenberghe 
> wrote:
> > They remain nil.
> >
> > That is why #initialize on the class side is needed.
> >
> > You can call that explicitly in a post load script, or rely on the class
> loading mechanism that normally calls #initialize automatically when
> loading a class. The warning is: this only happens when the *source* code
> of the #initialize methods changes. So sometimes, you will have to touch
> that method to force it.
> >
> > I hope that makes sense.
> >
> > See MCMethodDefinition>>#postloadOver:
> >
> > > On 20 Jan 2016, at 13:41, Dimitris Chloupis 
> wrote:
> > >
> > > So my question is this , I have a class with nil variables that are
> lazy initialised only when needed the first time and of course they keep
> their values from there on.
> > >
> > > Lets say I get the latest update from github via metacello over an
> older update that I already have inside the image , do those variables
> revert back to nil values ? or do they keep their values as they are ?
> >
> >
>
>
>

[Pharo-users] Use cases for methods with optional parameters

[Damien Cassou]

Hi,

I would like to study the impact of adding optional parameters to
keyword methods in Pharo. The goal of optional parameters is to
facilitate the implementation of methods where some parameters are
optional. For example, Seaside has:

WAComponent>>request: aRequestString label: aLabelString
 default: aDefaultString onAnswer: aBlock

...

This method of 4 arguments has only 1 required argument (aRequestString)
and 3 optional ones. In the current implementation, this results in 7
additional methods that only delegate directly or indirectly to the one
above:

- request:
- request:default:
- request:default:onAnswer:
- request:label:
- request:label:default:
- request:label:onAnswer:
- request:onAnswer:

Before starting to implement anything, I need to know if it makes sense.
If you want to help me, please send me all the use cases you have by
giving me:

- the library name (and URL if not in Catalog), or "pharo" if it's in
  Pharo
- the class where this happens
- the range of selectors that make sense

For the example above, this would be:

- Seaside
- WAComponent
- request:*


Thank you very much

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

[Pharo-users] [ANN][Invite] Pharo Sprint 29 Jan

[marcus . denker]

We will organize a Pharo sprint / Moose dojo Friday, 11th September, starting at
10:00am. (Local Time Lille).

It will be at the Inria Lille, Building B, third floor (RMoD offices) and
at the University of Chile, Santiago de Chile.

Remotely, you can join us on Slack or the IRC channel #pharo on
irc.freenode.net server. During the sprint, we will try to synchronize
local and remote Pharo sprinters.

As the building is not open to the public, please contact us before if
you plan to come.

Re: [Pharo-users] Dynamic Typing > Static Typing? « games.greggman.com

[Martin Bähr]

Excerpts from Dimitris Chloupis's message of 2016-01-20 12:36:37 +0100:
> we have witnessed 3 great migrations of coders
> 1) The migration from Assembly to C/C++ and other high level languages
> 2) The migration from C++ as the dominant force of coding to Java
> 3) The migration from static types languages to dynamic typed languages

that's a great observation! and you are right, dynamic typed languages have won
and smalltalk and lisp had it right all along.

> On the matter of python getting optional static typing I can say this and
> predict this, static type will never become anywhere as big for python as
> generic types are in static type languages and I say that because I have a
> good understanding of the python culture.

that's a good point too. what i am interested in is the fact that having types
available in these languages, research can finally look for conclusive evidence
of how much advantage types really give, because all other differences between
eg python and c++ are eliminated.

i simply do not believe that any findings about types, by comparing python with
c++ is valid because they are such different beasts of languages.

greetings, martin.

-- 
eKita   -   the online platform for your entire academic life
-- 
chief engineer   eKita.co
pike programmer  pike.lysator.liu.secaudium.net societyserver.org
secretary  beijinglug.org
mentor   fossasia.org
foresight developer  foresightlinux.orgrealss.com
unix sysadmin
Martin Bähr  working in chinahttp://societyserver.org/mbaehr/

Re: [Pharo-users] Dynamic Typing > Static Typing? « games.greggman.com

[Martin Bähr]

Excerpts from Sven Van Caekenberghe's message of 2016-01-20 09:09:00 +0100:
> What was also in the original article is the point that yes, refactoring is a
> bit easier, more correct and more powerful in a static typed language, but
> you need much more refactoring there because of all this extra coding to
> maintain the type constraints (again for little gain).

which extra coding do you mean here? can you give an example?

i once translated code from untyped common lisp to typed pike, and the result 
was
almost identical. there was no extra code whatsoever. the only really difference
was that variables had type declarations.

looking at typescript for example, it has a feature where you can take existing
javascript libraries and add type annotations in a separate file. how would
adding that type information lead to extra code? that simply makes no sense. 

if you talk about extra code in java or c++, then that's because those
languages are different to dynamic languages in many other ways, not just
types.

greetings, martin.

-- 
eKita   -   the online platform for your entire academic life
-- 
chief engineer   eKita.co
pike programmer  pike.lysator.liu.secaudium.net societyserver.org
secretary  beijinglug.org
mentor   fossasia.org
foresight developer  foresightlinux.orgrealss.com
unix sysadmin
Martin Bähr  working in chinahttp://societyserver.org/mbaehr/

Re: [Pharo-users] Dynamic Typing > Static Typing? « games.greggman.com

[Dimitris Chloupis]

indeed python and C++ are not just diffirent but two languages going the
exact opposite directions, Python emphasizing speed of development , C++
emphasizing speed of execution.

In C/C++ every decision must be based upon performance, this not how any
other language works , even Java is not that worried about performance,
sure its important but it is not the main goal.

Hence its not surprising that C++ is the undisputed choice for very
performance orientated fields, like Gaming, audio , science that involves
heavy calculation. Look at python how popular it has become for scientists
but AFTER the fact that so many C++ libraries have been made for python
like numpy/scipy and Blaze.

So you are absolute to say that some people migrate to dynamic languages
not just for dynamic types and is also to say that people stick with C++
and C not because of static types. If that was the case python would not
implement optional static types and C++ would not implement generics.

The important thing to note here is that we no longer at 80 and 90s ,
nowdays you can combine any language with anything else and the vast
majority of projects are written in multiple languages.

I dont agree with the remark "Smalltalk and Lisp were right all along" ,
obviously they were not because the entire world would have been using
smalltalk and lisp which we dont. To claim so is to try to simplify coding
and with every simplification it loses a part of the truth.

On Wed, Jan 20, 2016 at 5:57 PM Martin Bähr <
mba...@email.archlab.tuwien.ac.at> wrote:

> Excerpts from Dimitris Chloupis's message of 2016-01-20 12:36:37 +0100:
> > we have witnessed 3 great migrations of coders
> > 1) The migration from Assembly to C/C++ and other high level languages
> > 2) The migration from C++ as the dominant force of coding to Java
> > 3) The migration from static types languages to dynamic typed languages
>
> that's a great observation! and you are right, dynamic typed languages
> have won
> and smalltalk and lisp had it right all along.
>
> > On the matter of python getting optional static typing I can say this and
> > predict this, static type will never become anywhere as big for python as
> > generic types are in static type languages and I say that because I have
> a
> > good understanding of the python culture.
>
> that's a good point too. what i am interested in is the fact that having
> types
> available in these languages, research can finally look for conclusive
> evidence
> of how much advantage types really give, because all other differences
> between
> eg python and c++ are eliminated.
>
> i simply do not believe that any findings about types, by comparing python
> with
> c++ is valid because they are such different beasts of languages.
>
> greetings, martin.
>
> --
> eKita   -   the online platform for your entire academic
> life
> --
> chief engineer
>  eKita.co
> pike programmer  pike.lysator.liu.secaudium.net
> societyserver.org
> secretary
> beijinglug.org
> mentor
> fossasia.org
> foresight developer  foresightlinux.org
> realss.com
> unix sysadmin
> Martin Bähr  working in china
> http://societyserver.org/mbaehr/
>

Re: [Pharo-users] [ANN][Invite] Pharo Sprint 29 Jan

[Marcus Denker]

> On 20 Jan 2016, at 16:37, marcus.den...@inria.fr wrote:
> 
> 
> We will organize a Pharo sprint / Moose dojo Friday, 11th September, starting 
> at

This is Friday,  29 Jan (next week).

> 10:00am. (Local Time Lille).
> 
> It will be at the Inria Lille, Building B, third floor (RMoD offices) and
> at the University of Chile, Santiago de Chile.
> 
> Remotely, you can join us on Slack or the IRC channel #pharo on
> irc.freenode.net server. During the sprint, we will try to synchronize
> local and remote Pharo sprinters.
> 
> As the building is not open to the public, please contact us before if
> you plan to come.

Re: [Pharo-users] Use cases for methods with optional parameters

[Offray Vladimir Luna Cárdenas]

Hi,

As a newbie, without a clear idea of where to apply this specifically I 
can say that seems pretty interesting. I have methods with several 
parameters (may be product of my newbie code), but making them optional 
seems an idea worthy to explore.


Cheers,

Offray

On 20/01/16 10:08, Damien Cassou wrote:

Hi,

I would like to study the impact of adding optional parameters to
keyword methods in Pharo. The goal of optional parameters is to
facilitate the implementation of methods where some parameters are
optional. For example, Seaside has:

WAComponent>>request: aRequestString label: aLabelString
  default: aDefaultString onAnswer: aBlock

 ...

This method of 4 arguments has only 1 required argument (aRequestString)
and 3 optional ones. In the current implementation, this results in 7
additional methods that only delegate directly or indirectly to the one
above:

- request:
- request:default:
- request:default:onAnswer:
- request:label:
- request:label:default:
- request:label:onAnswer:
- request:onAnswer:

Before starting to implement anything, I need to know if it makes sense.
If you want to help me, please send me all the use cases you have by
giving me:

- the library name (and URL if not in Catalog), or "pharo" if it's in
   Pharo
- the class where this happens
- the range of selectors that make sense

For the example above, this would be:

- Seaside
- WAComponent
- request:*


Thank you very much

Re: [Pharo-users] Updating a project and NIL class variables

[Henrik Nergaard]

“The warning is: this only happens when the *source* code of the #initialize 
methods changes. So sometimes, you will have to touch that method to force it.”

Perhaps there should be an overload able method that decides whether or not to 
initialize the class, such that classes relying on reinitializing  every time a 
change is merged, can do this by simply answering true?


From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
Dimitris Chloupis
Sent: Wednesday, January 20, 2016 3:47 PM
To: Any question about pharo is welcome 
Subject: Re: [Pharo-users] Updating a project and NIL class variables

no apologies owed, I just asked because I want to make sure Pharo wont do 
anything weird behind my back :)

On Wed, Jan 20, 2016 at 4:39 PM Sven Van Caekenberghe 
mailto:s...@stfx.eu>> wrote:

> On 20 Jan 2016, at 15:34, Dimitris Chloupis 
> mailto:kilon.al...@gmail.com>> wrote:
>
> Thank you for the info but I think I did not make myself clear because you 
> say "remain nil"
>
> Ok Imagine a class SomeClass and that class has a variable we will call 
> SomeVariable, class variable that is
> , there is no class initialize method, now that class has a method that is 
> eventually called ,
> someMethod
>
> SomeVariable ifNil: [ SomeVariable := 'hello world']
>
> so when I decide to update this class via metacello loading the latest 
> version from github ,  SomeVariable will have the value 'hello world'
>
> My question is , will SomeVariable after I do the update revert back to nil  
> or stay 'hello world' ?
>
> If your answer is no, and it stays 'hello world' then yes i need an 
> initialize method and call it at update time.

Argh, I should have said: keeps it value, will not revert to nil.

Sorry for the confusion !

> On Wed, Jan 20, 2016 at 2:54 PM Sven Van Caekenberghe 
> mailto:s...@stfx.eu>> wrote:
> They remain nil.
>
> That is why #initialize on the class side is needed.
>
> You can call that explicitly in a post load script, or rely on the class 
> loading mechanism that normally calls #initialize automatically when loading 
> a class. The warning is: this only happens when the *source* code of the 
> #initialize methods changes. So sometimes, you will have to touch that method 
> to force it.
>
> I hope that makes sense.
>
> See MCMethodDefinition>>#postloadOver:
>
> > On 20 Jan 2016, at 13:41, Dimitris Chloupis 
> > mailto:kilon.al...@gmail.com>> wrote:
> >
> > So my question is this , I have a class with nil variables that are lazy 
> > initialised only when needed the first time and of course they keep their 
> > values from there on.
> >
> > Lets say I get the latest update from github via metacello over an older 
> > update that I already have inside the image , do those variables revert 
> > back to nil values ? or do they keep their values as they are ?
>
>

Re: [Pharo-users] Use cases for methods with optional parameters

[Esteban A. Maringolo]

2016-01-20 14:01 GMT-03:00 Offray Vladimir Luna Cárdenas :
> Hi,
>
> As a newbie, without a clear idea of where to apply this specifically I can
> say that seems pretty interesting. I have methods with several parameters
> (may be product of my newbie code), but making them optional seems an idea
> worthy to explore.
>
> Cheers,
>


In a pure object oriented approach, if you have a lot of varying
parameters is a sign that you might need to reify the parameters as a
first class object, i.e. "SomethingParameters" class or similar, then
instead of passing 1...n objects that will work as parameters you only
pass one object, aSomethingParameters.

Of course it adds more friction to something that maybe the language
could provide, but in Smalltalk everything is explicit.

I would be interested in the use cases and how to deal with
"undefined" arguments, will they be nil or other kind of undefined
object?

Regards!

Esteban A. Maringolo

Re: [Pharo-users] Use cases for methods with optional parameters

[Cyril Ferlicot D.]

Le 20/01/2016 16:08, Damien Cassou a écrit :
> Hi,
> 
> I would like to study the impact of adding optional parameters to
> keyword methods in Pharo. The goal of optional parameters is to
> facilitate the implementation of methods where some parameters are
> optional. For example, Seaside has:
> 
> WAComponent>>request: aRequestString label: aLabelString
>  default: aDefaultString onAnswer: aBlock
> 
> ...
> 
> This method of 4 arguments has only 1 required argument (aRequestString)
> and 3 optional ones. In the current implementation, this results in 7
> additional methods that only delegate directly or indirectly to the one
> above:
> 
> - request:
> - request:default:
> - request:default:onAnswer:
> - request:label:
> - request:label:default:
> - request:label:onAnswer:
> - request:onAnswer:
> 
> Before starting to implement anything, I need to know if it makes sense.
> If you want to help me, please send me all the use cases you have by
> giving me:
> 
> - the library name (and URL if not in Catalog), or "pharo" if it's in
>   Pharo
> - the class where this happens
> - the range of selectors that make sense
> 
> For the example above, this would be:
> 
> - Seaside
> - WAComponent
> - request:*
> 
> 
> Thank you very much
> 

Hi Damien,

There is a lot of optional parameters in the UIManager.

Package: UIManager (pharo)

Classes: UIManager and subclasses

Selectors:

- chooseFrom:*
- reguest:*
- …

Almost all the methods have optional parameters.

-- 
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-users] Use cases for methods with optional parameters

[Dimitris Chloupis]

it would certainly save time from navigating through methods that more or
less do the same thing. And of course dummy methods that they are there
just to facilitate for less arguments.

On Wed, Jan 20, 2016 at 7:42 PM Cyril Ferlicot D. 
wrote:

> Le 20/01/2016 16:08, Damien Cassou a écrit :
> > Hi,
> >
> > I would like to study the impact of adding optional parameters to
> > keyword methods in Pharo. The goal of optional parameters is to
> > facilitate the implementation of methods where some parameters are
> > optional. For example, Seaside has:
> >
> > WAComponent>>request: aRequestString label: aLabelString
> >  default: aDefaultString onAnswer: aBlock
> >
> > ...
> >
> > This method of 4 arguments has only 1 required argument (aRequestString)
> > and 3 optional ones. In the current implementation, this results in 7
> > additional methods that only delegate directly or indirectly to the one
> > above:
> >
> > - request:
> > - request:default:
> > - request:default:onAnswer:
> > - request:label:
> > - request:label:default:
> > - request:label:onAnswer:
> > - request:onAnswer:
> >
> > Before starting to implement anything, I need to know if it makes sense.
> > If you want to help me, please send me all the use cases you have by
> > giving me:
> >
> > - the library name (and URL if not in Catalog), or "pharo" if it's in
> >   Pharo
> > - the class where this happens
> > - the range of selectors that make sense
> >
> > For the example above, this would be:
> >
> > - Seaside
> > - WAComponent
> > - request:*
> >
> >
> > Thank you very much
> >
>
> Hi Damien,
>
> There is a lot of optional parameters in the UIManager.
>
> Package: UIManager (pharo)
>
> Classes: UIManager and subclasses
>
> Selectors:
>
> - chooseFrom:*
> - reguest:*
> - …
>
> Almost all the methods have optional parameters.
>
> --
> Cyril Ferlicot
>
> http://www.synectique.eu
>
> 165 Avenue Bretagne
> Lille 59000 France
>
>

Re: [Pharo-users] Dynamic Typing > Static Typing? « games.greggman.com

[Jimmie Houchin]

I will not argue whether or not Smalltalk and Lisp were right all along. 
However, the fact that Smalltalk and Lisp are where they are is not 
simply a matter of technical merit. There were many, many, political 
decisions made by the owners of the technology which participated in its 
successes and failures.


Proprietary, commercial, expensive, and the varying corporate entities 
one had to deal with in order to use this software was a huge factor. Us 
small guys who would want to use this fantastic enabling technology had 
our limitations in acquiring this technology. You had to have money and 
really want to spend it in this manner.


This is not to make derogatory statements about their decisions. But 
they did have an impact. Had the best of Smalltalk and Lisp been open 
sourced 20 to 30 years ago. Would this be a very different world? I 
think so. However, the income and profits of those corporations would 
have been different also. It wasn't our decision to make and we were not 
living in their shoes. We would have to become knowledgeable about the 
economics, the state of the competition, the state of their own 
business, etc. to become even reasonably qualified to judge. Even then 
different people make different decisions because they think differently 
or even possibly are looking for different results. Open source was a 
different and very foreign world back then. It was a very foreign 
thought to open source your intellectual property and believe that you 
could earn a living from it. You do have to think different to be a 
creator of open source software and to be successful at making a living 
from it.


What if Sun put the effort into Strongtalk that they put into Java? 
Where would we be?


I personally believe Smalltalk and Lisp had it right. Own the entire 
environment and machine. Turtles all the way down.


Unfortunately the world isn't so clean. However, we do have a very nice 
open source Smalltalk inspired tool in Pharo. While the past was not in 
our control. We do have a say about the future. :)

Lets make the future great!

Shalom Aleichem

Jimmie

On 01/20/2016 10:13 AM, Dimitris Chloupis wrote:
indeed python and C++ are not just diffirent but two languages going 
the exact opposite directions, Python emphasizing speed of development 
, C++ emphasizing speed of execution.


In C/C++ every decision must be based upon performance, this not how 
any other language works , even Java is not that worried about 
performance, sure its important but it is not the main goal.


Hence its not surprising that C++ is the undisputed choice for very 
performance orientated fields, like Gaming, audio , science that 
involves heavy calculation. Look at python how popular it has become 
for scientists but AFTER the fact that so many C++ libraries have been 
made for python like numpy/scipy and Blaze.


So you are absolute to say that some people migrate to dynamic 
languages not just for dynamic types and is also to say that people 
stick with C++ and C not because of static types. If that was the case 
python would not implement optional static types and C++ would not 
implement generics.


The important thing to note here is that we no longer at 80 and 90s , 
nowdays you can combine any language with anything else and the vast 
majority of projects are written in multiple languages.


I dont agree with the remark "Smalltalk and Lisp were right all along" 
, obviously they were not because the entire world would have been 
using smalltalk and lisp which we dont. To claim so is to try to 
simplify coding and with every simplification it loses a part of the 
truth.


On Wed, Jan 20, 2016 at 5:57 PM Martin Bähr 
> wrote:


Excerpts from Dimitris Chloupis's message of 2016-01-20 12:36:37
+0100:
> we have witnessed 3 great migrations of coders
> 1) The migration from Assembly to C/C++ and other high level
languages
> 2) The migration from C++ as the dominant force of coding to Java
> 3) The migration from static types languages to dynamic typed
languages

that's a great observation! and you are right, dynamic typed
languages have won
and smalltalk and lisp had it right all along.

> On the matter of python getting optional static typing I can say
this and
> predict this, static type will never become anywhere as big for
python as
> generic types are in static type languages and I say that
because I have a
> good understanding of the python culture.

that's a good point too. what i am interested in is the fact that
having types
available in these languages, research can finally look for
conclusive evidence
of how much advantage types really give, because all other
differences between
eg python and c++ are eliminated.

i simply do not believe that any findings about types, by
comparing python with
c++ is valid because they are such different beasts of

Re: [Pharo-users] Updating a project and NIL class variables

[Sven Van Caekenberghe]

> On 20 Jan 2016, at 18:06, Henrik Nergaard  wrote:
> 
> “The warning is: this only happens when the *source* code of the #initialize 
> methods changes. So sometimes, you will have to touch that method to force 
> it.”
> Perhaps there should be an overload able method that decides whether or not 
> to initialize the class, such that classes relying on reinitializing  every 
> time a change is merged, can do this by simply answering true?

Seems like a good idea, to modify the logic in 
MCMethodDefinition>>#postloadOver:

However, I have a feeling that maybe people already have thought/discussed 
about this in the past, maybe we should find out why it was decided to do it 
like this.

A question is also: will the test method only run in the existing image, and/or 
does the incoming code have an influence, because that could require two 
version before an initialiser runs in the worst case (previous version says no, 
incoming says yes).

Just thinking out loud.

> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
> Dimitris Chloupis
> Sent: Wednesday, January 20, 2016 3:47 PM
> To: Any question about pharo is welcome 
> Subject: Re: [Pharo-users] Updating a project and NIL class variables
>  
> no apologies owed, I just asked because I want to make sure Pharo wont do 
> anything weird behind my back :)
>  
> On Wed, Jan 20, 2016 at 4:39 PM Sven Van Caekenberghe  wrote:
> 
> > On 20 Jan 2016, at 15:34, Dimitris Chloupis  wrote:
> >
> > Thank you for the info but I think I did not make myself clear because you 
> > say "remain nil"
> >
> > Ok Imagine a class SomeClass and that class has a variable we will call 
> > SomeVariable, class variable that is
> > , there is no class initialize method, now that class has a method that is 
> > eventually called ,
> > someMethod
> >
> > SomeVariable ifNil: [ SomeVariable := 'hello world']
> >
> > so when I decide to update this class via metacello loading the latest 
> > version from github ,  SomeVariable will have the value 'hello world'
> >
> > My question is , will SomeVariable after I do the update revert back to nil 
> >  or stay 'hello world' ?
> >
> > If your answer is no, and it stays 'hello world' then yes i need an 
> > initialize method and call it at update time.
> 
> Argh, I should have said: keeps it value, will not revert to nil.
> 
> Sorry for the confusion !
> 
> > On Wed, Jan 20, 2016 at 2:54 PM Sven Van Caekenberghe  wrote:
> > They remain nil.
> >
> > That is why #initialize on the class side is needed.
> >
> > You can call that explicitly in a post load script, or rely on the class 
> > loading mechanism that normally calls #initialize automatically when 
> > loading a class. The warning is: this only happens when the *source* code 
> > of the #initialize methods changes. So sometimes, you will have to touch 
> > that method to force it.
> >
> > I hope that makes sense.
> >
> > See MCMethodDefinition>>#postloadOver:
> >
> > > On 20 Jan 2016, at 13:41, Dimitris Chloupis  wrote:
> > >
> > > So my question is this , I have a class with nil variables that are lazy 
> > > initialised only when needed the first time and of course they keep their 
> > > values from there on.
> > >
> > > Lets say I get the latest update from github via metacello over an older 
> > > update that I already have inside the image , do those variables revert 
> > > back to nil values ? or do they keep their values as they are ?
> >
> >
> 

Re: [Pharo-users] Dynamic Typing > Static Typing? « games.greggman.com

[David Allouche]

> On 20 Jan 2016, at 19:27, Jimmie Houchin  wrote:
> 
> I will not argue whether or not Smalltalk and Lisp were right all along. 
> However, the fact that Smalltalk and Lisp are where they are is not simply a 
> matter of technical merit. There were many, many, political decisions made by 
> the owners of the technology which participated in its successes and failures.
> 
> Proprietary, commercial, expensive, and the varying corporate entities one 
> had to deal with in order to use this software was a huge factor. Us small 
> guys who would want to use this fantastic enabling technology had our 
> limitations in acquiring this technology. You had to have money and really 
> want to spend it in this manner.
> 
> This is not to make derogatory statements about their decisions. But they did 
> have an impact. Had the best of Smalltalk and Lisp been open sourced 20 to 30 
> years ago. Would this be a very different world? I think so. However, the 
> income and profits of those corporations would have been different also. It 
> wasn't our decision to make and we were not living in their shoes. We would 
> have to become knowledgeable about the economics, the state of the 
> competition, the state of their own business, etc. to become even reasonably 
> qualified to judge. Even then different people make different decisions 
> because they think differently or even possibly are looking for different 
> results. Open source was a different and very foreign world back then. It was 
> a very foreign thought to open source your intellectual property and believe 
> that you could earn a living from it. You do have to think different to be a 
> creator of open source software and to be successful at making a living from 
> it.
> 
> What if Sun put the effort into Strongtalk that they put into Java? Where 
> would we be?
> 
> I personally believe Smalltalk and Lisp had it right. Own the entire 
> environment and machine. Turtles all the way down.
> 
> Unfortunately the world isn't so clean. However, we do have a very nice open 
> source Smalltalk inspired tool in Pharo. While the past was not in our 
> control. We do have a say about the future. :)
> Lets make the future great!

Well spoken!

Free software became a business enabler thanks to the web. Back then, there was 
no web, no ability to build global communities pushing forward a shared 
artefact. I think that is no coincidence that the oldest language that is still 
mainstream is C, which was used to build Unix, which was used to build the web.

Now, let's do something awesome :-)

Re: [Pharo-users] Use cases for methods with optional parameters

[Hernán Morales Durand]

Hi Damien,

As far as I know this describes the Robert Hirschfeld's Convenience Methods
pattern. I wrote a code generator package which generates this pattern
through an API like this:

CGStConvenienceMethods uniqueInstance
setCleanTarget;
parameterCount: 2;
targetSelector: #cgConvEx2;
addReturn;
targetClassCategory: 'ConvenienceMethodsEx';
targetClass: #ConvenienceMethodsEx;
generateMethods.

That expression generates a class named ConvenienceMethodsEx with 3 methods:

#cgConvEx2
#cgConvEx2with:
#cgConvEx3with:with:

where each method passes nil as default parameter to it's "subsequent"
version (same selector +1 parameter).

Cheers,

Hernán


2016-01-20 12:08 GMT-03:00 Damien Cassou :

> Hi,
>
> I would like to study the impact of adding optional parameters to
> keyword methods in Pharo. The goal of optional parameters is to
> facilitate the implementation of methods where some parameters are
> optional. For example, Seaside has:
>
> WAComponent>>request: aRequestString label: aLabelString
>  default: aDefaultString onAnswer: aBlock
>
> ...
>
> This method of 4 arguments has only 1 required argument (aRequestString)
> and 3 optional ones. In the current implementation, this results in 7
> additional methods that only delegate directly or indirectly to the one
> above:
>
> - request:
> - request:default:
> - request:default:onAnswer:
> - request:label:
> - request:label:default:
> - request:label:onAnswer:
> - request:onAnswer:
>
> Before starting to implement anything, I need to know if it makes sense.
> If you want to help me, please send me all the use cases you have by
> giving me:
>
> - the library name (and URL if not in Catalog), or "pharo" if it's in
>   Pharo
> - the class where this happens
> - the range of selectors that make sense
>
> For the example above, this would be:
>
> - Seaside
> - WAComponent
> - request:*
>
>
> Thank you very much
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Success is the ability to go from one failure to another without
> losing enthusiasm." --Winston Churchill
>
>

Re: [Pharo-users] Generating a binary package like PharoLauncher

[Hernán Morales Durand]

Hi Serge,

I wrote a code generator package with uses Mustache and generates a NSIS
script. As an example:

CGNSISIPharo4AppInstaller uniqueInstance
product: 'MyProduct';
identity: 'MyName';
version: '1.0.0';
url: 'http://www.google.com';
launcher: 'MyLauncher.exe';
licenseEnFileName: 'LICENSE_ENGLISH';
iconFile: 'MyProduct.ico';
welcomeBmpFile: 'MyProduct.bmp';
splashBMPFileName: 'Splash.bmp';
generate.

Maybe that's what you're looking for?

Hernán


2016-01-18 14:23 GMT-03:00 Serge Stinckwich :

> Dear all,
>
> I would like to distribute Kendrick like PharoLauncher, i.e as a
> binary package for mac and windows. Are the script of CI for
> generating PharoLauncher available somewhere ?
>
> Thank you.
> --
> Serge Stinckwich
> UCBN & UMI UMMISCO 209 (IRD/UPMC)
> Every DSL ends up being Smalltalk
> http://www.doesnotunderstand.org/
>
>

[Pharo-users] Cleaning Phao topics

[stepharo]

Hi

I will go over Pharo topics on github and also clean and sync the file 
on the Pharo web site

and I will clean the topics.
I will make a list with the ones that are not clear with no mentors in 
case some people want to rescue
them but this list should be much better and I will clean it with the 
Mooc and future lectures I will

do in mind.

Stef