On 10/07/06, stéphane ducasse ducasse@iam.unibe.ch wrote:
C'est marrant de voir que cette personne qui s'est plaint de Squeak a prefere recommencer ailleurs au lieu de proposer une nouvelle mouture de Morphic comme est en train de le faire un argentain (juan vuletich). C'est marrant je n'ai jamais vu cette personne ne serait qu'envoyer un simple fix dans Squeak. Il a surement des tas de raisons.
En tout cas il n'était pas resté "muet" sur la liste squeak-dev , source: http://sourceforge.net/mailarchive/forum.php?thread_id=26506356&forum_id...
Contenu:
On 23/07/06, Paul D. Fernhout pdfernhout@kurtz-fernhout.com wrote:
Francois-
I noticed this discussion from a couple of weeks back related to PataPata, and my wife, who speaks some French, gave me a rough translation: http://www.nabble.com/PataPata-t1915500.html
by stéphane ducasse-2 2006-07-10 02:33 C'est marrant de voir que cette personne qui s'est plaint de Squeak a prefere recommencer ailleurs au lieu de proposer une nouvelle mouture de Morphic comme est en train de le faire un argentain (juan vuletich). C'est marrant je n'ai jamais vu cette personne ne serait qu'envoyer un simple fix dans Squeak. Il a surement des tas de raisons.
You have been a little quiet on your side of the Atlantic, and if this was the only reason, I should mention I have done some previous things done for Squeak, of varying degrees of success, and mostly from about six to eight years ago, so perhaps so long ago Stéphane has forgotten?
I have both contributed to the Squeak community and have specific reasons for not just improving Morphic.
I was one of the first users of Squeak (Sun, Oct 6 1996):
http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/798b...
I developed Embedded Squeak (a small headless Squeak): http://www.kurtz-fernhout.com/squeak/readme.txt
I worked on a Newton version of Squeak (a fizzled project, admittedly, no source on the web).
I released a Data Repository System for Squeak:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-July/003656.html
Some old comments I made on improving Morphic include:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-February/012486.... which lead to my proof-of-concept of LinksWorld posted to the Squeak list 03/11/2000: "Here is one working example of some of what I am talking about for an alternate design philosophy to Morphic: http://www.kurtz-fernhout.com/squeak/LinksWorld20000311.zip This code example is similar to the concept expressed in another post I made related to using networks of links as the basis for GUI building. It runs under MVC much as Morphic does -- by not actually using the MVC paradigm, but just presenting a "world" window. This code was developed under Squeak 2.7, and I tested filing it into 2.4. It has not been tested with 2.8."
A summary I wrote to the Squeak list of the deeper issues:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-September/009324... "There are really just a few core things that need to be rewoven throughout the release -- modularity, exceptions, fonts (please not ones reliant on Morphic) and then Squeak can really take off as the rest of the parts can be added by individuals as modules. All are already making progress (slowly). But I think it unrealistic to expect an individual or even a group to do these specific core things outside of SqueakC (given the current state of affairs). Just about everything else, yes. For example, I have in the past offered things like LinksWorld (with undo) or the Pointrel data repository system as Squeak add-ons. These few core things I mentioned would be best done by the core group. Unfortunately, at this point what we have now (to greatly exaggerate, admittedly) is in effect the core SqueakC team working on extensions and applications (Morphic, eToy, 3DGraphics, Scripting) and everyone else working on core issues (exceptions, fonts, modularity, block variables). If Squeak was more modular, this inverted approach might work better. But it's not yet. And making Squeak more modular requires making massive core changes -- a Catch 22 (even I think for the Squeak Stable World Tour, but perhaps that will have oompph enough to get past it.)"
You can Google for lots of other comments I've made to the Squeak lists on lots of issues relating to making Squeak a better system. Essentially, the core issues relate to trying to manage complexity in Squeak. For example: "Belling the cat of complexity (was: Ship it with Squeak)"
http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-June/001371.html (including proposing a "harvesting" process). From there: "Les Tyrrell put the issues very eloquently, and makes me realize this issue for shipping is really best put as "managing complexity in Squeak to reduce the risk of unexpected behavior in an application to an acceptable level". The complexity in Squeak comes in two areas: code issues and license issues."
One big issue I wrote extensively on the Squeak list was simply the license and related issues -- the Squeak license was not true "open source" or "free software" (especially regarding indemnification and export provisions), and there was never a clear statement from Disney as to the licensing of the work done while Alan Kay's group was there. I begged Alan Kay to get one as his group left Disney, but essentially got a reply that software copyright and patents were so messed up that licensing was always problematical and if you read the Squeak license a certain way their stuff was covered somehow. He said similar things publicly later, a related example being:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-March/054984.htm... (which also proposes going beyond Squeak, which I am trying to do). I'm willing to tolerate some ambiguity in licensing issues, but that seemed pretty much beyond what I was comfortable with. :-) So legally IMHO Squeak itself was (and still is) a shaky foundation to build on (the Disney issue being the most problematical in my opinion). Technologically interesting, yes, but legally problematical. I also had the Squeak situation reviewed by the legal team at one of the biggest computer companies in the world and could use it only with a lot of big restrictions even with Disney as a partner (no distribution of the results being the biggest one -- and that big company even had one of the authors of the Squeak license working for it by then and helping me with the approval process). By contrast, Python got the go-ahead for doing all sorts of stuff with around 1999 (embarrassingly to me, they even asked Guido directly if Python was original) when I wanted permission to use that for an R&D project. Personally, it would not surprise me if that licensing was also one issue driving some of Alan Kay's groups interest in Python (although I think visibility is still probably the bigger draw. :-)
I think history has proven me right on these things. As much as people protested or ignored these points, these issues of managing complexity (e.g. "bit rot") in Squeak and of dealing with licensing issues continue to limit Squeak's growth and development. For example, recent posts by others on Jan 30 2005 : "Squeak is an unsuccessful open source project (was RE: Let us face reality)"
http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-January/087609.h... (I agree Craig Latta's work is a great direction). or: "The state of licensing... and a Dream! (was Re: Proposal for a Squeak migration meeting)"
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-June/105229.html Or even:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-March/055566.htm...
I *could* solve the technical issues with Squeak (and would have enjoyed doing so); I could *not* solve the legal ones by myself, or the complexity management ones of seeing any improvements I made be left to rot as the core team focused on just adding more complexity (which I had already seen happen to other submitters for patches related to fixing core issues.)
People are now trying to address these core complexity management issues in Squeak and doing a good job of it, but for me the licensing issues remain as unresolvable ones. Others (including presumably Stéphane) naturally have their own opinions on the licensing situation, and many agree with Alan Kay's opinion, and so focus on improving Squeak directly, and I wish them the best of success with that. And here is a good idea by Stéphane on how to slowly fix even the licensing issue:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-June/105257.html The copyright "contamination" problem would still there to varying degrees, although it would also haunt contributions by anyone, including myself, who has used any commercial Smalltalk which generally come with much source, and most Squeakers fall in that category.
Still, even Alan Kay himself repeatedly suggests just thinking of Squeak as a stepping stone to the next great thing.
These were the sorts of things I wanted to address such as with this proposal:
http://lists.squeakfoundation.org/pipermail/squeakfoundation/2002-January/00... "The intent of the Bellesqueak list is to support a community process which creates, discusses, uses, and maintains a cross-platform computing environment and knowledge management system inspired by Squeak Smalltalk called Bellesqueak. The focus of Bellesqueak will be on transparency, robustness, and complexity management -- to support the doing of good deeds such as education, sustainable development, and ensuring humanity survives Vernor Vinge's Singularity in some form." But, that effort did not progress (although PataPata is a form of progress on it).
I just took a week vacation to visit relatives, and now I am reevaluating what I want to do with PataPata -- like whether to continue with Python or reconsider the idea taking the lessons from those versions and move towards putting prototypes with a Smalltalk/Self syntax on top of OCaml (and perhaps other syntaxes as well, indentational Scheme, Python-ish, etc.). I remain intrigued by the notion of building prototypes on Ocaml (using it as a "better C") to create a system that has late binding for most things in the system I build but have early binding for a few performance issues like the delegation code itself (which is currently in Python and so, in this case, not as fast as it could be). Alternatively, modifying the Jython compiler for the JVM to use prototype delegation routines written in Java is another route to gain performance but in this case stay close to the Python language model (and probably advantageous from a copyright "contamination" point of view). Both approaches have pluses and minuses, as does just sticking with plain Python.
--Paul Fernhout
francois
Stef
A voir ici : http://showmedo.com/videos/video? name=patapata_tkinter1_fSchnell
WARNING : Troll detected.
Non ce n'est pas un e-Toys en Python, c'est juste un ancien utilsateur de Squeak (Paul Fernhout un américain) qui se fait plaisir en *commençant* quelque chose dans son temps libre (v 0.1). Son initiative n'est pas supportée par "Guido" à ma connaissance.
Comme je crois à la diffusion des idées (qui ne sont pas encore brevetables pour l'instant), j'ai fait ce Screencast pour expliquer à un autre américain ce que cet américain fesait sur une liste (et puis après showmedo l'a repris).
Bon on a tous des choses constructives à faire.
Bonne nuit.
francois
-- oooo Dr. Serge Stinckwich OOOOOOOO Université de Caen>CNRS UMR 6072>GREYC>MAD OOESUGOO http://purl.org/net/SergeStinckwich oooooo Smalltalkers do: [:it | All with: Class, (And love: it)] \ / ##
Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr