January 2016 - Pharo-users - lists.pharo.org

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

by 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 < mbaehr(a)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.se caudium.net > societyserver.org > secretary > beijinglug.org > mentor > fossasia.org > foresight developer foresightlinux.org > realss.com > unix sysadmin > Martin BÃ¤hr working in china > http://societyserver.org/mbaehr/ >

Jan. 20, 2016

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

by Marcus Denker

> On 20 Jan 2016, at 16:37, marcus.denker(a)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.

Jan. 20, 2016

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

by 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.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

Jan. 20, 2016

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

by 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.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

Jan. 20, 2016

[ANN][Invite] Pharo Sprint 29 Jan

by marcus.denker＠inria.fr

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.

Jan. 20, 2016

Use cases for methods with optional parameters

by 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

Jan. 20, 2016

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

by 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 <sven(a)stfx.eu> wrote: > > > On 20 Jan 2016, at 15:34, Dimitris Chloupis <kilon.alios(a)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 <sven(a)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 <kilon.alios(a)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 ? > > > > > > >

Jan. 20, 2016

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

by Sven Van Caekenberghe

> On 20 Jan 2016, at 15:34, Dimitris Chloupis <kilon.alios(a)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 <sven(a)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 <kilon.alios(a)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 ? > >

Jan. 20, 2016

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

by 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 <kilon.alios(a)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. > > On Wed, Jan 20, 2016 at 2:54 PM Sven Van Caekenberghe <sven(a)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 <kilon.alios(a)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 ? >> >> >>

Jan. 20, 2016

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

by 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 <sven(a)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 <kilon.alios(a)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 ? > > >

Jan. 20, 2016