El lun, 02-05-2011 a las 22:43 +0200, Igor Stasenko escribió:
> Pharo is end-user application for developers, not for users :) He he, other quote for twitter! -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx |
> El lun, 02-05-2011 a las 22:43 +0200, Igor Stasenko escribió:
>> Pharo is end-user application for developers, not for users :) +1, that's why I prefer Pharo over Squeak. -- Ramon Leon http://onsmalltalk.com |
Hi Igor
?? Shouldn't I be writing Pharo/Seaside apps with it? I am definitely a *user* Of Pharo/Seaside if I do.. Regards Ted On Mon, May 2, 2011 at 10:53 PM, Ramon Leon <[hidden email]> wrote: >> El lun, 02-05-2011 a las 22:43 +0200, Igor Stasenko escribió: >>> >>> Pharo is end-user application for developers, not for users :) > > +1, that's why I prefer Pharo over Squeak. > > -- > Ramon Leon > http://onsmalltalk.com > > |
On 2 May 2011 22:59, Ted F.A. van Gaalen <[hidden email]> wrote:
> Hi Igor > ?? Shouldn't I be writing > Pharo/Seaside apps with it? > I am definitely a *user* Of Pharo/Seaside if I do.. hmm.. i don't know.. i were always thinking that those who writing applications are developers, and those who using applications, who don't understand what program is, what is the code, and how it works are users.. but maybe times had changed and now writing an application no longer means that you are developer, but just some kind of power-user? :) > Regards > Ted > > On Mon, May 2, 2011 at 10:53 PM, Ramon Leon <[hidden email]> wrote: >>> El lun, 02-05-2011 a las 22:43 +0200, Igor Stasenko escribió: >>>> >>>> Pharo is end-user application for developers, not for users :) >> >> +1, that's why I prefer Pharo over Squeak. >> >> -- >> Ramon Leon >> http://onsmalltalk.com >> >> > > -- Best regards, Igor Stasenko AKA sig. |
On Mon, May 2, 2011 at 4:10 PM, Igor Stasenko <[hidden email]> wrote:
> On 2 May 2011 22:59, Ted F.A. van Gaalen <[hidden email]> wrote: >> Hi Igor >> ?? Shouldn't I be writing >> Pharo/Seaside apps with it? >> I am definitely a *user* Of Pharo/Seaside if I do.. > > hmm.. i don't know.. i were always thinking that those who writing > applications are developers, > and those who using applications, who don't understand what program > is, what is the code, and how it works are users.. > but maybe times had changed and now writing an application no longer > means that you are developer, > but just some kind of power-user? :) That seems to fit pretty well with Alan's original ideas about where he wanted smalltalk and the dynabook to go. -- James >> Regards >> Ted |
In reply to this post by Igor Stasenko
Yes, but a bit simplified:
As a "typical application programmer" I consider myself as a "pharo-user" (that is why I am here.) Pharo/Smalltalk I really like as an application development tool. made by people like you (grateful, thanks), who dive deeper in Pharo "itself", so to speak So that is why I come with typical "user" questions and long term thoughts about usability and so on. Simply said: I wont' touch much of the "deeper world" in the image, but put my own application object layer on it. That is so nice about Smalltalk. (not making any money with it, I am outta work at the moment :o| - On Mon, May 2, 2011 at 11:10 PM, Igor Stasenko <[hidden email]> wrote: > On 2 May 2011 22:59, Ted F.A. van Gaalen <[hidden email]> wrote: >> Hi Igor >> ?? Shouldn't I be writing >> Pharo/Seaside apps with it? >> I am definitely a *user* Of Pharo/Seaside if I do.. > > hmm.. i don't know.. i were always thinking that those who writing > applications are developers, > and those who using applications, who don't understand what program > is, what is the code, and how it works are users.. > but maybe times had changed and now writing an application no longer > means that you are developer, > but just some kind of power-user? :) > >> Regards >> Ted >> >> On Mon, May 2, 2011 at 10:53 PM, Ramon Leon <[hidden email]> wrote: >>>> El lun, 02-05-2011 a las 22:43 +0200, Igor Stasenko escribió: >>>>> >>>>> Pharo is end-user application for developers, not for users :) >>> >>> +1, that's why I prefer Pharo over Squeak. >>> >>> -- >>> Ramon Leon >>> http://onsmalltalk.com >>> >>> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > |
Yes, the distinction is blurred,
i am good with OOP but won't dive too deep (i might drown :o) On Mon, May 2, 2011 at 11:34 PM, TedvG TedvG <[hidden email]> wrote: > Yes, but a bit simplified: > As a "typical application programmer" > I consider myself as a "pharo-user" > (that is why I am here.) > Pharo/Smalltalk I really like as an application development tool. > made by people like you (grateful, thanks), who dive > deeper in Pharo "itself", so to speak > So that is why I come with typical "user" questions > and long term thoughts about usability and so on. > Simply said: I wont' touch much of the "deeper world" > in the image, but put my own application object layer > on it. That is so nice about Smalltalk. > (not making any money with it, I am outta work at the moment :o| > > > > - > > On Mon, May 2, 2011 at 11:10 PM, Igor Stasenko <[hidden email]> wrote: >> On 2 May 2011 22:59, Ted F.A. van Gaalen <[hidden email]> wrote: >>> Hi Igor >>> ?? Shouldn't I be writing >>> Pharo/Seaside apps with it? >>> I am definitely a *user* Of Pharo/Seaside if I do.. >> >> hmm.. i don't know.. i were always thinking that those who writing >> applications are developers, >> and those who using applications, who don't understand what program >> is, what is the code, and how it works are users.. >> but maybe times had changed and now writing an application no longer >> means that you are developer, >> but just some kind of power-user? :) >> >>> Regards >>> Ted >>> >>> On Mon, May 2, 2011 at 10:53 PM, Ramon Leon <[hidden email]> wrote: >>>>> El lun, 02-05-2011 a las 22:43 +0200, Igor Stasenko escribió: >>>>>> >>>>>> Pharo is end-user application for developers, not for users :) >>>> >>>> +1, that's why I prefer Pharo over Squeak. >>>> >>>> -- >>>> Ramon Leon >>>> http://onsmalltalk.com >>>> >>>> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> > |
In reply to this post by TedVanGaalen
On May 2, 2011, at 11:46 AM, Ted F.A. van Gaalen wrote:
> On Mon, May 2, 2011 at 7:44 PM, Norbert Hartl <[hidden email]> wrote: >> >> Am 02.05.2011 um 18:49 schrieb Ted F.A. van Gaalen: >> >>> Assume that throughout this all coding are countless >>> references to classes that are perfectly normal at the >>> time of writing. This no exception. >>> >> Well, if you stay in this "time of writing" (meaning same vm, same image) everything should be fine. > > (A) I would always want to move my packages to newer releases because > they [might] have better performance due to more optimized core > classes ?(in addition to the VM performance) You'll want to upgrade to benefit from performance gains that result from removing the cruft and creating a lean and mean core class library? That seems at odds with the "please don't change the core class library" line of thought. Pat |
Hi Pat
E.g. Collection classes: Still use the existing methods like #add: perhaps the internal workings of these methods are further optimized... However I don't have to change any code for this.. Regards Ted On Mon, May 2, 2011 at 11:57 PM, Pat Maddox <[hidden email]> wrote: > On May 2, 2011, at 11:46 AM, Ted F.A. van Gaalen wrote: > >> On Mon, May 2, 2011 at 7:44 PM, Norbert Hartl <[hidden email]> wrote: >>> >>> Am 02.05.2011 um 18:49 schrieb Ted F.A. van Gaalen: >>> >>>> Assume that throughout this all coding are countless >>>> references to classes that are perfectly normal at the >>>> time of writing. This no exception. >>>> >>> Well, if you stay in this "time of writing" (meaning same vm, same image) everything should be fine. >> >> (A) I would always want to move my packages to newer releases because >> they [might] have better performance due to more optimized core >> classes ?(in addition to the VM performance) > > You'll want to upgrade to benefit from performance gains that result from removing the cruft and creating a lean and mean core class library? That seems at odds with the "please don't change the core class library" line of thought. > > Pat > > |
In reply to this post by TedVanGaalen
On 2 May 2011 23:37, TedvG TedvG <[hidden email]> wrote:
> Yes, the distinction is blurred, > i am good with OOP but won't > dive too deep (i might drown :o) You don't have to dive deep. And actually what i like about smalltalk , that it is shallow all the way down. If you know C++ by chance, just take a look at STL implementation , lets say vector: www.sgi.com/tech/stl/stl_vector.h and compare it with implementation which provides similar interface (like Array or OrderedCollection). This makes a HUGE difference. The code in STL library are definitely written not for learning. It is written so that people could use it, but not change it. If you really want to understand STL implementation, it will require from you a lot of time to spend just reading the code and this is only after you finish learning C++ syntax with tons of its rules.. and understanding what is going on there is another story. This code is just beyond a limit of being maintainable. Very small number of people could read it, even less people could understand it, and even less could actually attempt to maintain or improve it. It means that STL is made in stone for eons. For good or bad. But in 100 years you can be sure that everyone around will use pretty much same STL library implementation than nowadays.. ( unless a humans race IQ will radically boost in next few generations). So.. if you value backwards compatibility, maybe you better stick with C++ ? :) > > On Mon, May 2, 2011 at 11:34 PM, TedvG TedvG <[hidden email]> wrote: >> Yes, but a bit simplified: >> As a "typical application programmer" >> I consider myself as a "pharo-user" >> (that is why I am here.) >> Pharo/Smalltalk I really like as an application development tool. >> made by people like you (grateful, thanks), who dive >> deeper in Pharo "itself", so to speak >> So that is why I come with typical "user" questions >> and long term thoughts about usability and so on. >> Simply said: I wont' touch much of the "deeper world" >> in the image, but put my own application object layer >> on it. That is so nice about Smalltalk. >> (not making any money with it, I am outta work at the moment :o| >> >> >> >> - >> >> On Mon, May 2, 2011 at 11:10 PM, Igor Stasenko <[hidden email]> wrote: >>> On 2 May 2011 22:59, Ted F.A. van Gaalen <[hidden email]> wrote: >>>> Hi Igor >>>> ?? Shouldn't I be writing >>>> Pharo/Seaside apps with it? >>>> I am definitely a *user* Of Pharo/Seaside if I do.. >>> >>> hmm.. i don't know.. i were always thinking that those who writing >>> applications are developers, >>> and those who using applications, who don't understand what program >>> is, what is the code, and how it works are users.. >>> but maybe times had changed and now writing an application no longer >>> means that you are developer, >>> but just some kind of power-user? :) >>> >>>> Regards >>>> Ted >>>> >>>> On Mon, May 2, 2011 at 10:53 PM, Ramon Leon <[hidden email]> wrote: >>>>>> El lun, 02-05-2011 a las 22:43 +0200, Igor Stasenko escribió: >>>>>>> >>>>>>> Pharo is end-user application for developers, not for users :) >>>>> >>>>> +1, that's why I prefer Pharo over Squeak. >>>>> >>>>> -- >>>>> Ramon Leon >>>>> http://onsmalltalk.com >>>>> >>>>> >>>> >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> >> > > -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by TedVanGaalen
On 3 May 2011 00:12, TedvG TedvG <[hidden email]> wrote:
> Hi Pat > E.g. Collection classes: > Still use the existing methods like #add: > perhaps the internal workings of these methods > are further optimized... However I don't have to > change any code for this.. Unfortunately it is not always possible to keep protocol(s) compatible. Because the design of library could be completely different and the old protocol is simply not fit for it (take an XTreams for example). > Regards > Ted > > On Mon, May 2, 2011 at 11:57 PM, Pat Maddox <[hidden email]> wrote: >> On May 2, 2011, at 11:46 AM, Ted F.A. van Gaalen wrote: >> >>> On Mon, May 2, 2011 at 7:44 PM, Norbert Hartl <[hidden email]> wrote: >>>> >>>> Am 02.05.2011 um 18:49 schrieb Ted F.A. van Gaalen: >>>> >>>>> Assume that throughout this all coding are countless >>>>> references to classes that are perfectly normal at the >>>>> time of writing. This no exception. >>>>> >>>> Well, if you stay in this "time of writing" (meaning same vm, same image) everything should be fine. >>> >>> (A) I would always want to move my packages to newer releases because >>> they [might] have better performance due to more optimized core >>> classes ?(in addition to the VM performance) >> >> You'll want to upgrade to benefit from performance gains that result from removing the cruft and creating a lean and mean core class library? That seems at odds with the "please don't change the core class library" line of thought. >> >> Pat >> >> > > -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by Mariano Martinez Peck
On May 2, 2011, at 12:48 AM, Markus Fritsche wrote: > Hi, > > 2011/4/27 Mariano Martinez Peck <[hidden email]>: >> And as Marcus said, most of the times (sometimes we had some problems) we >> have a deprecation process where we (usually) say which should be used >> instead. > > From a a-little-bit-more-than-user perspective I am looking at > > SmalltalkImage>>#hasBindingThatBeginsWith: aString > self deprecated: 'Use Smalltalk globals'. > ^globals hasBindingThatBeginsWith: aString > Maybe we should not deprecate that quite yet but have it as a compatibility method (like at:put:) > Well, with a bit of analysis, I would be able to figure out, that the > author might have intended that I should search the SystemDictionary > myself. I feel like an additional comment would have been helpful. > > Same with the other problem I had with ServiceRegistry - it is gone > and it is not easy to find out what that was supposed to do. Next step > is to compare squeak and the Pharo releases to find out what happened > to it (the issue tracker does not easily yield results for this, but > maybe I searched in the wrong way). > Services brought lots of complexity without being used too much. We should build menues via pragmas (like the world menu), then extensions ot menues are just extension methods. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. |
Free forum by Nabble | Edit this page |