Em 16-07-2009 08:40, Bert Freudenberg escreveu:
> On 14.07.2009, at 03:01, osp at aloha.com wrote:
>
>> Maybe it is just me, but "a fast bytecode package loader, without the 
>> need
>> to compile Smalltalk code" combined with "such feature could make life
>> easier to third party Etoys developer and eventually attract more of 
>> them
>> to Etoys" sounds like an endorsement of closed-source commercial EToys.
>
> No, that's is a severe misunderstanding you construct here.
>
>> If
>> commercial success is not the attraction, what is? Faster initial load
>> time? Reduced file transfer size? Perhaps I assumed too much.
>
>
> Yes, both of these. The scenario we care most about is the one million 
> kids using XO laptops. These machines are under-powered compared to 
> recent PCs, and have rather little main memory. It's infeasible to 
> have one image with all the extensions to Etoys, because the whole 
> image is loaded into RAM. It would be very nice if these add-ons could 
> be delivered as separate packages and loaded on demand.

But to have millions of kids using XO laptops it is necessary to supply 
a product that has commercial appeal. Moreover in 3rd world countries 
where the political discourse behind money employed in buying and 
distributing these PCs is based on the fact that children will be 
enabled to gain technical skills that will allow them to leave the 
"prison of poverty".

In this line of real life context, other participants like 
IBM/Unisys/Dell/HP/Sun/Microsoft/Borland/etc argue that they have better 
stuff than the "under powered" OLPC (for instance) and that nothing 
interesting will result from teaching smalltalk and it would be better 
to "train children" to use "more significant technologies" (sic) like 
Java/.NET/MVC/MVB/Delphi/etc...

Many countries, like Brazil, have laws that make computer donations to 
public schools almost (if not absolutely) impossible. For the interested 
ones, just take a look at Federal Law 8666 
(http://www.planalto.gov.br/ccivil/Leis/L8666cons.htm). Thus, unless a 
big boss patronizes embedding squeak inside the product they'll be 
selling to government through public bid... children will learn 
something else.

I am aware that other 3rd world countries have the same legal problems. 
And even in countries that doesn't have specific laws (moreover the ones 
with big population) the donation of XO laptops may be non viable due to 
costs involved, so a sales scheme is to  be devised.

On the other hand, why would a government invest in something that has 
no commercial appeal? Governments are elected (usually by people) so 
they care for immediate results of their policies. Consider the reality 
of 3rd world countries where day to day survival is a really concrete 
concern of population. Government actions are aimed to discourses like: 
"now your children is entitled to run for better jobs". No commercial 
relevance, no better jobs, no action by governments.

>
> That's what the current Dr Geo II package is doing. But it is slow, 
> because all the code is compiled to byte code when loading the 
> package. The Squeak byte code compiler has not exactly been optimized 
> for speed, because in usual development you only compile a method at a 
> time. In any case, the *result* of loading a package that includes 
> both source code and byte code would be exactly the same as compiling 
> the source code, but way faster.
>
> This could also be used to speed up package loading in general. In 
> fact, this would make the concept of "libraries" feasible in Squeak - 
> packages loaded on demand. Think about pre-compiled lisp modules, or 
> the .pyc files generated from .py Python files for speed. Note I'm not 
> advocating this for Squeak but it would make it technically feasible.
>
> It's just not exactly trivial to do in a robust way. At the very 
> least, all global references in the compiled methods will have to be 
> updated. This includes classes which have to be referenced, Symbols 
> need to get interned and unified. The source could be appended to the 
> changes file and source pointers incremented, or the source could 
> remain in separate files but we'd need a new source code scheme for that.
>
> I think this all would be immensely useful in the long run, but truth 
> is we have been getting by without for so long that there just does 
> not seem to be anybody both motivated and skilled enough to do it.
>
> - Bert -
>
>
>
>
CdAB