To try out FileSystem in 2.0 -- which download?

> Hello
>
> I would like to try out the newly integrated FileSystem
>
> The Pharo 2.0 unstable page
>   http://www.pharo-project.org/pharo-download/unstable-2-0
>
> has two options:
>
> 1)
>       a link to
>       https://ci.lille.inria.fr/pharo/   (all builds)
>
> and
>
> 2)
> a One-click distribution
>      http://ci.lille.inria.fr/pharo/view/Pharo%202.0/job/Pharo-2.0/lastSuccessfulBuild/artifact/Pharo-2.0-one-click.zip
>
> Is the One-click distribution on par with the latest builds or lagging behind?
>

>
> On Oct 4, 2012, at 8:02 AM, Marcus Denker <[hidden email]> wrote:
>>
>> Now there are two philosophies
>>
>> 1) we load the new in addition. It even is compatible to many different versions of the System, and everyone uses it
>> in new code. But the sytem can not use it, as the developer of course wants to load the latest version of this independendly
>> develpopped library. Some people requested that for FileSystem, and we renamed all classes so that they can continue
>> to load the code themselves.
>
> This  actually is interesting, these two philosophies...
>
> 1) The Addition View
>
> Smalltalk is perfect and finished. Everything we do we do "on top". If we implement Morphic, we keep MVC. Things like
> FileSystem code is there as an additonal library.
> When doing research, the picture you have is not that of a System that you improve to make a new System that makes
> the next research easier. No. You do something *on top*, and throw it away after.
>
> 2) The System View
>
> I think some people's brain kind of got a hickup when they looked at instances of Class and saw that they just use standard
> libraries. MethodDictionay is a Dictionary... there is no special "I wrote everyhting again because I am clever!" code
> even deep in the system. That is one of the things that makes Smalltalk powerful!
>
> The main reason is that it created a feedback loop: We improve something for an application. But then, instead of throwing
> it away, we *apply* that improvement to the *whole* system. The system gets better (faster, smaller). And its expressiveness
> is improved: the next developer can just *use* the improvement and put the time into something else.
>
> Especially in Research, this is quite important: You can't publish things that have already been done. Time is limited (just 3-4 years
> to do a PhD...). So if the guy has to constantly start from scratch, this gets very hard after just some interations. Yet, when the System
> itself improves... the picture here is that of a mountain: We can always climb up from the valley deep down, or we can build base camps.
> Who will do better?
>
> I think we are starting to (slowly) see this with Pharo. E.g. the on-demand loading of the .sources. It uses Zinc and FileSystem, it's just a
> couple of lines of code. Yes, you could have done it before. But would anyone do it? Of course not.  (just a very trivial example).
>
> Marcus
>
> --
> Marcus Denker -- http://marcusdenker.de
>
>

> Thanks for the explanation and pointers, Marcus.
>
> Well written, well said, as usual ;-)
>
> --
> Sven Van Caekenberghe
> http://stfx.eu
> Smalltalk is the Red Pill
>
>
>
> On 04 Oct 2012, at 08:26, Marcus Denker <[hidden email]> wrote:
>
>>
>> On Oct 4, 2012, at 8:02 AM, Marcus Denker <[hidden email]> wrote:
>>>
>>> Now there are two philosophies
>>>
>>> 1) we load the new in addition. It even is compatible to many different versions of the System, and everyone uses it
>>> in new code. But the sytem can not use it, as the developer of course wants to load the latest version of this independendly
>>> develpopped library. Some people requested that for FileSystem, and we renamed all classes so that they can continue
>>> to load the code themselves.
>>
>> This  actually is interesting, these two philosophies...
>>
>> 1) The Addition View
>>
>> Smalltalk is perfect and finished. Everything we do we do "on top". If we implement Morphic, we keep MVC. Things like
>> FileSystem code is there as an additonal library.
>> When doing research, the picture you have is not that of a System that you improve to make a new System that makes
>> the next research easier. No. You do something *on top*, and throw it away after.
>>
>> 2) The System View
>>
>> I think some people's brain kind of got a hickup when they looked at instances of Class and saw that they just use standard
>> libraries. MethodDictionay is a Dictionary... there is no special "I wrote everyhting again because I am clever!" code
>> even deep in the system. That is one of the things that makes Smalltalk powerful!
>>
>> The main reason is that it created a feedback loop: We improve something for an application. But then, instead of throwing
>> it away, we *apply* that improvement to the *whole* system. The system gets better (faster, smaller). And its expressiveness
>> is improved: the next developer can just *use* the improvement and put the time into something else.
>>
>> Especially in Research, this is quite important: You can't publish things that have already been done. Time is limited (just 3-4 years
>> to do a PhD...). So if the guy has to constantly start from scratch, this gets very hard after just some interations. Yet, when the System
>> itself improves... the picture here is that of a mountain: We can always climb up from the valley deep down, or we can build base camps.
>> Who will do better?
>>
>> I think we are starting to (slowly) see this with Pharo. E.g. the on-demand loading of the .sources. It uses Zinc and FileSystem, it's just a
>> couple of lines of code. Yes, you could have done it before. But would anyone do it? Of course not.  (just a very trivial example).
>>
>>       Marcus
>>
>> --
>> Marcus Denker -- http://marcusdenker.de
>>
>>
>
>

>
> On 04 Oct 2012, at 08:02, Marcus Denker <[hidden email]> wrote:
>
>> I would start with the book chapter:
>>
>> http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/FileSystem.pdf
>
> To those who helped writing this chapter and bringing FileSystem to Pharo and writing FileSystem in the first place: thanks !
>
> One thing though: the public API as described in the high-level documentation should be used to write method comments - this is a contribution that anyone can do ;-)