2008/9/1 Alejandro F. Reimondo <aleReimondo at smalltalking.net>:
> Hi,
>
>> The purpose of putting scripts on installer.pbwiki.com is so that those
>> scripts can be loaded into 'any' image with the minimum of Installer or
>> at best LPF loaded.
>
> The scripting idea is valuable when you want to "run" scripts (to
> produce output data) on a solid+fat+stable defined
> core of functions+components exposed by the scripting
> engine/compiler...
> It is not the case for smalltalk systems, where any change can
> be done on the system, during an installation the intent is to
> produce change in the system, and the most valuable attribute
> of the system itself is it´s stability.
> (a very diferent scenario to where use of scripting has
> proven to be good)
>
>> This scenario is intended to enable the user to see
>> and select what to apply to their own images.
>
> The real problem here is that "the user" (the owner of the
> system under my pov) must ask/respond without
> seen/understanding what will be injected and also without
> understanding some areas of the system that will be affected
> by the "script" (a script that is written by a person that do not
> know about the system it is been installed).
>
> I consider that it is not enough to "see"/read the package
> intention, if the injection(ingestion?) of changes to the system
> is fast, "the user" will receive also more uncertaninty about
> the stability of the system .
> Incremental (and fine grained) incorporation of pieces in a
> guided tour can be more effective; e.g. it is better to make
> incorporations of features as much slow as possible, to let
> the person learn about what is been incorporated and
> act/ask/reflect while understanding what is included.
>
> If we let "smalltalk users" continue incorporating and using
> instant features, the effect is similar to copy&paste
> ("problems" appears when peolpe do not have time to
> think about it).
>

Sure, a mistake made by "smalltalk user" can lead to problems, which:
a) easy to reproduce , since scripts is provided
b) easy to fix , because of a)
c) easy to distribute fix, by fixing a script

and compare this to a mistake, done by a "master" who did something
which only he can understand, and which only he could fix, and as its
often happens, have no time/will/money to spend fixing the problem he
once introduced.


> best,
> Ale.
>


-- 
Best regards,
Igor Stasenko AKA sig.