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@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:
- Get some Vision out there. The stuff here was my best first shot.
- Get some form of decision process in place.
- 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@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation