[squeak-dev] The Pillars of Squeak

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] The Pillars of Squeak

Andreas.Raab
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

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Pillars of Squeak

Ralph Johnson
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

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Pillars of Squeak

Michael Rueger-6
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

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Pillars of Squeak

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Pillars of Squeak

garduino
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

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Pillars of Squeak

David Goehrig
In reply to this post by Ralph Johnson
On Mon, Jul 6, 2009 at 7:03 AM, Ralph Johnson <[hidden email]> wrote:
 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.

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.  

Then there is the huge number of methods that are in desperate need of some thought and refactoring.  Consider:

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.

--
-=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Pillars of Squeak

Ken Causey-3
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
David,

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
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Pillars of Squeak

keith1y
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



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Pillars of Squeak

keith1y
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

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Pillars of Squeak

Igor Stasenko
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.

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] The Pillars of Squeak

Igor Stasenko
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.