Andreas

This sounds cool :) I want that future. I was really thinking that now 
that java is nearly as complex a C++ :) and smalltalk too old :)
having a new cool dynamic language with the Smalltalk essence (late 
bound, pure, uniform, simple, elegant) + security
would be cool. But I'm disgressing too :)

I think that the most important aspect is that people should find the 
new stuff more sexy, useful and the transition with
follow. This is why tweak is important because morphic is a legacy 
system (made his time, but bloated and need to pass away).

Stef

By the way andreas you should get in sync with marcus because his work 
on the new compiler could really help you for your
tweak extensions.


> Hi Goran,
>
> Let me try to answer your questions:
>
>> 1. Is Tweak meant to replace Morphic alltogether in the long run? Or 
>> is
>> it only replacing parts of Morphic?
>
> It is clearly intended to be a replacement of Morphic. Replacing 
> "parts" makes little or no sense as it would break too many things 
> that need fixing. However, we realize and acknowledge the fact that 
> Morphic will stick around for a long time (similar to MVC which is 
> still in Squeak) and the only thing we am working on is the ability to 
> get rid of both MVC and Morphic if that is desirable (which it will 
> for packaging purposes but not for a long time as most of the tools 
> are available for Morphic).
>
> Meaning that although Tweak is intended to be a Morphic replacement it 
> *will* work in parallel to and together with Morphic (not necessarily 
> vice versa since that again would mean fixing many different things in 
> Morphic that I cannot possibly be bothered to fix). I should also 
> mention that the Tk4 efforts play an important role here as they are 
> intended to hammer out some of the issues for integrating Tweak into 
> "different window managers" - e.g., you can expect that once this 
> works you might have "native Morphic windows" which host Tweak 
> environments similar to any other kind of window.
>
>> 2. Is Tweak meant to be something that can work on top of official
>> Squeak, or is it only targeted at Croquet? Croquet is currently not a
>> "fork" of Squeak, but it may very well turn out to become one. And if
>> the principal developers behind Tweak are the Croqueteers, it may
>> perhaps turn into something Croquet specific.
>
> That depends on your definition of "Squeak" and "Croquet". Some people 
> take the (overly simplified) point of view that Croquet is ultimately 
> about 3D environments but let me tell you: It is not. It is ultimately 
> about collaboration and communcation and there are many different ways 
> of doing this, some of which imply a 3D space (having the vast 
> advantage of providing context for the collaboration and a natural 
> model for navigating large spaces) and some of which don't. *All* of 
> them, however will require a distributed, loosely coupled, secure 
> messaging model of replicated computation between (mutually 
> distrusting) objects and peers. Which is what we internally understand 
> as "Croquet"; a much broader, much wider ranging collaboration 
> architecture that includes many different areas of communication, many 
> different classes of devices, many different user interfaces. (and 
> yes, we really aren't there by a long shot but then again I will want 
> to have something to work on five years from now ;-)
>
> Given that definition I can say with utter certainty that Tweak is 
> meant to run on top of Croquet, with "collaboration builtin". Whether 
> that can run on "top of official Squeak" depends on whether Croquet 
> can run "on top of official Squeak" and that largely depends on how 
> drastic the required changes from the research to the engineering 
> track are, i.e., I do not have a good answer. Personally, I would be 
> surprised if the changes were too drastic to make it work at all but 
> then again you never know - we certainly have been talking about some 
> quite orthogonal directions to using Squeak.
>
> But does that matter? Practically speaking, no. All it means is that 
> an infrastructure is in place which enables you to do tight 
> collaboration using these objects. That - for example - the objects 
> have builtin policies to be able to interact with multiple users (what 
> is a double-click in a collaboration environment?) that they know 
> about replication strategies etc. OTOH, if you are interested in 
> building "smart clients" (this is a term that I have lately heard to 
> distinguish apps from "thin but dumb" clients) it actually gives you 
> ways to move the boundary between client and server in a way that has 
> been impossible before - starting from a really, really dumb client 
> (which would resemble something like VNC or the X-Windows protocol) up 
> to a really, really smart client (which would effectively be a P2P 
> network with no server other than for getting some code). So there are 
> certainly opportunities in the areas of distributed computation - even 
> for "boring old business apps" which suddenly might become just a 
> little smarter, and just a little more usable than before.
>
> But I disgress ;-)
>
>> Well, as I said - I am not sure yet how Tweak (or Croquet for that
>> matter) really relates to Squeak. And since I guess the Croqueteers
>> aren't sure themselves :) it is all a bit foggy right now. To me at
>> least. :)
>
> I think the best way to describe the *current* relation between 
> Squeak, Croquet and Tweak is to say: Squeak is being used by both. 
> Both systems have a set of requirements which are met by Squeak - 
> mostly that of having a fairly simple late-bound object system with 
> good programming tools and -most importantly- the ability to change 
> everything top-to-bottom. I fully expect to port both forward to the 
> next Squeak release which contains m17n (again "using" Squeak) but 
> whether that's going to stay that way is a different question.
>
> Okay, I know I shouldn't do it but I am going to hint a little bit at 
> the future: Personally, one of my major goals is to -oh my god- get 
> rid of the current Squeak VM and replace it with something infinitely 
> more flexible, elegant, and fast. That would be a major step away from 
> what we currently have under the name of "official Squeak" but it 
> seems to me that we have both the technology and the people to make 
> this happen and I will be damned if I miss that chance.
>
> Secondly, security is going to be one of the major thrusts of our 
> efforts which (not surprisingly) will address the issue of modularity 
> - by the end of the day, in order to be successful we must be able to 
> replicate code on arbitrary machines of the internet, run it securely, 
> and get rid of it with (literally) no traces left. I believe that's 
> absolutely doable and, again, we have the technology and the people to 
> do it (shameless plug on "how to do security right": 
> http://www.erights.org and 
> https://www.cypherpunks.to/erights/talks/uni-tea/uni-tea.ppt for how 
> this might work in the context of Croquet).
>
> Thirdly, the time is ripe for some REAL progress on the front of 
> end-user programming, towards a system that is able to speak to the 
> user in the form that the user knows about or wishes to use, to have a 
> system that is capable of explaining itself to the user, that tells 
> you where to start, what to look for, who to ask. A system that 
> includes lots of exemplary programming styles, varieties on the 
> languages you use all of which brings security and distributed 
> computing to the end-user.
>
> Cheers,
>  - Andreas
>
>