Folks -
[also posted at http://board.squeak.org/2009/07/06/the-pillars-of-squeak/] I've been trying to come up with a starting point for a strategy discussion to help our community understand better what we are and what we want to do in the future. In thinking through the various aspects (there is nothing like sitting on a porch in North Carolina on a warm summer evening to do that ;-) it occurred to me that Squeak is really built around three fundamental pillars: * Minimalism. * Tools. * Education. Minimalism. I think we all agree that we love minimalistic, simple kernels and systems. I don't think any of us would disagree with that. Whether it's an embedded system, a little kernel image, or some self-contained bootstrap magic; we just all love and cherish self-contained little systems. Tools. It's what we use daily and it's one of the things that we're most proud of. The effectiveness of our tools, the speed with which they allow us to do almost magical things, the ability to simulate even complex interactions are all parts of the environment that I don't think anyone would give up on. Education. Smalltalk started as a system simple enough that a single person could understand and making a system that way means building it in an accessible form and that is squarely part of education. Some of us are also interested in educating children using Squeak but I think that we *all* want the system to be easy to learn from and easy to access. In addition to these fundamental pillars of Squeak I see three more areas that are of very wide interest but not universally shared: * Media. * Internet. * Business. Media. The media aspects of Squeak are certainly unique. There is no other Smalltalk system that comes even close and for me, the media aspects were always the most interesting. Having the ability to have vector graphics, 3d, sound synthesis, mixing, video, scripting running bit-identical over such a variety of platforms is what makes projects like Plopp, or Etoys, or even Croquet and Qwaq Forums possible. Internet. This is the Internet age after all, and much of what we do centers around it. Projects like Seaside or Aida are central for much of newly generated interest, entire companies are built around the abilities of Squeak on the 'net. Business. Last, but not least, business uses. There is a lot of interest in business use of Squeak which I think we have never very carefully catered too, but the interest (mostly in the form of complaints ;-) is certainly there. Since that's literally where the money is I think it's worthwhile to take it into account carefully. Since this is supposed to the the starting point for a strategy discussion, what do people think about the above areas of interest? I'm in particular interested in whether you think you could identify with the three pillars of Squeak since if we can agree on those as the most important values that we *all* share, it seems that there are obvious practical consequences that we can draw from it. I think that formulating and agreeing on our values as a community is a central part of setting our own direction. It gives us something to look back to when we don't know what to do next, it gives us something to agree on when we disagree. Comments are very welcome. Cheers, - Andreas |
On Sun, Jul 5, 2009 at 10:19 PM, Andreas Raab<[hidden email]> wrote:
>it occurred to me that Squeak is really built around three > fundamental pillars: > > * Minimalism. > * Tools. > * Education. > > Minimalism. I think we all agree that we love minimalistic, simple kernels > and systems. I don't think any of us would disagree with that. Whether it's > an embedded system, a little kernel image, or some self-contained bootstrap > magic; we just all love and cherish self-contained little systems. I love minimalistic, simple kernels and systems. Squeak isn't one. I suppose that at its heart there is a simple kernel, but it is surrounded by an overly complex image. i imagine that most of the people at the original Squeak Central also loved minimalism. So, why did Squeak get so big? What forces cause people who love minimalism to make a bloated image? At least one of these forces is the demand for immediate usefulness. It is easier to throw stuff in the image than to modularize the system. But I think that the forces opposing minimalism are probably complex and powerful. If we don't understand them, we are unlikely to defeat them. -Ralph |
Ralph Johnson wrote:
> did Squeak get so big? What forces cause people who love minimalism > to make a bloated image? At least one of these forces is the demand > for immediate usefulness. It is easier to throw stuff in the image > than to modularize the system. But I think that the forces opposing > minimalism are probably complex and powerful. If we don't understand > them, we are unlikely to defeat them. I think the main problem historically was the (non)availability of a source management system that supported packages. In its absence there was no self/natural enforcement of modularization leading i.e. to etoys and morphic being woven through every aspect of the image. Thus creating the tremendous forces opposing minimalism plus the self fulfilling prophecy of "if it's out of the core it won't be maintained". Just MTC Michael |
In reply to this post by Andreas.Raab
On Sun, Jul 05, 2009 at 08:19:13PM -0700, Andreas Raab wrote:
> > * Minimalism. > * Tools. > * Education. > ... > > Since this is supposed to the the starting point for a strategy > discussion, what do people think about the above areas of interest? I'm > in particular interested in whether you think you could identify with > the three pillars of Squeak since if we can agree on those as the most > important values that we *all* share, it seems that there are obvious > practical consequences that we can draw from it. Yes, these three capture the fundamentals nicely. I am inclined also to think of "Accessibility" in the sense of an entire system that is visible, browsable, and changeable from top to bottom. Squeak is different from other open systems because an individual person can really lay hands on it, learn from it, and experiment to his or her heart's desire. I think you have captured that theme nicely under the "Education" pillar, but I wonder if it may be worth a pillar of its own. On the other hand, explaining this under the theme of Squeak as an educational system helps to articulate why the education pillar is important to all of us, not just to young children. > I think that formulating and agreeing on our values as a community is a > central part of setting our own direction. It gives us something to look > back to when we don't know what to do next, it gives us something to > agree on when we disagree. Nicely said. Dave |
In reply to this post by Andreas.Raab
Hi all:
2009/7/6 Andreas Raab <[hidden email]>: > it occurred to me that Squeak is really built around three > fundamental pillars: > > * Minimalism. > * Tools. > * Education. > > Minimalism. I think we all agree that we love minimalistic, simple kernels > and systems. I don't think any of us would disagree with that. Whether it's > an embedded system, a little kernel image, or some self-contained bootstrap > magic; we just all love and cherish self-contained little systems. > > Tools. It's what we use daily and it's one of the things that we're most > proud of. The effectiveness of our tools, the speed with which they allow us > to do almost magical things, the ability to simulate even complex > interactions are all parts of the environment that I don't think anyone > would give up on. My comment about Tools is closely related to the Business one and is about the lot of tools and changes (and incompatibilities) that were emerging with the time. I understand that any of us can develop its own tools, but also think that would decide a set of tools to use on the "official" squeak and maintain its use or, if changes, then make it more "organically". I means, by example, the different sort of packages of code (.cs, .sar, .mcz), the different tools to deal with (changesets, CodeLoader, Monticello), the tools developed by Keith (LPF, Installer, etc), the different repositories (SqueakMap, Squeaksource, Universes). I think that all these things deserve a bit of order (Well, already lot of discussions on the other threads, but just to point). > > In addition to these fundamental pillars of Squeak I see three more areas > that are of very wide interest but not universally shared: > > * Media. > * Internet. > * Business. > Is hard to me think why not universally shared. AFAIK exist a lot of applications on Media and Internet, as many as in the other fields. And, as you correctly point, Business is were the money is. As a small independent developer, the business side is VERY important to me, because I can not afford to use the language *X* to earn money and Squeak only to hobbistic projects. And I think that is the position of several people here. Alos I use other Smalltalks to specific commercial projects, but I would love to use Squeak to all my projects. That would permit a deeper dedication to Squeak, no only to use it, else to contribute with it. In summary, I think that the 6 areas pointed are importants, agree with the Ralph comment about Minimalism and select my pov about that Tools (and process) need some definitions and reordering. Cheers. -- Germán S. Arduino http://www.arduinosoftware.com http://germanarduino.blogspot.com |
In reply to this post by Ralph Johnson
On Mon, Jul 6, 2009 at 7:03 AM, Ralph Johnson <[hidden email]> wrote:
The force that opposes minimalism is actually just mental inertia. It is easier to not think about what you're doing, and fling code at a problem until you find a solution. To actually consider how the semantics of the method and object names you choose will affect future developers is simply beyond the capacity of most programmers, who tend to get hung up on the details of implementation. And when they do, the remainder of the complexity that creeps into Squeak images is a product of "taste".
Look at how many methods are in core classes that there because of some weird corner case where the semantics did not quite work. Objects veryDeepCopy* tend to fall into this category. Then you get the pure semantic sugar methods, which can be found in methods such as the SyntaxMorph's polution of object with the 5 selfWrittenAs* methods.
anObject actionMap vs
EventManager actionMapFor: anObject vs EventManager actionMaps at: anObject ifAbsent: [ EventMangager createActionMap ] And then consider what the Morph class does in comparison.
aMorph extension valueOfProperty: #actionMap. vs aMorph extension otherProperties at: aSymbol ifAbsent: [^ aBlock value] where extension is a MorphExtension object, and otherProperties is an IdentityDictionary.
If you look at what is actually trying to be done, both cases are attempting to provide ad hoc properties to a base object. On the one hand, a global external weak reference dictionary was used to do the mapping, and on the other a per-instance dictionary was created to amend the object's properties. They do the same thing (return a dictionary) with roughly the same semantics, but this is definitely a simpler way than having two hyperbolically parallel implementations.
What really needs to happen at some point is a "Grand-Refactoring" where in some fundamental architectural changes can be made with a view towards simplifying the end-user semantics. Look at all the places someone has hacked a new method in a core class, that is only used in a specific context or work around, and then identify the features and generalized semantics that would have accounted for what became a fringe case. One feature that would fix many of these issues is to just provide one standard way for instances of Object to add ad hoc properties and methods. Another feature that has yet to be used properly is traits. Packages are a third.
Why a Grand-Refactoring might never happen, is it will require rewriting substantial amounts of the image, and will necessarily break all existing applications. You can leave in shims to port old code, but unless you remove them quickly (within a year) you ensure that habitual factors will prevent them from ever being removed. You can also do a Slightly-Less-Grand-Refactoring every couple years, to pick any weeds that have grown up between the cracks, or fix issues that people have been working around in the original one. But you don't want to pump out one of those more than once a year, to give people a stable base.
Overcoming mental inertia is very hard work. You have to change your habits, and see things you've stared at for too long with fresh eyes. But it can be done if there is enough will in the community.
|
In reply to this post by David T. Lewis
On Mon, 2009-07-06 at 07:35 -0400, David T. Lewis wrote:
> On Sun, Jul 05, 2009 at 08:19:13PM -0700, Andreas Raab wrote: > > > > * Minimalism. > > * Tools. > > * Education. > > > ... > > > > Since this is supposed to the the starting point for a strategy > > discussion, what do people think about the above areas of interest? I'm > > in particular interested in whether you think you could identify with > > the three pillars of Squeak since if we can agree on those as the most > > important values that we *all* share, it seems that there are obvious > > practical consequences that we can draw from it. > > Yes, these three capture the fundamentals nicely. I am inclined also to > think of "Accessibility" in the sense of an entire system that is visible, > browsable, and changeable from top to bottom. Squeak is different from > other open systems because an individual person can really lay hands on > it, learn from it, and experiment to his or her heart's desire. I think > you have captured that theme nicely under the "Education" pillar, but > I wonder if it may be worth a pillar of its own. On the other hand, > explaining this under the theme of Squeak as an educational system helps > to articulate why the education pillar is important to all of us, not just > to young children. > > > I think that formulating and agreeing on our values as a community is a > > central part of setting our own direction. It gives us something to look > > back to when we don't know what to do next, it gives us something to > > agree on when we disagree. > > Nicely said. > > Dave Thank you I very much agree that accessibility is a core strength of Squeak and one I certainly would not wish to lose. On the one hand this accessibility is do in part to the tools, but that is certainly not the entirety of the story. Ken signature.asc (196 bytes) Download Attachment |
Dear All,
I am not and never intended to compete with Andreas. I most certainly do not have time or energy right now. Andreas could have come to me with his ideas in the first place, and integrated them into the existing philosophy and process rather than replacing the process, and attempting to integrate my tools into a new process for which they were not intended. He could quite easily have picked up the ball and run with it by loading squeaksource/Tasks and reviewing class ReleaseAfterSqueak310 and looked at it tried it out and refined it. As far as I know I am the only person who has been motivated to get some significant commonality going between existing forks, and we have had one major success so far, with Gjallar being able to move from 3.8 to 3.10 due to its use of Installer scripts. I am going to let you lot get on with whatever you want to do because Andreas is not going to submit to my overall vision anyway. Either he thinks my ideas are worth using or not. Since my main idea was that of a philosophy embodied in a rigid repeated automated process which he has summarily replaced with a relatively haphazard uncontrolled and unplanned process, it appears not. I believe that ultimately my ideas will stand or fall on their own merit, and I will just have to be more patient. I have no quibble with the idea of using a common repositories, for externally managed projects, and the plan was to move certain components of the kernel out into externally shared (or stolen/acquired from pharo) packages anyway. e.g. Network, Collections etc. I maintain that the image itself (or the repository representing it, otherwise known as "trunk") should only be touched by completed "grand refactorings" that are at the point of integration, and this integration should be effected by an automatic build task every day/week into a separate "unstable" image until deemed ready. I believe that if all the maintainers of all the forks, adopted this approach, even in part, then "ready to integrate chunks" would be more readily exchanged and shared among forks. I resist strongly the idea that all kernel packages be made open access for people to simultaneously apply multiple incomplete innovations and refactorings that have not been subjected in their complete form to peer review or test in a publicly available "unstable" image. At present I don't have time to compete, or to build something and say - there you go my ideas was better after all. After you have mangled the image about a bit, I will take another look at the situation when I have time. For the moment my future work on Bob, will strictly be work that I need for my commercial projects and amusement. All the sources etc are available for you to play with if you want to. I might be back around October. have fun Keith |
Igor,
thanks for that, I still think we will get there in the end. >From now on, I will endeavour to work with, and encourage people to communicate in a friendlier medium than email/irc I honestly believe that if Andreas and I had spoken on the phone/skype this confusion etc would never have happened. take care Keith |
2009/7/6 Keith Hodges <[hidden email]>:
> Igor, > > thanks for that, I still think we will get there in the end. > Sorry, but for what? I didn't posted to this topic a bit. And as far as i know, i am the only Igor who posting on squeak-dev. > >From now on, I will endeavour to work with, and encourage people to > communicate in a friendlier medium than email/irc I honestly believe > that if Andreas and I had spoken on the phone/skype this confusion etc > would never have happened. > > take care > > Keith > > -- Best regards, Igor Stasenko AKA sig. |
I am not posting to this thread , because i sharing the same vision,
as Andreas does, except some little insignificant details maybe. But i am more concerned with what we have built or going to build on top of those pillars. Because we all know, that "Road to hell is ALSO paved by a good intensions" :) 2009/7/6 Igor Stasenko <[hidden email]>: > 2009/7/6 Keith Hodges <[hidden email]>: >> Igor, >> >> thanks for that, I still think we will get there in the end. >> > Sorry, but for what? I didn't posted to this topic a bit. > And as far as i know, i am the only Igor who posting on squeak-dev. > >> >From now on, I will endeavour to work with, and encourage people to >> communicate in a friendlier medium than email/irc I honestly believe >> that if Andreas and I had spoken on the phone/skype this confusion etc >> would never have happened. >> >> take care >> >> Keith >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig. |
Free forum by Nabble | Edit this page |