On Thu, Feb 23, 2012 at 8:43 PM, Jecel Assumpcao Jr.
<jecel at merlintec.com> wrote:
> Thanks to Enrico, Hannes and David for your kind words.
>
> Enrico Spinielli wrote:
>
>> If you will organize your projects to be open and you will be willing to get some help,
>> I would be very interested to help with your vision of a system projected in the future
>> without forgetting the past!
>
> The project was fully Open Source between 1997 and 2008 (though so
> poorly documented that it might as well have been closed), but now is
> partly Open Source and we still have to figure out which parts will be
> what given the large overlap between the commercial venture and my PhD
> project. Curiously, while it was Open Source it couldn't be considered
> Free Software since in the 1990s I came up with a concept similar to
> Apple's App Store but with "pay per use" as in Brad Cox's
> "Superdistribution" instead of "pay to own".
>
> http://www.wired.com/wired/archive/2.09/superdis.html
>
> Having to pay to run software violates freedom 0, though not 1, 2 and 3:
>
> http://www.gnu.org/philosophy/free-sw.html
>
> It does not, however, violate any of the 10 terms of the Open Source
> Defintion:
>
> http://www.opensource.org/osd.html
>
> Basically, it would be great if people could make their living by
> working on Smalltalk. I am trying to figure out a way to achieve this
> without secrets and restrictions. Back in the 1980s and early 1990s I
> gave the DRM issue a lot of thought and decided against trying to find a
> technical solution for an ethical problem.
>
> Hannes Hirzel wrote:
>
>> You say:
>>
>> " I you can't add simplicity, only complexity."
>>
>> So to have something simple you have to start from scratch.
>
> Exactly. If you take Unix and add X11 and then QT and the KDE you might
> get something that looks simple, but it really isn't and once in a while
> the underlying complexity will show through. Contrast this with BeOS,
> for example. And I think that they limited how simply they could make it
> by basing their work on C++.
>
> Even while playing with Little Smalltalk 3 (100KB image, 40KB VM and
> Smalltalk-76 class model) or 4 (92KB image, 89KB VM and Smalltalk-80
> model) I like to think about how much we have learned since these
> systems were created and how much smaller and simpler they could be.
>
> Just a simple example to make this discussion more concrete: in the
> Squeak VM we have the "push literal" bytecode that will take an object
> reference stored in the method object and save that on the stack. That
> reference can be to *any* object in the whole image, but the compiler
> will only allow us to generate code that points to a small set of
> objects that have a literal syntax defined for them: arrays, numbers,
> strings, characters, booleans and nil. What if we could just drag any
> object and drop it into the source code? The compiler could be far
> simpler - all it would need to do would be to copy the reference from
> the source text to the method object instead of knowing how to parse
> half a dozen text notations. Of course, the complexity would have just
> moved elsewhere instead of being eliminated because if the compiler
> doesn't know how to make numbers then some other part of the system has
> to be able to do it.
>
> The point is that doing it from scratch allows us to explore
> alternatives that are not available while just adding to the current
> system.
>
>> I am looking forward to your work on a
>> "a very simple Smalltalk to run side by side with Squeak in the second
>> half of 2012"
>
> For that we have to define a standard way to communicate between
> different images (TeaTime is a way to keep identical images in sync, and
> so doesn't count). That could be rST, Spoon's Other or something similar
> (Colin Putney has proposed a specialized one for remote
> debugging/development). With a little care, it would be possible to have
> an application that would run half in Squeak 1.6 and half in Squeak 4.3
> or else half in Spoon and half in Newspeak.
>
This would be cool. And maybe confusing ;-)

Karl