[Squeakfoundation]Discussion on vision!

ducasse ducasse at iam.unibe.ch
Wed Sep 24 21:58:44 CEST 2003


Hi goran

I agree with your ideas.
	- We will continue to work on the cleaning (slowly peeble by peeble) 
of the kernel,
	- lukas and/or adrian and/or nathanael and/or me will work on a new 
completely from scratch implementation
	of traits with tests and all the rest. We should decide who and the 
plan next week.
	- I'm planning to work on analysis for modularisation as a research 
topics, and I will take Squeak as case study.
	- A package mechanism is getting to really show up. Perfect. I know 
that Ginsu is now open source and that
	joseph has a mySql back end but we will see that later.
	- I think that we should have a better infrastructure in the same 
ideas that
		FileList registration, for the menu for example
	- The idea of a better code and better infrastructure is that people 
can experiment much faster without breaking all 	the rest.
	- I think that I liked 3.6 because it evolved at each level (TTF and 
kernel and network). So this was a good model
	for the future.

What I would like from the Guides is to push forward some key points 
for 3.7 and the next:
	- Flow (may be I'm not expert but having a good stream library could 
be good)
	- Some KCP stuff (I hope that the notification mechanism will get 
mature)
	- A new and sexy look
	- Something that I would really like to have is a better tool kit to 
build user interface 	May be you should send a call?
	- marcus would like to use the SmaCC AST and clean the compiler this 
is also important
	and at ESUG john told us that he should discuss with don but that a 
dual licensing SqueakL/MIT could be
        possible.
	- Ideally I would really to have the RB **engine** inside Squeak 
because when I see how fast I go with changing 	code in VW.

What I can tell you is that next year ESUG will be at brussels (we 
tried to change the date but for money reasons
and room problems we got stuck with the last week of August). Now this 
is up to you to make a Squeak event at  ESUG: we will provide all the 
rest (beer, network....:).
	
	Stef



On Mardi, sep 23, 2003, at 14:42 Europe/Zurich, 
goran.krampe at bluefish.se wrote:

