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 <[email protected]> wrote: > > On Oct 4, 2012, at 8:02 AM, Marcus Denker <[email protected]> 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 > >
