Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

Miguel Cobá
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





Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

Ramon Leon-5
> 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

Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

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

Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

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

Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

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

Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

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

Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

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

Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

patmaddox
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

Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

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

Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

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

Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

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

Reply | Threaded
Open this post in threaded view
|

Re: Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

Marcus Denker-4
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.


12