> Hi fellow Guides and all others!
>
> NOTE TO ALL: Please do NOT crosspost this post to squeak-dev. It is
> meant as a seed for discussion and if stuff like this gets immediately
> crossposted to squeak-dev then it will make it much harder to use this
> list as an open discussion channel for the Guides.
>
> Once upon a time (the squeak-dev thread called "[IMPORTANT]Concrete
> proposals!") I
> promised that we Guides should come up with something like a Vision.
>
> Now I have taken some time to actually formulate *my personal* Vision 
> of
> Squeak and our future.
>
> So this is a "seed for discussion" and is (I repeat) *my personal
> thoughts* on the matter.
> Let's throw some thoughts around and try to condense this into 
> something
> good.
>
> (AsbestSuit on: self) wear
>
> regards, Göran
>
> PS. This was about the Vision. A totally different chapter is the 
> Guides
> - us.
> There are three things I want us to do in that respect:
> 1. Get some Vision out there. The stuff here was my best first shot.
> 2. Get some form of decision process in place.
> 3. Rotate at least one Guide, maybe more.
>
> --------------
>
> My personal Vision on Squeak
>
> To me *all* the different directions, views and visions that live 
> inside
> the Squeak community have great value. I want Squeak to be a platform,
> media,
> call it whatever you like - that is as versatile and universally useful
> as possible. The vision outlined here may though be perceived by some 
> as
> too vague or general. But I truly believe that many of the great 
> virtues
> of Squeak and its community come from this diversity.
>
> Currently I use Squeak for my email, my private experiments in
> programming, our Swikis in our company, as the development environment
> of choice for my web apps and other projects that don't need "business
> UIs" and sometimes as a presentation tool.
>
> But I also "use" Squeak for personal fulfillment - the Squeak community
> is packed with ideas, creativity and interesting people from all over
> the world. Following the squeak-dev list is hard work, but it pays off
> by teaching me things almost every day. I also enjoy being a part of 
> the
> community, getting to know people, collaborating and simply solving
> problems together.
>
> A recent example of this is that Daniel Vainsencher and Andreas Raab
> visited Stockholm for a few days and to meet Squeakers in the real 
> world
> is always inspiring.
>
> During this visit Daniel and I discussed the Guides "model", the
> community and how it works and much more. We didn't solve the issues of
> course - but for me personally it did clear my head about *my* vision
> for Squeak. It turns out that I actually can explain this vision using
> three headlines:
>
> #1 The universal tool
>
> I want Squeak - the tool - to improve in any and all areas possible.
> Better performance, more ports, more and better libraries, more
> possibilities for user interfaces, more implemented standards 
> (typically
> communication) and so on. I want to be able to choose Squeak as my tool
> of choice for *any* development task.
>
> This also includes evolving Squeak the language. I am in favour of
> looking at for example Traits or implementing new and modern Collection
> classes. ANSI compliance is good - but IMHO it should never be allowed
> to stand in the way of the evolution of Squeak. Smalltalk is a dead
> language, if we consider the standard at least - Squeak on the other
> hand is very much alive. Being somewhat compatible with other 
> Smalltalks
> is also a nice thing - but again, I don't think we should let it stand
> in our way
> into the future.
>
> So as I said in the introduction above - I don't want to point at any
> specific area to be more important than any other. The more diverse
> people and interests we can satisfy the more interesting solutions and
> cross-domain ideas we may find.
>
> BUT... for the tool Squeak to scale as a universal tool and platform -
> we need better infrastructure. And we are getting there slowly.
> SqueakMap has been a success - very much so to my personal 
> satisfaction.
> Now we need to get the next version up as soon as possible, and that is
> still my first priority.
>
> But we also need other things - one thing is a Test server, and I 
> happen
> to know that some people are working on that. A Test server could
> automatically run unit test suites for different packages and
> combinations of packages - and thus act as the big guardian of
> robustness and quality. After having seen Daniel Vainsencher describe
> how rules about dependencies in our code actually can be expressed as
> Unit tests (the package MudPie) a Test Server suddenly sounds like a
> really great addition to our infrastructure. (Note: Just saw Daniel's
> posts on this subject on the list)
>
> Another such thing that is missing is a big cross-reference server - 
> and
> AFAIK nobody is yet working on that. SqueakMap2 will of course be a
> fundamental prerequisite for such a beast. Imagine a server that knows
> about all the package releases on SqueakMap and can reliably answer
> questions like for example "all senders of..." and "all implementors
> of..." *globally* for all known packages.
>
> In short - we need better tools. The above two servers are just pieces
> of the puzzle. There are other tools we need too - like Monticello
> servers for team development on packages, some bug report tool for
> keeping track of bugs grouped by package and so on.
>
> Some people think that the current trend with partitioning Squeak into
> packages with appointed maintainers/stewards is making it harder to
> maintain Squeak as a coherent environment. Yes, the new scheme demands
> more of our infrastructure - but I am convinced that this move is
> healthy and will make Squeak scale and be able to sustain a much higher
> speed of evolution through parallellism.
>
> But this current direction also demands something from all of us - we
> must
> learn to delegate and *trust* other Squeakers to take decisions in the
> respective
> areas. This is something we need to work on and we Guides should take a
> lead
> in and try to finally establish different areas of responsibility using
> the
> previouslly outlined concept Stewards.
>
> Finally I want to note the importance of all the other projects going 
> on
> at
> the moment - KCP, MCP, m17n, Squeakland and many others come to mind.
> All these projects make Squeak better.
>
> #2 Collaboration and communication
>
> Currently Squeakers collaborate using a mailinglist, a number of 
> Swikis,
> an ftp site, SqueakMap and to very little extent IRC. We do publish
> Projects for people to play with but that is still just a way of
> publishing a document - not much interaction going on there between
> Squeakers.
>
> Maybe I missed a thing or two but essentially IMHO we aren't using
> Squeak itself to its full potential. I want us to start thinking about
> building infrastructure for tying the Squeak community together in more
> real time. There have been numerous ideas in this respect and I hope to
> see more of it.
>
> Squeak is a great platform for groundbreaking new ways to collaborate
> and communicate. We are also in a unique situation since when we are
> using Squeak we are also *running it* - we are living inside the object
> space. So we can easily add various collaborative mechanisms to 
> actually
> make Squeak stand out *even more* compared to other development
> environments.
>
> SqueakMap2 will actually lay the base for such mechanisms and ideas.
> How? It extends the map to not only keeping track of packages, but also
> keeping track of Squeakers. Eventually we will actually be able to 
> track
> a single element of Squeak, say a method - to an SM package and thus to
> one or more Squeakers.
>
> Having such a model of the community itself is the first step towards
> more advanced communication than the mailinglist. Let the brainstorming
> begin!
>
> #3 Fun
>
> When all words have been said this is in fact the most important thing
> for me. I want to have fun. Squeak is fun. The community is full of fun
> ideas and fun people. I wouldn't be in the Squeak community if it 
> wasn't
> as fun as it is. :-)
>
> One early peer reviewer of this text mentioned that Fun should be #1 
> and
> not #3. But I saved it for last to make it a better finish. :)
>
> Many people view Squeak as a vehicle for a cause - it may be to build a
> new 3D environment (Croquet) to create new possibilites for
> communication. It may be to create and spur a new way of learning 
> (eToys
> etc).
>
> All these ideas are very interesting, inspiring and important. But the
> thing that makes them that - to me at least - is that they are fun. It
> is *great* fun to see kids explore, laugh and enjoy the buzzing
> fulfillment of creating something on their own. We also know that kids
> learn best through playing - having fun.
>
> It is also great fun to play around in 3D and imagining how such an
> awesome environment like Croquet can change the way we build systems 
> and
> "places" on the net.
>
> Again, when I talked to Daniel when he was here we realized that we
> really could have more... "fun events" in the community.
> <teaser>
> Daniel and I have loosely been cooking up one idea for such an event
> that would take place during a full weekend, 48 hours. Exactly what it
> would entail is the topic of a different post - but it is just pure 
> fun.
> :)
> </teaser>
>
> So my final word is - whatever we do to move Squeak into the future -
> let's make sure we have fun doing it. :)
>
> regards, Göran
> _______________________________________________
> Squeakfoundation mailing list
> Squeakfoundation at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
>



More information about the Squeakfoundation mailing list