Igor Stasenko wrote on Date: Thu, 20 Aug 2009 04:00:32 +0300:
> The central question, which arising immediately is, what is the
> credible way(s) to reproduce such artifacts?
> When we having a source code, we could (re)compile it on a different
> system. But what you propose to do with pure binary data, a soup of
> objects, in respect that it is incredibly hard to understand, what
> bits you need and what's not, in case if you need to do clean-up ,
> refactor, rewrite and simply analyze what is happening.

All true, but that is also the case of the image. Which is why we had
that whole discussion with some Debian guys about Squeak not being free
since you can't generate the current image from text sources like you
can for Self or GNU Smalltalk.

I like to classify computer systems as "blueprint" on one extreme, where
each execution starts wth an empty state and a description of what is to
be done, and as "living" on the other extreme, where once execution is
started it continues forever and accumulates more and more information
not in the original description (you can cheat and interrupt execution
by dumping the full state and later restoring it - like with Squeak
images). Each one has its problems and its advantages. Lots of bugs
which don't matter much in blueprint systems (like memory leaks) are
fatal for living systems. The latter need sophisticated error detection
and correction mechanisms ("lint" for images) which we don't currently
have. On the other hand, developing on living systems is so much more
productive that I am willing to deal with their problems.

Note that PCs were pure blueprint systems when they only had floppy
disks and applications were simply run instead of installed. With
internal fixed disks they have moved more and more towards living
systems (Windows registry and many other things). Many people long so
much for the old days that they cope with the changing behavior of
Windows over time by throwing out their computers every two years and
buying a new one. Certainly such people would not be very happy with the
direction I would like Squeak to go.

> This is what making a huge difference, for instance, between
> applications with open source code and applications shipped in binary
> form - you can only report bugs, but can't realy make any suggestions
> about what happening.

All of the tools that created the bits in the first place, as well as
the tools to change them are inside the same image as the bits. So I
don't agree with your analogy.

Note that just because you call some bits inside the computer "text"
doesn't mean you can manipulate them without special tools. It is just
that if the list of such tools is large and include things as vi, emacs,
notepad and so on then the tool is invisible to you. But it is there. If
I give you some text I wrote on my ZX81 (odd Sinclair character set) or
on the Burroughs 6700 (EBCDIC) then these tools won't help you very
much.

> I don't think that developers of Squeak should be victims of such situation(s).

The original thread was about how I vote for things that will make
Squeakers happy, not for what I would personally like. So nobody will be
a victim because of me. But I see no harm in discussing these things -
most people aren't even aware that we are making a choice.

-- Jecel